Re: OpenWrt One - celebrating 20 years of OpenWrt

2024-02-27 Thread Ivan Ivanov
This is an excellent idea by Dave Taht to use multiple ath9k chips.
Actually, I don't understand: how for a "modern, open, stable" WiFi
platform - someone could suggest a blobbed Mediatek or even worse,
Broadcom. an OpenWRT official device should be no worse than
LibreCMC-supported routers in regards to openness and freedom
(LibreCMC is a fork of OpenWRT for routers which could run on 100%
opensource without any binary blobs) . If you take some random
Mediatek with crappy binary blobs as the base, such a router won't be
any better than what you could get at store for a much cheaper price
:P

A higher price of OpenWRT router would be much more justified by "no
binary blobs" as the primary selling point. So the solution is either
to put multiple blobless ath9k chips or reverse-engineer & liberate
the firmware of some newer WiFi chip (or even create a new WiFi chip
by crowdfunding). There are no other sane options in sight

> Dave Taht wrote:
> I would actually, be happy cutting even more multiplexing latency out of the 
> ath9k chips

Best regards,
Ivan

On Tue, Feb 27, 2024 at 9:21 AM Bas Mevissen via openwrt-devel
 wrote:
>
> 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.
>
>
> -- Forwarded message --
> From: Bas Mevissen 
> To: Paul D 
> Cc: John Crispin , "Rafał Miłecki" , 
> OpenWrt Development List , 
> complia...@sfconservancy.org
> Bcc:
> Date: Tue, 27 Feb 2024 10:19:30 +0100
> Subject: Re: OpenWrt One - celebrating 20 years of OpenWrt
> On 2024-02-27 10:16, Bas Mevissen wrote:
>
> (former one escaped too quickly, please ignore)
>
> > On 2024-02-26 22:38, Paul D wrote:
> >> On 2024-02-26 19:39, John Crispin wrote:
> >>> Hi Rafał,
> >>>
> >>>> Is there any update / schedule you could share?
> >>> I have been meaning to send an update for a few days. Thanks for
> >>> reminding me.
> >>>>
> >>>> I'm really looking forward to this device.
> >>> yeah, me too ;)
> >>>
> >>>
> >>> Lots of stuff has been happening. There was a short break due to the
> >>> lunar new year but we are picking up pace again.
> >>>
> >>> *) schematics are done
> >
> > Can it be shared already? I'm wondering whether some peripheral port
> > can easily be used to configure an external switch chip. I would like
> > not to have to use the mbus for that.
>
> >
> >>> *) PCB is mostly routed (https://nbd.name/one-top.jpg
> >>> https://nbd.name/one-bottom.png)
> >>
> >> If there is no price difference, can we have 90 degree angled pins for
> >> GND+TX+RX serial header, so the pins face away from the board as USB
> >> sockets do, and not stand up perpendicularly.
> >>
> >> This way serial consoles are workable even when device is in a case.
> >>
> >>
> >> Does anyone else have opinions on this?
> >>
> >
> > I think the console USB connector is intended for that.
> >
> >>>
> >>> *) there was a small hiccup in registering the OUI block that we are
> >>> currently resolving
> >>> *) the trademark agreement is being worked on - I have a call with
> >>> SFC tomorrow to discuss this
> >>>
> >>> I am expecting that the first 15 PCBA samples will be produced
> >>> shortly and be shipped by end of march.
> >>>
> >>> as for the software side, I modified a mt7981 RFB to have  dual
> >>> flash, mikrobus,  s.T. I could build and test dts files. I
> >>> ordered the RTC used on a carrier board and was able to test it.
> >>>
> >>> all the u-boot patches are pretty much done. there is a pretty
> >>> elaborate uboot-env with lots of commands to provide easy
> >>> un-brickability.
> >>>
> >>> I have a local OpenWrt tree with ~10 patches that I hope to send as a
> >>> RFC later this week.
> >>>
> >>> the PCB will probably be light blue (PANTONE 306 C) which is the
> >>> light blue used inside the OpenWrt logo. we are still figuring this
> >>> out with the supplier.
> >>
> >>
> >> In 20 years when these devices are old and need recycling, how
> >> recyclable are the PCBs? What substances go into it? Toxic ones?
&

Re: OpenWrt One - celebrating 20 years of OpenWrt

2024-02-27 Thread Bas Mevissen via openwrt-devel
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 ---

On 2024-02-27 10:16, Bas Mevissen wrote:

(former one escaped too quickly, please ignore)


On 2024-02-26 22:38, Paul D wrote:

On 2024-02-26 19:39, John Crispin wrote:

Hi Rafał,


Is there any update / schedule you could share?
I have been meaning to send an update for a few days. Thanks for 
reminding me.


I'm really looking forward to this device.

yeah, me too ;)


Lots of stuff has been happening. There was a short break due to the 
lunar new year but we are picking up pace again.


*) schematics are done


Can it be shared already? I'm wondering whether some peripheral port 
can easily be used to configure an external switch chip. I would like 
not to have to use the mbus for that.




*) PCB is mostly routed (https://nbd.name/one-top.jpg 
https://nbd.name/one-bottom.png)


If there is no price difference, can we have 90 degree angled pins for 
GND+TX+RX serial header, so the pins face away from the board as USB 
sockets do, and not stand up perpendicularly.


This way serial consoles are workable even when device is in a case.


Does anyone else have opinions on this?



I think the console USB connector is intended for that.



*) there was a small hiccup in registering the OUI block that we are 
currently resolving
*) the trademark agreement is being worked on - I have a call with 
SFC tomorrow to discuss this


I am expecting that the first 15 PCBA samples will be produced 
shortly and be shipped by end of march.


as for the software side, I modified a mt7981 RFB to have  dual 
flash, mikrobus,  s.T. I could build and test dts files. I 
ordered the RTC used on a carrier board and was able to test it.


all the u-boot patches are pretty much done. there is a pretty 
elaborate uboot-env with lots of commands to provide easy 
un-brickability.


I have a local OpenWrt tree with ~10 patches that I hope to send as a 
RFC later this week.


the PCB will probably be light blue (PANTONE 306 C) which is the 
light blue used inside the OpenWrt logo. we are still figuring this 
out with the supplier.



In 20 years when these devices are old and need recycling, how 
recyclable are the PCBs? What substances go into it? Toxic ones?


The color pigment is probably not the biggest concern...






I should probably start building a page inside the wiki to provide 
better visibility into what is happening.




Would be great. But this mail was already great to read about the 
progress!


shout out to pepe2k, SFC and MTK for the never ending support that 
they provide on this journey.


And an extra big thank you to Simon, the designer/engineer from BPi 
that has been ultra cool in making this become a reality


     John


Agree!


Bas.





___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


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

2024-02-27 Thread Bas Mevissen via openwrt-devel
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 ---

On 2024-02-26 22:38, Paul D wrote:

On 2024-02-26 19:39, John Crispin wrote:

Hi Rafał,


Is there any update / schedule you could share?
I have been meaning to send an update for a few days. Thanks for 
reminding me.


I'm really looking forward to this device.

yeah, me too ;)


Lots of stuff has been happening. There was a short break due to the 
lunar new year but we are picking up pace again.


*) schematics are done


Can it be shared already? I'm wondering whether some peripheral port can 
easily be used to configure an external switch chip. I w


*) PCB is mostly routed (https://nbd.name/one-top.jpg 
https://nbd.name/one-bottom.png)


If there is no price difference, can we have 90 degree angled pins for 
GND+TX+RX serial header, so the pins face away from the board as USB 
sockets do, and not stand up perpendicularly.


This way serial consoles are workable even when device is in a case.


Does anyone else have opinions on this?



I think the console USB connector is intended for that.



*) there was a small hiccup in registering the OUI block that we are 
currently resolving
*) the trademark agreement is being worked on - I have a call with SFC 
tomorrow to discuss this


I am expecting that the first 15 PCBA samples will be produced shortly 
and be shipped by end of march.


as for the software side, I modified a mt7981 RFB to have  dual flash, 
mikrobus,  s.T. I could build and test dts files. I ordered the 
RTC used on a carrier board and was able to test it.


all the u-boot patches are pretty much done. there is a pretty 
elaborate uboot-env with lots of commands to provide easy 
un-brickability.


I have a local OpenWrt tree with ~10 patches that I hope to send as a 
RFC later this week.


the PCB will probably be light blue (PANTONE 306 C) which is the light 
blue used inside the OpenWrt logo. we are still figuring this out with 
the supplier.



In 20 years when these devices are old and need recycling, how 
recyclable are the PCBs? What substances go into it? Toxic ones?





I should probably start building a page inside the wiki to provide 
better visibility into what is happening.


shout out to pepe2k, SFC and MTK for the never ending support that 
they provide on this journey.


And an extra big thank you to Simon, the designer/engineer from BPi 
that has been ultra cool in making this become a reality


     John




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel



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

2024-02-26 Thread Paul D

On 2024-02-26 19:39, John Crispin wrote:

Hi Rafał,


Is there any update / schedule you could share?
I have been meaning to send an update for a few days. Thanks for 
reminding me.


I'm really looking forward to this device.

yeah, me too ;)


Lots of stuff has been happening. There was a short break due to the 
lunar new year but we are picking up pace again.


*) schematics are done
*) PCB is mostly routed (https://nbd.name/one-top.jpg 
https://nbd.name/one-bottom.png)


If there is no price difference, can we have 90 degree angled pins for 
GND+TX+RX serial header, so the pins face away from the board as USB 
sockets do, and not stand up perpendicularly.


This way serial consoles are workable even when device is in a case.


Does anyone else have opinions on this?



*) there was a small hiccup in registering the OUI block that we are 
currently resolving
*) the trademark agreement is being worked on - I have a call with SFC 
tomorrow to discuss this


I am expecting that the first 15 PCBA samples will be produced shortly 
and be shipped by end of march.


as for the software side, I modified a mt7981 RFB to have  dual flash, 
mikrobus,  s.T. I could build and test dts files. I ordered the RTC 
used on a carrier board and was able to test it.


all the u-boot patches are pretty much done. there is a pretty elaborate 
uboot-env with lots of commands to provide easy un-brickability.


I have a local OpenWrt tree with ~10 patches that I hope to send as a 
RFC later this week.


the PCB will probably be light blue (PANTONE 306 C) which is the light 
blue used inside the OpenWrt logo. we are still figuring this out with 
the supplier.



In 20 years when these devices are old and need recycling, how 
recyclable are the PCBs? What substances go into it? Toxic ones?





I should probably start building a page inside the wiki to provide 
better visibility into what is happening.


shout out to pepe2k, SFC and MTK for the never ending support that they 
provide on this journey.


And an extra big thank you to Simon, the designer/engineer from BPi that 
has been ultra cool in making this become a reality


     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

2024-02-26 Thread John Crispin

Hi Rafał,


Is there any update / schedule you could share?
I have been meaning to send an update for a few days. Thanks for 
reminding me.


I'm really looking forward to this device.

yeah, me too ;)


Lots of stuff has been happening. There was a short break due to the 
lunar new year but we are picking up pace again.


*) schematics are done
*) PCB is mostly routed (https://nbd.name/one-top.jpg 
https://nbd.name/one-bottom.png)


*) there was a small hiccup in registering the OUI block that we are 
currently resolving
*) the trademark agreement is being worked on - I have a call with SFC 
tomorrow to discuss this


I am expecting that the first 15 PCBA samples will be produced shortly 
and be shipped by end of march.


as for the software side, I modified a mt7981 RFB to have  dual flash, 
mikrobus,  s.T. I could build and test dts files. I ordered the RTC 
used on a carrier board and was able to test it.


all the u-boot patches are pretty much done. there is a pretty elaborate 
uboot-env with lots of commands to provide easy un-brickability.


I have a local OpenWrt tree with ~10 patches that I hope to send as a 
RFC later this week.


the PCB will probably be light blue (PANTONE 306 C) which is the light 
blue used inside the OpenWrt logo. we are still figuring this out with 
the supplier.


I should probably start building a page inside the wiki to provide 
better visibility into what is happening.


shout out to pepe2k, SFC and MTK for the never ending support that they 
provide on this journey.


And an extra big thank you to Simon, the designer/engineer from BPi that 
has been ultra cool in making this become a reality


    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

2024-02-26 Thread Rafał Miłecki

Hi John!

On 9.01.2024 11:49, John Crispin wrote:

In 2024 the OpenWrt project turns 20 years! Let's celebrate this anniversary by 
launching our own first and fully upstream supported hardware design.

If the community likes the idea outlined below in greater details, we would 
like to start a vote.


Is there any update / schedule you could share?

I'm really looking forward to this device.

___
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

2024-01-23 Thread Andrey Jr. Melnikov
John Crispin  wrote:
> tl;dr

> In 2024 the OpenWrt project turns 20 years! Let's celebrate this 
> anniversary by launching our own first and fully upstream supported 
> hardware design.

> If the community likes the idea outlined below in greater details, we 
> would like to start a vote.

> ---

> The idea

[]

> Hardwarespecifications:

> * SOC: MediaTek MT7981B
> * Wi-Fi: MediaTek MT7976C (2x2 2.4 GHz + 3x3/2x2 + zero-wait DFS 5Ghz)
> * DRAM: 1 GiB DDR4
> * Flash: 128 MiB SPI NAND+ 4 MiB SPI NOR
> * Ethernet: 2x RJ45 (2.5 GbE + 1 GbE)
> * USB (host): USB 2.0 (Type-A port)
> * USB (device, console): Holtek HT42B534-2 UART to USB (USB-C port)
> * Storage: M.2 2042 for NVMe SSD (PCIe gen 2 x1)
> * Buttons: 2x (reset + user)
> * Mechanical switch: 1x for boot selection (recovery, regular)
> * LEDs: 2x (PWM driven), 2x ETH Led (GPIO driven)
> * External hardware watchdog: EM Microelectronic EM6324 (GPIO driven)
> * RTC: NXP PCF8563TS (I2C) with battery backup holder(CR1220)
> * Power: USB-PD-12V on USB-C port (optional802.3at/afPoE via RT5040 module)
Why this slow-switching-power-when-enable yet antoher USB crap? optionally -
may be, but standart barrel plug 5.5/2.1 + (optional internal JST HX 2.54mm 2P
connector) is better.

> * Expansion slots: mikroBUS
> * Certification: FCC/EC/RoHS compliance
> * Case: PCB size is compatible to BPi-R4 and the case design can be re-used
> * JTAG for main SOC: 10-pin 1.27 mm pitch (ARM JTAG/SWD)
> * Antenna connectors: 3x MMCX for easy usage, assembly and durability
> * Schematics: these will be publicly available (license TBD)
> * GPL compliance: 3b. "Accompany it with a written offer ... to give any 
> third party ... a complete machine-readable copy of the corresponding 
> source code"
> * Price: aiming for below 100$

[]


___
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

2024-01-21 Thread Janusz Dziedzic
śr., 17 sty 2024 o 18:15 Daniel Golle  napisał(a):
>
> On Wed, Jan 17, 2024 at 05:47:26PM +0100, John Crispin wrote:
> >
> > On 17.01.24 17:46, Janusz Dziedzic wrote:
> > > Do you think I can use m.2 A->M converter here and use wifi mt7916 A+E
> > > (6GHz) instead of NVMe?
> > > Eg.https://kamami.pl/akcesoria-do-raspberry-pi/587051-m2-m-key-to-m2-a-key-adapter-m2-m-key-do-m2-a-key.html
> > > Will that work?
> >
> > so the theory but we wont know until we try.
>
> I've tried that on BPi-R3 with MT7921K module, and that worked
> fine. I don't see a reason why it wouldn't work on a very similar
> MediaTek SoC -- we just need to make sure the power budget of the
> M.2 slot is enough for even WiFi modules more power hungry than
> MT7921K (I assume MT7916E wants quite a bit more juice).

Also did test today - bpi-r3 + m2 M -> A adapter + intel ax200.
Seems works fine - hope will be same here, so could extend it and have AX/BE.

root@bpi-r3-os-0014555f4dd7:/# lspci
00:00.0 PCI bridge: MEDIATEK Corp. Device 1f32 (rev 01)
01:00.0 Network controller: Intel Corporation Wi-Fi 6 AX200 (rev 1a)
root@bpi-r3-os-0014555f4dd7:/#

root@bpi-r3-os-0014555f4dd7:/# dmesg|grep iwl
[   15.693504] iwlwifi :01:00.0: assign IRQ: got 144
[   15.698560] iwlwifi :01:00.0: enabling device ( -> 0002)
[   15.704665] iwlwifi :01:00.0: enabling bus mastering
[   16.335900] iwlwifi :01:00.0: api flags index 2 larger than
supported by driver
[   16.343604] iwlwifi :01:00.0: TLV_FW_FSEQ_VERSION: FSEQ
Version: 89.3.35.37
[   16.428220] iwlwifi :01:00.0: loaded firmware version
72.daa05125.0 cc-a0-72.ucode op_mode iwlmvm
[   16.445463] iwlwifi :01:00.0: Detected Intel(R) Wi-Fi 6 AX200
160MHz, REV=0x340
[   16.587848] iwlwifi :01:00.0: Detected RF HR B3, rfid=0x10a100
[   16.657202] iwlwifi :01:00.0: base HW address: 5c:80:b6:fe:0c:b8
root@bpi-r3-os-0014555f4dd7:/#


root@bpi-r3-os-0014555f4dd7:/# ls /sys/class/ieee80211/
phy0  phy1  phy2
root@bpi-r3-os-0014555f4dd7:/

BR
Janusz

___
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

2024-01-19 Thread Bjørn Mork
Ivan Ivanov  writes:

> blobless ath9k

OK, I'll bite.

Get yourself a microscope and look closer at that chip.  You might find
some code in there, even if the driver didn't load any.  Please ask
Qualcomm for the source and come back when you've got it.

Modern systems contain a large number of binary blobs.  Every single
processor will come with some kind of firmware attached - either in
persistent storage hidden from the rest of the system or as files for
some driver to load.  And there are processors everywhere.  In the SoC
obviously, in the WiFi controllers, in the switch, in any peripheral, in
the LED controller, etc.

A "libre" system is an illusion. It is completely impossible to create
any sort of modern computer with no closed source parts.

Of course, I know of many projects claiming otherwise.  They are
clinging to some very limited defintion of the hardware vs software
border, allwong them to define any non-upgradable chip as "hardware".
Which is utterly stupid since this actually prevents the system from
ever being able to run open source code on that chip.

Just my .02 €


Bjørn

___
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

2024-01-19 Thread Ivan Ivanov
Dear community,

This is an excellent idea by Dave Taht to use multiple ath9k chips.
Actually, I don't understand: how for a "modern, open, stable" WiFi
platform - someone could suggest a blobbed Mediatek or even worse,
Broadcom. an OpenWRT official device should be no worse than
LibreCMC-supported routers in regards to openness and freedom (fork of
OpenWRT for routers which could run on 100% opensource without any
binary blobs) . If you take some random Mediatek with crappy binary
blobs as the base, such a router won't be any better than what you
could get at store for a much cheaper price :P

A higher price of OpenWRT router would be much more justified by "no
binary blobs" as the primary selling point. So the solution is either
to put multiple blobless ath9k chips or reverse-engineer & liberate
the firmware of some newer WiFi chip (or even create a new WiFi chip
by crowdfunding). There are no other sane options in sight

> Dave Taht wrote:
> I would actually, be happy cutting even more multiplexing latency out of the 
> ath9k chips

Best regards,
Ivan

___
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

2024-01-19 Thread Bas Mevissen via openwrt-devel
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 ---

On 2024-01-17 16:21, John Crispin wrote:

Additional FAQ for OpenWrt One

This is a summary of some further questions regarding the OpenWrt One
project gathered so far. After OpenWrt voted to move forward, it will
be converted into a page within the OpenWrt wiki as a place for
collecting the latest information.

Q: Will the various hardware buttons and switches be fully exposed on
the outside?
A: The latest iteration of the design will fully expose all buttons
and switches.

Q: Will there be an option to purchase preassembled kits?
A: We're considering that option but still need to explore
possibilities with the manufacturer.

Q: When do you expect general availability?
A: Once we vote to move forward, it will take around 45 days until the
first PCBA engineering samples get shipped. These will be passed on to
developers for testing. Once they are verified it will probably take
another 30-45 days until they can be ordered. So we are looking at
April timeframe.

Q: What kind of power supply is needed?
A: While the initial announcement imprecisely referred to the power
supply as "USB-PD 12V" the PCB will draw its required power from a
USB-C PD 3.0/2.0 source.

Q: Why does the current design not feature any USB 3.0 connectivity?
A: USB 3.0 always has the risk of interference with 2.4 GHz Wi-Fi. We
would like to reduce risk as much as possible. Interference proofing
the board would add considerable complexity and costs.

Q: Why did you implement a M.2 slot?
A: After careful consideration we came to the conclusion that directly
exposing a PCIe 1x lane in the form of an M.2 slot provides the most
flexibility for potential expansions. It can be used for NVMe storage
(up to 2242 when using an enclosure), e.g. to host containers or media
files. It also enables the simple use of other, non-OpenWrt
distributions with larger storage footprints.

Q: Why is there no consideration for Wi-Fi 6E/7 (6GHz / Tri-Band)?
A: Neither is the mac80211 upstream support for Wi-Fi 7 complete, nor
is there a fully integrated tri-band SoC solution available right now,
let alone fully or partially supported upstream. Supporting Wi-Fi 7
would drastically increase the overall costs and make it impossible to
deliver sufficient software support in the foreseeable future.

Q: Why are there only two ethernet ports?
A: We didn't want to impose additional complexity and costs by
including an external managed switch IC. One port is 1GBit/s capable,
while the other features a speed up to 2.5GBit/s. This is a limitation
of the chosen SoC.



Makes sense. Most people already have additional switches at home to 
accommodate more than the typically 4-5 ports router have.


Will there be no limitation on which of the ports is the WAN or the LAN 
(e.g. due to offloading)?


Would it be an idea to have a connector with SPI/I2C, power and 
preferably direct access to the media interface to be able to connect 
your own switch board? Then you can still control the switch from 
OpenWRT.



Q: Why should I get the One? There are more capable, more featured
devices available!
A: The OpenWrt One is intended to serve as a robust and simple
educational platform for OpenWrt enthusiasts, it is neither intended
to be a competitor to off the shelf SOHO routers nor do we aim for the
largest possible amount of features. It also serves as a donation
vehicle for the OpenWrt project.

Q: Does that mean that OpenWrt will stop supporting other hardware?
A: There is no intention at all to change the way OpenWrt operates or
how it implements and supports current and future hardware. The
OpenWrt One device will be supported as one device among many others
and receive the same level of support.

Q: Doesn't this draw attention away from properly supporting existing 
devices?

A: The OpenWrt One project is a privately led initiative by a few
enthusiasts, there is no intent to change the focus of the OpenWrt
project in any way.


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel



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

2024-01-18 Thread Rich Brown


> On Jan 18, 2024, at 12:11 PM, Dave Taht  wrote:
> 
> OpenWrt One could use a logo...

Could we get the designer of the current OpenWrt logo/wordmark to augment it 
with the word "One"?

See: 
https://github.com/openwrt/branding/blob/master/logo/openwrt_logo_text_horizontal_blue_and_dark_blue.svg
___
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

2024-01-18 Thread Daniel Santos

On 1/18/24 10:37, Chuanhong Guo wrote:

MT7981 is such a chip with NAT offload capability, and the
flow-offload driver mentioned in other threads is actually
a driver for this hardware block.
Since it's a cost-down MT7986 I would imagine this particular
feature is the same between them:

HW NAT
− Etherent/WiFi
− Wired speed
− IPv4 routing, NAT, NAPT
− IPv6 routing, DS-Lite, 6RD


I can't find an MT7981 / Filogic 820 datasheet anywhere, but apparently 
MediaTek was nice enough to put out a public release for the MT7986 / 
Filogic 820 for the Banana Pi R3. Anybody know what the differences are? 
Could it just be quad vs dual core?


I'm also wondering if MediaTek could be convinced to make a public 
release of the MT7981B for this project.


To work on any MediaTek SoCs, if feels like you have to be an expert in 
all of them to know what microcode they're reusing for each component 
(peripheral interfaces, etc.) from one chip to the next, and thus the 
registers and behavior that had been previously published in a some 
other programmer's manual. It's a strange world to me.


Daniel

___
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

2024-01-18 Thread Dave Taht
On Thu, Jan 18, 2024 at 12:04 PM Gregers Baur-Petersen  wrote:
>
>
>
> On 18/01/2024 17.50, Dave Taht wrote:
> > tee-hee. For the record, I would prefer less (and less buggy) offloads
> > than offloads, and to work on scaling software better to multi-cores.

I had heard there was a mt76? mt79? feature where the completion
interrupt could be made to shape the pulls from the qdisc, essentially
doing hardware shaping. There is support for this in BQL for several
intel chips. True?

> >
> > I also would love to find a chip where fq_codel could be offloaded,
> > but with open source for the offload, since the nss drivers are
> > slightly broken...
> >
> > I also would like a pony.
> >
> Not sure if a pony is the extra addition/feature I need. I'm more of a
> dog person ;-)

OpenWrt One could use a logo...
>
> > On Thu, Jan 18, 2024 at 11:40 AM Chuanhong Guo  wrote:
> >>
> >> Hi!
> >>
> >> On Fri, Jan 19, 2024 at 12:23 AM Fernando Frediani  
> >> wrote:
> >>>
> >>> Hi, interesting. Is it enough to give it the necessary performance boost
> >>> when doing NAT ? Is it capable of doing it on the chip or does it do on
> >>> the CPU ? Reading about it seems to be a software thing although seems
> >>> there are hardware capable devices as well. How comparable is this to a
> >>> chip that has NAT offload capability ?
> >>
> >> MT7981 is such a chip with NAT offload capability, and the
> >> flow-offload driver mentioned in other threads is actually
> >> a driver for this hardware block.
> >> Since it's a cost-down MT7986 I would imagine this particular
> >> feature is the same between them:
> >>
> >> HW NAT
> >> − Etherent/WiFi
> >> − Wired speed
> >> − IPv4 routing, NAT, NAPT
> >> − IPv6 routing, DS-Lite, 6RD
> >>
> >> --
> >> Regards,
> >> Chuanhong Guo
> >>
> >> ___
> >> openwrt-devel mailing list
> >> openwrt-devel@lists.openwrt.org
> >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> >
> >
> >
>
> --
>   -
>   Gregers Baur-Petersen
>   Anthropologist
>   -
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel



-- 
40 years of net history, a couple songs:
https://www.youtube.com/watch?v=D9RGX6QFm5E
Dave Täht CSO, LibreQos

___
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

2024-01-18 Thread Gregers Baur-Petersen



On 18/01/2024 17.50, Dave Taht wrote:

tee-hee. For the record, I would prefer less (and less buggy) offloads
than offloads, and to work on scaling software better to multi-cores.

I also would love to find a chip where fq_codel could be offloaded,
but with open source for the offload, since the nss drivers are
slightly broken...

I also would like a pony.

Not sure if a pony is the extra addition/feature I need. I'm more of a 
dog person ;-)



On Thu, Jan 18, 2024 at 11:40 AM Chuanhong Guo  wrote:


Hi!

On Fri, Jan 19, 2024 at 12:23 AM Fernando Frediani  wrote:


Hi, interesting. Is it enough to give it the necessary performance boost
when doing NAT ? Is it capable of doing it on the chip or does it do on
the CPU ? Reading about it seems to be a software thing although seems
there are hardware capable devices as well. How comparable is this to a
chip that has NAT offload capability ?


MT7981 is such a chip with NAT offload capability, and the
flow-offload driver mentioned in other threads is actually
a driver for this hardware block.
Since it's a cost-down MT7986 I would imagine this particular
feature is the same between them:

HW NAT
− Etherent/WiFi
− Wired speed
− IPv4 routing, NAT, NAPT
− IPv6 routing, DS-Lite, 6RD

--
Regards,
Chuanhong Guo

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel






--
 -
 Gregers Baur-Petersen
 Anthropologist
 -

___
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

2024-01-18 Thread Dave Taht
tee-hee. For the record, I would prefer less (and less buggy) offloads
than offloads, and to work on scaling software better to multi-cores.

I also would love to find a chip where fq_codel could be offloaded,
but with open source for the offload, since the nss drivers are
slightly broken...

I also would like a pony.

On Thu, Jan 18, 2024 at 11:40 AM Chuanhong Guo  wrote:
>
> Hi!
>
> On Fri, Jan 19, 2024 at 12:23 AM Fernando Frediani  
> wrote:
> >
> > Hi, interesting. Is it enough to give it the necessary performance boost
> > when doing NAT ? Is it capable of doing it on the chip or does it do on
> > the CPU ? Reading about it seems to be a software thing although seems
> > there are hardware capable devices as well. How comparable is this to a
> > chip that has NAT offload capability ?
>
> MT7981 is such a chip with NAT offload capability, and the
> flow-offload driver mentioned in other threads is actually
> a driver for this hardware block.
> Since it's a cost-down MT7986 I would imagine this particular
> feature is the same between them:
>
> HW NAT
> − Etherent/WiFi
> − Wired speed
> − IPv4 routing, NAT, NAPT
> − IPv6 routing, DS-Lite, 6RD
>
> --
> Regards,
> Chuanhong Guo
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel



-- 
40 years of net history, a couple songs:
https://www.youtube.com/watch?v=D9RGX6QFm5E
Dave Täht CSO, LibreQos

___
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

2024-01-18 Thread Chuanhong Guo
Hi!

On Fri, Jan 19, 2024 at 12:23 AM Fernando Frediani  wrote:
>
> Hi, interesting. Is it enough to give it the necessary performance boost
> when doing NAT ? Is it capable of doing it on the chip or does it do on
> the CPU ? Reading about it seems to be a software thing although seems
> there are hardware capable devices as well. How comparable is this to a
> chip that has NAT offload capability ?

MT7981 is such a chip with NAT offload capability, and the
flow-offload driver mentioned in other threads is actually
a driver for this hardware block.
Since it's a cost-down MT7986 I would imagine this particular
feature is the same between them:

HW NAT
− Etherent/WiFi
− Wired speed
− IPv4 routing, NAT, NAPT
− IPv6 routing, DS-Lite, 6RD

-- 
Regards,
Chuanhong Guo

___
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

2024-01-17 Thread John Crispin


On 17.01.24 20:31, David Bauer wrote:

Hi John,

On 1/9/24 11:49, 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
- 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


No Idea how MTK factory calibration data is individual per-device.

If it's possible, I'd like to propose a archive of the 
radio-calibration / MAC-Address partition.


So this would be used to enable people download their calibration data 
for their serial-number and

make it "unbrickable" with an SPI clamp.

What do you think?

Best
David

Hi David

indeed, I fully agree, the calib blob holds no privacy relevant info. 
once the vote concludes positive I have the mandat to talk with the ODM. 
the idea is to provide a http/rest endpoint for the ODM to


a) grab a blob with the serial number and other TBD data to be place 
inside the flash


b) upload the calibration data for backup storage,

    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

2024-01-17 Thread David Bauer

Hi John,

On 1/9/24 11:49, 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
- 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


No Idea how MTK factory calibration data is individual per-device.

If it's possible, I'd like to propose a archive of the radio-calibration / 
MAC-Address partition.

So this would be used to enable people download their calibration data for 
their serial-number and
make it "unbrickable" with an SPI clamp.

What do you think?

Best
David

___
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

2024-01-17 Thread John Crispin


On 17.01.24 20:28, Daniel Santos wrote:

On 1/16/24 00:36, John Crispin wrote:


And in the interest of running *my* own mouth, I'm stoked as hell -- 
LOVE that it will have mikroBUS! Thanks to John and everyone working 
on this!


My only request is that any unused gpios that don't make it to 
mikroBUS find their way to a (possibly unpopulated) header some 
where for the sake of hackability. 1mm pitch is fine. I've had more 
than one occasion where I wanted to add something and didn't have 
the bus or I/O lines and then discovered that the MCU did, but they 
were all N/C. Hackability is what makes the FOSS / open hardware 
world so awesome.\!


Daniel

yeah we will add all remaining GPIO togehter with GND and 3,3V on a 
2.54mm header.


HELL YES! Even better!

Even though it's on mikroBUS, maybe export the reset line on header as 
well?


Daniel


Hi Daniel,

good Idea added to my TODO notes

    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

2024-01-17 Thread Daniel Santos

On 1/16/24 00:36, John Crispin wrote:


And in the interest of running *my* own mouth, I'm stoked as hell -- 
LOVE that it will have mikroBUS! Thanks to John and everyone working 
on this!


My only request is that any unused gpios that don't make it to 
mikroBUS find their way to a (possibly unpopulated) header some where 
for the sake of hackability. 1mm pitch is fine. I've had more than 
one occasion where I wanted to add something and didn't have the bus 
or I/O lines and then discovered that the MCU did, but they were all 
N/C. Hackability is what makes the FOSS / open hardware world so 
awesome.\!


Daniel

yeah we will add all remaining GPIO togehter with GND and 3,3V on a 
2.54mm header.


HELL YES! Even better!

Even though it's on mikroBUS, maybe export the reset line on header as well?

Daniel

___
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

2024-01-17 Thread Daniel Golle
On Wed, Jan 17, 2024 at 05:47:26PM +0100, John Crispin wrote:
> 
> On 17.01.24 17:46, Janusz Dziedzic wrote:
> > Do you think I can use m.2 A->M converter here and use wifi mt7916 A+E
> > (6GHz) instead of NVMe?
> > Eg.https://kamami.pl/akcesoria-do-raspberry-pi/587051-m2-m-key-to-m2-a-key-adapter-m2-m-key-do-m2-a-key.html
> > Will that work?
> 
> so the theory but we wont know until we try.

I've tried that on BPi-R3 with MT7921K module, and that worked
fine. I don't see a reason why it wouldn't work on a very similar
MediaTek SoC -- we just need to make sure the power budget of the
M.2 slot is enough for even WiFi modules more power hungry than
MT7921K (I assume MT7916E wants quite a bit more juice).

___
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

2024-01-17 Thread John Crispin



On 17.01.24 17:19, Fernando Frediani wrote:
Hi, again, does this SoC have any type of NAT offload capability ? Now 
a days with common Internet Broadband plans that is becoming a must.


Also is there any possibility to consider more than just 2 Ethernet 
ports (at least 4)? Would that increase the cost significantly ?


Fernando


yes via flow table offload

--> 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/mediatek/mtk_ppe_offload.c



___
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

2024-01-17 Thread Janusz Dziedzic
śr., 17 sty 2024 o 16:27 John Crispin  napisał(a):
>
> Additional FAQ for OpenWrt One
>
> This is a summary of some further questions regarding the OpenWrt One
> project gathered so far. After OpenWrt voted to move forward, it will be
> converted into a page within the OpenWrt wiki as a place for collecting
> the latest information.
>
> Q: Will the various hardware buttons and switches be fully exposed on
> the outside?
> A: The latest iteration of the design will fully expose all buttons and
> switches.
>
> Q: Will there be an option to purchase preassembled kits?
> A: We're considering that option but still need to explore possibilities
> with the manufacturer.
>
> Q: When do you expect general availability?
> A: Once we vote to move forward, it will take around 45 days until the
> first PCBA engineering samples get shipped. These will be passed on to
> developers for testing. Once they are verified it will probably take
> another 30-45 days until they can be ordered. So we are looking at April
> timeframe.
>
> Q: What kind of power supply is needed?
> A: While the initial announcement imprecisely referred to the power
> supply as "USB-PD 12V" the PCB will draw its required power from a USB-C
> PD 3.0/2.0 source.
>
> Q: Why does the current design not feature any USB 3.0 connectivity?
> A: USB 3.0 always has the risk of interference with 2.4 GHz Wi-Fi. We
> would like to reduce risk as much as possible. Interference proofing the
> board would add considerable complexity and costs.
>
> Q: Why did you implement a M.2 slot?
> A: After careful consideration we came to the conclusion that directly
> exposing a PCIe 1x lane in the form of an M.2 slot provides the most
> flexibility for potential expansions. It can be used for NVMe storage
> (up to 2242 when using an enclosure), e.g. to host containers or media
> files. It also enables the simple use of other, non-OpenWrt
> distributions with larger storage footprints.
>
Do you think I can use m.2 A->M converter here and use wifi mt7916 A+E
(6GHz) instead of NVMe?
Eg. 
https://kamami.pl/akcesoria-do-raspberry-pi/587051-m2-m-key-to-m2-a-key-adapter-m2-m-key-do-m2-a-key.html
Will that work?


> Q: Why is there no consideration for Wi-Fi 6E/7 (6GHz / Tri-Band)?
> A: Neither is the mac80211 upstream support for Wi-Fi 7 complete, nor is
> there a fully integrated tri-band SoC solution available right now, let
> alone fully or partially supported upstream. Supporting Wi-Fi 7 would
> drastically increase the overall costs and make it impossible to deliver
> sufficient software support in the foreseeable future.
>
> Q: Why are there only two ethernet ports?
> A: We didn't want to impose additional complexity and costs by including
> an external managed switch IC. One port is 1GBit/s capable, while the
> other features a speed up to 2.5GBit/s. This is a limitation of the
> chosen SoC.
>
> Q: Why should I get the One? There are more capable, more featured
> devices available!
> A: The OpenWrt One is intended to serve as a robust and simple
> educational platform for OpenWrt enthusiasts, it is neither intended to
> be a competitor to off the shelf SOHO routers nor do we aim for the
> largest possible amount of features. It also serves as a donation
> vehicle for the OpenWrt project.
>
> Q: Does that mean that OpenWrt will stop supporting other hardware?
> A: There is no intention at all to change the way OpenWrt operates or
> how it implements and supports current and future hardware. The OpenWrt
> One device will be supported as one device among many others and receive
> the same level of support.
>
> Q: Doesn't this draw attention away from properly supporting existing
> devices?
> A: The OpenWrt One project is a privately led initiative by a few
> enthusiasts, there is no intent to change the focus of the OpenWrt
> project in any way.
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel



-- 
Janusz Dziedzic

___
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

2024-01-17 Thread John Crispin


On 17.01.24 17:46, Janusz Dziedzic wrote:

Do you think I can use m.2 A->M converter here and use wifi mt7916 A+E
(6GHz) instead of NVMe?
Eg.https://kamami.pl/akcesoria-do-raspberry-pi/587051-m2-m-key-to-m2-a-key-adapter-m2-m-key-do-m2-a-key.html
Will that work?


so the theory but we wont know until we try.

    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

2024-01-17 Thread John Crispin

Additional FAQ for OpenWrt One

This is a summary of some further questions regarding the OpenWrt One 
project gathered so far. After OpenWrt voted to move forward, it will be 
converted into a page within the OpenWrt wiki as a place for collecting 
the latest information.


Q: Will the various hardware buttons and switches be fully exposed on 
the outside?
A: The latest iteration of the design will fully expose all buttons and 
switches.


Q: Will there be an option to purchase preassembled kits?
A: We're considering that option but still need to explore possibilities 
with the manufacturer.


Q: When do you expect general availability?
A: Once we vote to move forward, it will take around 45 days until the 
first PCBA engineering samples get shipped. These will be passed on to 
developers for testing. Once they are verified it will probably take 
another 30-45 days until they can be ordered. So we are looking at April 
timeframe.


Q: What kind of power supply is needed?
A: While the initial announcement imprecisely referred to the power 
supply as "USB-PD 12V" the PCB will draw its required power from a USB-C 
PD 3.0/2.0 source.


Q: Why does the current design not feature any USB 3.0 connectivity?
A: USB 3.0 always has the risk of interference with 2.4 GHz Wi-Fi. We 
would like to reduce risk as much as possible. Interference proofing the 
board would add considerable complexity and costs.


Q: Why did you implement a M.2 slot?
A: After careful consideration we came to the conclusion that directly 
exposing a PCIe 1x lane in the form of an M.2 slot provides the most 
flexibility for potential expansions. It can be used for NVMe storage 
(up to 2242 when using an enclosure), e.g. to host containers or media 
files. It also enables the simple use of other, non-OpenWrt 
distributions with larger storage footprints.


Q: Why is there no consideration for Wi-Fi 6E/7 (6GHz / Tri-Band)?
A: Neither is the mac80211 upstream support for Wi-Fi 7 complete, nor is 
there a fully integrated tri-band SoC solution available right now, let 
alone fully or partially supported upstream. Supporting Wi-Fi 7 would 
drastically increase the overall costs and make it impossible to deliver 
sufficient software support in the foreseeable future.


Q: Why are there only two ethernet ports?
A: We didn't want to impose additional complexity and costs by including 
an external managed switch IC. One port is 1GBit/s capable, while the 
other features a speed up to 2.5GBit/s. This is a limitation of the 
chosen SoC.


Q: Why should I get the One? There are more capable, more featured 
devices available!
A: The OpenWrt One is intended to serve as a robust and simple 
educational platform for OpenWrt enthusiasts, it is neither intended to 
be a competitor to off the shelf SOHO routers nor do we aim for the 
largest possible amount of features. It also serves as a donation 
vehicle for the OpenWrt project.


Q: Does that mean that OpenWrt will stop supporting other hardware?
A: There is no intention at all to change the way OpenWrt operates or 
how it implements and supports current and future hardware. The OpenWrt 
One device will be supported as one device among many others and receive 
the same level of support.


Q: Doesn't this draw attention away from properly supporting existing 
devices?
A: The OpenWrt One project is a privately led initiative by a few 
enthusiasts, there is no intent to change the focus of the OpenWrt 
project in any way.



___
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

2024-01-16 Thread Mark Thurston
 > Interesting idea. We've been making and maintaining OpenWrt based
 > routers (yes with our little additions on top) for over a decade. Seems
 > like you have everything figured out already, but wanted to state the
 > obvious anyway - if you are interested, we are here and we would be
 > happy to help.
 > 

Dobry den Michal
I also saw a user called Pepe in the thread. Is it possible we have multiple 
current and former Turris staffers keen to contribute?
If so, that is great as the Omnia is solid.


___
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

2024-01-16 Thread Michal Hrusecky via openwrt-devel
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,

Interesting idea. We've been making and maintaining OpenWrt based
routers (yes with our little additions on top) for over a decade. Seems
like you have everything figured out already, but wanted to state the
obvious anyway - if you are interested, we are here and we would be
happy to help.

-- 

Michal Hrusecky  |  michal.hruse...@turris.com
Technical Lead   |  https://www.turris.com
Turris | CZ.NIC z.s.p.o  |  Milesovska 1136/5, 130 00 Praha

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

2024-01-15 Thread John Crispin



And in the interest of running *my* own mouth, I'm stoked as hell -- 
LOVE that it will have mikroBUS! Thanks to John and everyone working 
on this!


My only request is that any unused gpios that don't make it to 
mikroBUS find their way to a (possibly unpopulated) header some where 
for the sake of hackability. 1mm pitch is fine. I've had more than one 
occasion where I wanted to add something and didn't have the bus or 
I/O lines and then discovered that the MCU did, but they were all N/C. 
Hackability is what makes the FOSS / open hardware world so awesome.\!


Daniel

yeah we will add all remaining GPIO togehter with GND and 3,3V on a 
2.54mm header.


___
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

2024-01-15 Thread Daniel Santos

On 1/15/24 06:56, Paul D wrote:




A kickstarter is a good way to forecast demand.

You've captured the imagination of the geek community.



Not aware of peripheral issues or complexities in doing a kickstarter, 
though I agree with forecasting demand. "Geeks" are good at commenting 
on stuff, and intellectualizing a new board: let's see how many put 
their money where their mouth is.


And in the interest of running *my* own mouth, I'm stoked as hell -- 
LOVE that it will have mikroBUS! Thanks to John and everyone working on 
this!


My only request is that any unused gpios that don't make it to mikroBUS 
find their way to a (possibly unpopulated) header some where for the 
sake of hackability. 1mm pitch is fine. I've had more than one occasion 
where I wanted to add something and didn't have the bus or I/O lines and 
then discovered that the MCU did, but they were all N/C. Hackability is 
what makes the FOSS / open hardware world so awesome.\!


Daniel

___
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

2024-01-15 Thread Daniel Santos

On 1/10/24 08:18, Forest Crossman wrote:

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



I'm always a fan of a single PCB design that *can* be built in different 
configurations. So would suggest a design where differential mux can be 
left unpopulated to create a product w/o USB 3 support. But of course, 
this doesn't overcome EMI concerns Daniel Golle mentioned.


Daniel

___
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

2024-01-15 Thread Paul D





A kickstarter is a good way to forecast demand.

You've captured the imagination of the geek community.



Not aware of peripheral issues or complexities in doing a kickstarter, 
though I agree with forecasting demand. "Geeks" are good at commenting 
on stuff, and intellectualizing a new board: let's see how many put 
their money where their mouth is.


I, for one, think the new board's a great idea, although I'm still happy 
with my Archer. I do feel that an upgrade in the next 12mo may become 
necessary, however.


___
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

2024-01-14 Thread Dave Taht
On Mon, Jan 15, 2024 at 12:55 AM John Crispin  wrote:
>
> when did crowdfunding come into play here ? there is no intention of
> starting a crowdfunder.

A kickstarter is a good way to forecast demand.

You've captured the imagination of the geek community.

https://news.ycombinator.com/item?id=38934013

The original hits, by the original artists!

And upstream first, to build a better future, perhaps, in whatever you do next.

Please consider the idea.

>
>  John
>
> On 15.01.24 01:51, Kathy Giori wrote:
> > Or CrowdSupply  (founder Joshua Lifton).
> >
> > Or I could introduce you to BeagleBoard.org 
> > -- combo of the founder and the exec dir is quite an experienced pair,
> > well-aligned with OpenWrt principles, experienced with getting
> > high-volume hardware manufactured and sold (that is manufactured in
> > Asia). If you want to collaborate/co-brand with them, you'd have solid
> > experience behind the sales and distribution of the platform to
> > top-tier distributors (DigiKey, etc.). I already mentioned this
> > project to founder Jason Kridner and he'd be happy to have a chat.
> >
> > kathy
> >
> > p.s. perhaps you could organize a discussion of this platform at FOSDEM?
> >
> >
> > On Sun, Jan 14, 2024 at 7:05 AM Dave Taht  wrote:
> >
> > Can I recommend you do a kickstarter?
> >
> > ___
> > openwrt-devel mailing list
> > openwrt-devel@lists.openwrt.org
> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> >



-- 
40 years of net history, a couple songs:
https://www.youtube.com/watch?v=D9RGX6QFm5E
Dave Täht CSO, LibreQos

___
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

2024-01-14 Thread John Crispin
when did crowdfunding come into play here ? there is no intention of 
starting a crowdfunder.


    John

On 15.01.24 01:51, Kathy Giori wrote:

Or CrowdSupply  (founder Joshua Lifton).

Or I could introduce you to BeagleBoard.org  
-- combo of the founder and the exec dir is quite an experienced pair, 
well-aligned with OpenWrt principles, experienced with getting 
high-volume hardware manufactured and sold (that is manufactured in 
Asia). If you want to collaborate/co-brand with them, you'd have solid 
experience behind the sales and distribution of the platform to 
top-tier distributors (DigiKey, etc.). I already mentioned this 
project to founder Jason Kridner and he'd be happy to have a chat.


kathy

p.s. perhaps you could organize a discussion of this platform at FOSDEM?


On Sun, Jan 14, 2024 at 7:05 AM Dave Taht  wrote:

Can I recommend you do a kickstarter?

___
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

2024-01-14 Thread Kathy Giori
Or CrowdSupply [1] (founder Joshua Lifton).

Or I could introduce you to BeagleBoard.org [2] -- combo of the
founder and the exec dir is quite an experienced pair, well-aligned
with OpenWrt principles, experienced with getting high-volume hardware
manufactured and sold (manufactured in Asia). If you want to
collaborate/co-brand with them, you'd have solid experience behind the
sales and distribution of the platform to top-tier distributors
(DigiKey, etc.). I already mentioned this project to founder Jason
Kridner and he'd be happy to have a chat.

kathy

[1] https://www.crowdsupply.com/
[2] https://www.beagleboard.org/

p.s. perhaps you could organize a discussion of this platform at FOSDEM?


On Sun, Jan 14, 2024 at 7:05 AM Dave Taht  wrote:
>
> Can I recommend you do a kickstarter?
>
> ___
> 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

2024-01-14 Thread Dave Taht
Can I recommend you do a kickstarter?

___
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

2024-01-12 Thread John Crispin


On 12.01.24 16:16, Bas Mevissen via openwrt-devel wrote:


Hardwarespecifications:

* SOC: MediaTek MT7981B
* Wi-Fi: MediaTek MT7976C (2x2 2.4 GHz + 3x3/2x2 + zero-wait DFS 5Ghz)


Was the MT7986AV, MT7976DA combo considered? Has 4x4 for office 
applications (MU-MIMO), so might be useful for corporate or soho use.

It also has more horse power to run some local services


That would be the BPi R3-Mini. if you need that extra HP, please grab 
that unit.






* DRAM: 1 GiB DDR4


What's the price difference with 2GB? For home automation purposes and 
other virtualisation applications it might come in handy. 


1GB is recommended and well tested. We will probably get engineering 
samples and test with 2GB


    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

2024-01-12 Thread Bas Mevissen via openwrt-devel
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 ---



On 09/01/2024 11:49, John Crispin wrote:



This is our first design, so let's KiSS!



Agreed, however as it needs to last for a long period of time, it should 
not be too under powered.




Hardwarespecifications:

* SOC: MediaTek MT7981B
* Wi-Fi: MediaTek MT7976C (2x2 2.4 GHz + 3x3/2x2 + zero-wait DFS 5Ghz)


Was the MT7986AV, MT7976DA combo considered? Has 4x4 for office 
applications (MU-MIMO), so might be useful for corporate or soho use.

It also has more horse power to run some local services


* DRAM: 1 GiB DDR4


What's the price difference with 2GB? For home automation purposes and 
other virtualisation applications it might come in handy.



* Flash: 128 MiB SPI NAND+ 4 MiB SPI NOR
* Ethernet: 2x RJ45 (2.5 GbE + 1 GbE)
* USB (host): USB 2.0 (Type-A port)
* USB (device, console): Holtek HT42B534-2 UART to USB (USB-C port)


Great idea!


* Storage: M.2 2042 for NVMe SSD (PCIe gen 2 x1)
* Buttons: 2x (reset + user)
* Mechanical switch: 1x for boot selection (recovery, regular)
* LEDs: 2x (PWM driven), 2x ETH Led (GPIO driven)
* External hardware watchdog: EM Microelectronic EM6324 (GPIO driven)
* RTC: NXP PCF8563TS (I2C) with battery backup holder(CR1220)
* Power: USB-PD-12V on USB-C port (optional802.3at/afPoE via RT5040 module)
* Expansion slots: mikroBUS
* Certification: FCC/EC/RoHS compliance
* Case: PCB size is compatible to BPi-R4 and the case design can be re-used
* JTAG for main SOC: 10-pin 1.27 mm pitch (ARM JTAG/SWD)


Nice to have the connector, would be great if a supported USB JTAG 
adapter could be supplied as an option.



* Antenna connectors: 3x MMCX for easy usage, assembly and durability
* Schematics: these will be publicly available (license TBD)
* GPL compliance: 3b. "Accompany it with a written offer ... to give any 
third party ... a complete machine-readable copy of the corresponding 
source code"

* Price: aiming for below 100$



Or just have 1 or 2 existing Banana Pi boards with OpenWRT branding? The 
schematics are not really making much difference for most people. Having 
all SW FOSS does.



Bas.




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

2024-01-12 Thread Michael Richardson

Bjørn Mork  wrote:
> 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'm now imaging a case, literally in the shape of the letters "OpenWRT!!!".
(The !!! are the three antenna)




signature.asc
Description: PGP signature
___
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

2024-01-11 Thread Michael Richardson

Dave Taht  wrote:
> So I at least do not feel a huge urge to get on the 6ghz bandwagon at
> this time. I would actually, be happy cutting even more multiplexing
> latency out of the ath9k chips, and there is much fat left to be cut
> from the mt79 also, and the benefits of many people focused on building
> on top of a single stable *inexpensive* platform and working all the
> bugs out of it - that has a lot of shared characteristics with the
> higher end gear - cannot be underestimated. I still have wndr3800s
> running for years at a time, running openwrt.

+1.



signature.asc
Description: PGP signature
___
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

2024-01-11 Thread Piotr Dymacz

Hi Forest,

On 10.01.2024 15:18, Forest Crossman wrote:

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.


I suppose this should work (I couldn't find anything which would prevent 
using pure h/w analog mux on the bus with a runtime configuration) but I 
don't think there is a way to actually test it without a custom hardware 
(usually anything which doesn't exist in reference design/s from the 
chipset vendor must be tested in target configuration). Assuming bus 
speeds we are talking here about, I'm not sure this can be tested with 
some home-based tinkering ;)


I'm afraid that might delay the project but I will ask around.


 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.


This would also require a bit more current capacity in the USB Type-A 
connector if we decide to make it 3.x.


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

2024-01-11 Thread Arınç ÜNAL

John hello.

I like this project quite a lot. I'm very excited to see it happen and
would love to be involved! The company I work with, Xeront, has some PCB
designs of their own. I can happily connect you with folks for any
discussions about the electronic engineering and manufacturing aspects of
the project, should you need. We're here to help!

On 9.01.2024 13:49, John Crispin wrote:

How will the device be distributed?

OpenWrt itself cannot handle this for a ton of reasons. This is why we spoke 
with the SFC early. The idea is that BPi will distribute the device using the 
already established channels and for every device sold a donation will be made 
to ourSFC earmarked fund for OpenWrt. This money can then be used to cover 
hosting expenses or maybe an OpenWrt summit.


I've been organising an OpenWrt summit in Cyprus along with Battlemesh v16
in May. I've been coordinating with Hauke on this. I've made a small
announcement here [1] giving out the dates for the summit, 18-19 May 2024. This
project would be a great talking point for the summit.

If you or anyone on the list can give us a hand with funding the event, and
finding local folks to help in the field, that'd be great.

[1] http://lists.openwrt.org/pipermail/openwrt-devel/2023-December/041957.html

Arınç

___
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

2024-01-10 Thread Forest Crossman
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


Re: OpenWrt One - celebrating 20 years of OpenWrt

2024-01-10 Thread Piotr Dymacz

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

2024-01-10 Thread Piotr Dymacz

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

2024-01-10 Thread Piotr Dymacz

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

2024-01-10 Thread Piotr Dymacz

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

2024-01-10 Thread John Crispin


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

2024-01-10 Thread Robert Marko
> >
> > 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

2024-01-10 Thread Daniel Golle
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

2024-01-10 Thread Bjørn Mork
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


Re: OpenWrt One - celebrating 20 years of OpenWrt

2024-01-09 Thread David Lang

On Tue, 9 Jan 2024, Paul D wrote:


6GHz seems a starting point nowadays, although I get by with 5GHz.


only if all your clients support 6GHz as well, most don't


* Packages with cases+PSU are a must for broader acceptance,


which explains why the Raspberry Pi bare board is such a failure, right?

having a case design available is a good idea, but not shipping it yourself 
shouldn't be a showstopper.


* Having a few H/W variants available provides demand metrics: which variant 
is more in demand and popular speaks to what people want.


at a significant production/inventory cost. A good idea in the long run, but is 
it really a requirement to start with?


David Lang

___
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

2024-01-09 Thread Mark Thurston
This looks like a great project. I'm sure I would end up buying several units.

Looking at the spec:
 > Ethernet: 2x RJ45 (2.5 GbE + 1 GbE)

2.5Gb FTTP is becoming more widely available. It would be better to be able to 
match egress and ingress surely as it is a router after all?
1GbE x 2 or 2.5GbE x 2 (if the CPU hardware is able to route at that speed). 
Would SPFs be worth considering?

___
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

2024-01-09 Thread Dave Taht
I have often tried to point out that what matters most in wifi is low
interference, better multiplexing across devices, and good bandwidth
*at range*. Up until very recently the 6ghz stuff mostly had terrible
bandwidth, jitter and latency at range, and everyone shipping it
bleeding into all the channels, futility compensating for lousy device
drivers, on stupid, unrealistic benchmarks.

So I at least do not feel a huge urge to get on the 6ghz bandwagon at
this time. I would actually, be happy cutting even more multiplexing
latency out of the ath9k chips, and there is much fat left to be cut
from the mt79 also, and the benefits of many people focused on
building on top of a single stable *inexpensive* platform and working
all the bugs out of it - that has a lot of shared characteristics with
the higher end gear - cannot be underestimated. I still have wndr3800s
running for years at a time, running openwrt.

To date most of the pi-alikes have had absolutely terrible wifi, often
only a single crappy antenna and connected via usb or worse i2c.
Fixing that would be marvellous. a 3x3 as in this board, *lust*

https://docs.google.com/document/d/19ADByjakzQXCj9Re_pUvrb5Qe5OK-QmhlYRLMBY4vH4/edit

On Tue, Jan 9, 2024 at 1:17 PM 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
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel



-- 
40 years of net history, a couple songs:
https://www.youtube.com/watch?v=D9RGX6QFm5E
Dave Täht CSO, LibreQos

___
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

2024-01-09 Thread Janusz Dziedzic
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

___
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

2024-01-09 Thread Daniel Golle
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...

___
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

2024-01-09 Thread Janusz Dziedzic
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?

BR
Janusz

___
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

2024-01-09 Thread Daniel Golle
On Tue, Jan 09, 2024 at 05:52:57PM +0100, 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.

You are right, 6 GHz does *not* imply 802.11be. 802.11ax with HE rates
is sufficient.

However, as one is not supposed to send beacons or do actice scanning
on the 6 GHz band (simply because there are too many channels...) you
would need MBO features to inform clients about 6 GHz AP being
available, and that doesn't yet work very well (due to missing mac80211,
cfg80211 and hostapd features afaik).

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

Afaik the only reasonable way to implement tri-band 2.4G + 5G + 6G using
MTK SoCs is to use the in-SoC WiFi MAC to connect an MT7976A frontend and
use that for 2.4 GHz and 6 GHz, and then put an additional MT7915E
connected via PCIe for the 5 GHz band.
The only tri-band device I know is Adtran's SmartRG SDG-8632.

___
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

2024-01-09 Thread Robert Marko
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.

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

2024-01-09 Thread Rafał Miłecki

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?

___
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

2024-01-09 Thread Chuanhong Guo
Hi!

On Tue, Jan 9, 2024 at 10:34 PM John Crispin  wrote:
>
>
> On 09.01.24 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.
> >
> >> - 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)
>
> we looked into that kind of solution, i felt more accessible for the
> wider audience to use a CDC-ACM chip. flashing using a DAP involves
> knowing what JTAG is and how to use it. the idea is that the NOR uboot
> has a backup copy of the NAND uboot. holding down one of the buttons
> while powering on the device while BOOTSEL is on NOR will auto recover
> the NAND. cannot think of a simpler solution.

My thought was that all the JTAG stuff can live in a script.
But I agree that yours are definitely easier for end user :D

-- 
Regards,
Chuanhong Guo

___
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

2024-01-09 Thread Paul D

6GHz seems a starting point nowadays, although I get by with 5GHz.


If the BPi can be extended with add-on cards for exactly this area, 
that's a great starting point also.



Ideally sub $100 for any product.


* Packages with cases+PSU are a must for broader acceptance, and to 
prevent fatigue from having to buy several parts to get a working system 
that can be wall/ceiling-mounted. This is an implicit advantage to 
buying OTS routers: everything needed is there. An expensive ecosystem 
becomes a limiting factor for adoption.



* Having a few H/W variants available provides demand metrics: which 
variant is more in demand and popular speaks to what people want.



* CPU which manages line-speed WireGuard is very important nowadays: 
with governments monitoring people, users demand privacy afforded by VPNs.



Wi-Fi is still inherently limited by the closed-source nature of the 
Wi-Fi blobs: will those ever be open sourced? It'd be brave, but the 
right way. ( Lots of IP )




On 2024-01-09 11:49, John Crispin wrote:

tl;dr

In 2024 the OpenWrt project turns 20 years! Let's celebrate this 
anniversary by launching our own first and fully upstream supported 
hardware design.


If the community likes the idea outlined below in greater details, we 
would like to start a vote.




___
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

2024-01-09 Thread Michael Richardson

Chuanhong Guo  wrote:
>> * 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.

I don't quite understand the difference; as long as it still has a USB-C it's
fine.

My take on this is that while *I* can unbrick most things, there is still a
mental overhead in doing so...

I think that for many of that would buy a few (dozen), that one thing many us
will do is locate the device at a neighbour/relative/community-space that we
"support" in order to reduce the burden to us.  Being able to walk someone
else through plugging something in is a big win. "When you hit enter, does it
say openwrt#"? and if the answer is no, then we have to do that 100km drive
to visit the device.

I would appreciate a switch chip, since that lets us do DSA and different
things with different ports, but I can live without it.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



signature.asc
Description: PGP signature
___
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

2024-01-09 Thread John Crispin


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


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


we looked into that kind of solution, i felt more accessible for the 
wider audience to use a CDC-ACM chip. flashing using a DAP involves 
knowing what JTAG is and how to use it. the idea is that the NOR uboot 
has a backup copy of the NAND uboot. holding down one of the buttons 
while powering on the device while BOOTSEL is on NOR will auto recover 
the NAND. cannot think of a simpler solution. as for the cdc-acm chip. 
we looked at the holtek, cypress and microchip components. the holtek 
seems to be the easiest to source for the ODM.


    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

2024-01-09 Thread Dave Taht
Battery power capability? Parts of the world still have their power
flicker regularly. Others can be solar powered. What is the projected
power consumption of this device?

___
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

2024-01-09 Thread Chuanhong Guo
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.

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

-- 
Regards,
Chuanhong Guo

___
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

2024-01-09 Thread Enrico Mioso
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 
console 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. :)

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


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.

Enrico


___
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

2024-01-09 Thread Robert Marko
On Tue, 9 Jan 2024 at 13:38, Dave Taht  wrote:
>
> You should talk about this project at FOSSDEM!
>
> Two potential funders off the top of my head:
>
> https://nlnet.nl/funding.html
> https://www.ardc.net/apply/
> Ardc funded the latest round of the librerouter project in argentina,
> which is also openwrt based, but intended for outdoor.
>
> a 10 year design life would be nice. Gpon support instead of a 2.5Gbit port?

GPON support is non-existent in FOSS form basically.

Regards,
Robert
>
> The A53s are pretty weak. I would certainly like to see people squeeze
> more performance out of these...
>
> I am more a software guy than hw,  I would like to see "matter" begin
> to matter. 802.14 anyone? Also:
> https://forum.openwrt.org/t/cerowrt-ii-would-anyone-care/110554
>
> Otherwise, I applaud. We could really use a reference router. I still
> use (and love) my wndr3800s. Have not seen much reason to upgrade.
> There´s still improvements to the ath9k feasible!
>
> On Tue, Jan 9, 2024 at 5:52 AM John Crispin  wrote:
> >
> > tl;dr
> >
> > In 2024 the OpenWrt project turns 20 years! Let's celebrate this
> > anniversary by launching our own first and fully upstream supported
> > hardware design.
> >
> > If the community likes the idea outlined below in greater details, we
> > would like to start a vote.
> >
> > ---
> >
> > The idea
> >
> > It is not new. We first spoke about this during the OpenWrt Summits in
> > 2017 and also 2018. It became clear start of December 2023 while
> > tinkering with Banana Pi style devices that they are already pretty
> > close to what we wanted to achieve in ’17/‘18. Banana PIs have grown in
> > popularity within the community. They boot using a self compiled Trusted
> > Firmware-A (TF-A)and upstream U-Boot (thx MTK/Daniel) and some of the
> > boards are already fully supported by the upstream Linux kernel. The
> > only nonopen sourcecomponents are the 2.5 GbE PHYandWi-Fi firmware
> > blobsrunning on separate cores that areindependent of the main SoC
> > running Linuxand the DRAM calibration routines which are executed early
> > during boot.
> >
> > I contacted three project members (pepe2k, dangole, nbd) on December 6th
> > to outline the overall idea. We went over several design proposals, 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. We would like to propose the following as
> > our "first" community driven HW platform called "OpenWrt One/AP-24.XY".
> >
> > Together with pepe2k (thx a lot) I discussed this for many hours and we
> > worked out the following project proposal. Instead of going insane with
> > specifications, we decided to include some nice features we believe all
> > OpenWrt supported platforms should have (e.g. being almost
> > unbrickablewith multiple recovery options, hassle-free system console
> > access, on-board RTC with battery backup etc.).
> >
> > This is our first design, so let's KiSS!
> >
> >
> > Hardwarespecifications:
> >
> > * SOC: MediaTek MT7981B
> > * Wi-Fi: MediaTek MT7976C (2x2 2.4 GHz + 3x3/2x2 + zero-wait DFS 5Ghz)
> > * DRAM: 1 GiB DDR4
> > * Flash: 128 MiB SPI NAND+ 4 MiB SPI NOR
> > * Ethernet: 2x RJ45 (2.5 GbE + 1 GbE)
> > * USB (host): USB 2.0 (Type-A port)
> > * USB (device, console): Holtek HT42B534-2 UART to USB (USB-C port)
> > * Storage: M.2 2042 for NVMe SSD (PCIe gen 2 x1)
> > * Buttons: 2x (reset + user)
> > * Mechanical switch: 1x for boot selection (recovery, regular)
> > * LEDs: 2x (PWM driven), 2x ETH Led (GPIO driven)
> > * External hardware watchdog: EM Microelectronic EM6324 (GPIO driven)
> > * RTC: NXP PCF8563TS (I2C) with battery backup holder(CR1220)
> > * Power: USB-PD-12V on USB-C port (optional802.3at/afPoE via RT5040 module)
> > * Expansion slots: mikroBUS
> > * Certification: FCC/EC/RoHS compliance
> > * Case: PCB size is compatible to BPi-R4 and the case design can be re-used
> > * JTAG for main SOC: 10-pin 1.27 mm pitch (ARM JTAG/SWD)
> > * Antenna connectors: 3x MMCX for easy usage, assembly and durability
> > * Schematics: these will be publicly available (license TBD)
> > * GPL compliance: 3b. "Accompany it with a written offer ... to give any
> > third party ... a complete machine-readable copy of the corresponding
> > source code"
> > * Price: aiming for below 100$
> >
> >
> > How will the device be distributed?
> >
> > OpenWrt itself cannot handle this for a ton of reasons. This is why we
> > spoke with the SFC early. The idea is that BPi will distribute the
> > device using the already established channels and for every device sold
> > a donation will be made to ourSFC earmarked fund for OpenWrt. This money
> > can then be used to cover hosting expenses or maybe an OpenWrt summit.
> >
> > SFC is committed to working with us in various ways on this project —
> > including making sure OpenWrt'strademark is properly respected, that
> > this router isabeautiful example of excellent 

Re: OpenWrt One - celebrating 20 years of OpenWrt

2024-01-09 Thread Dave Taht
You should talk about this project at FOSSDEM!

Two potential funders off the top of my head:

https://nlnet.nl/funding.html
https://www.ardc.net/apply/
Ardc funded the latest round of the librerouter project in argentina,
which is also openwrt based, but intended for outdoor.

a 10 year design life would be nice. Gpon support instead of a 2.5Gbit port?

The A53s are pretty weak. I would certainly like to see people squeeze
more performance out of these...

I am more a software guy than hw,  I would like to see "matter" begin
to matter. 802.14 anyone? Also:
https://forum.openwrt.org/t/cerowrt-ii-would-anyone-care/110554

Otherwise, I applaud. We could really use a reference router. I still
use (and love) my wndr3800s. Have not seen much reason to upgrade.
There´s still improvements to the ath9k feasible!

On Tue, Jan 9, 2024 at 5:52 AM John Crispin  wrote:
>
> tl;dr
>
> In 2024 the OpenWrt project turns 20 years! Let's celebrate this
> anniversary by launching our own first and fully upstream supported
> hardware design.
>
> If the community likes the idea outlined below in greater details, we
> would like to start a vote.
>
> ---
>
> The idea
>
> It is not new. We first spoke about this during the OpenWrt Summits in
> 2017 and also 2018. It became clear start of December 2023 while
> tinkering with Banana Pi style devices that they are already pretty
> close to what we wanted to achieve in ’17/‘18. Banana PIs have grown in
> popularity within the community. They boot using a self compiled Trusted
> Firmware-A (TF-A)and upstream U-Boot (thx MTK/Daniel) and some of the
> boards are already fully supported by the upstream Linux kernel. The
> only nonopen sourcecomponents are the 2.5 GbE PHYandWi-Fi firmware
> blobsrunning on separate cores that areindependent of the main SoC
> running Linuxand the DRAM calibration routines which are executed early
> during boot.
>
> I contacted three project members (pepe2k, dangole, nbd) on December 6th
> to outline the overall idea. We went over several design proposals, 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. We would like to propose the following as
> our "first" community driven HW platform called "OpenWrt One/AP-24.XY".
>
> Together with pepe2k (thx a lot) I discussed this for many hours and we
> worked out the following project proposal. Instead of going insane with
> specifications, we decided to include some nice features we believe all
> OpenWrt supported platforms should have (e.g. being almost
> unbrickablewith multiple recovery options, hassle-free system console
> access, on-board RTC with battery backup etc.).
>
> This is our first design, so let's KiSS!
>
>
> Hardwarespecifications:
>
> * SOC: MediaTek MT7981B
> * Wi-Fi: MediaTek MT7976C (2x2 2.4 GHz + 3x3/2x2 + zero-wait DFS 5Ghz)
> * DRAM: 1 GiB DDR4
> * Flash: 128 MiB SPI NAND+ 4 MiB SPI NOR
> * Ethernet: 2x RJ45 (2.5 GbE + 1 GbE)
> * USB (host): USB 2.0 (Type-A port)
> * USB (device, console): Holtek HT42B534-2 UART to USB (USB-C port)
> * Storage: M.2 2042 for NVMe SSD (PCIe gen 2 x1)
> * Buttons: 2x (reset + user)
> * Mechanical switch: 1x for boot selection (recovery, regular)
> * LEDs: 2x (PWM driven), 2x ETH Led (GPIO driven)
> * External hardware watchdog: EM Microelectronic EM6324 (GPIO driven)
> * RTC: NXP PCF8563TS (I2C) with battery backup holder(CR1220)
> * Power: USB-PD-12V on USB-C port (optional802.3at/afPoE via RT5040 module)
> * Expansion slots: mikroBUS
> * Certification: FCC/EC/RoHS compliance
> * Case: PCB size is compatible to BPi-R4 and the case design can be re-used
> * JTAG for main SOC: 10-pin 1.27 mm pitch (ARM JTAG/SWD)
> * Antenna connectors: 3x MMCX for easy usage, assembly and durability
> * Schematics: these will be publicly available (license TBD)
> * GPL compliance: 3b. "Accompany it with a written offer ... to give any
> third party ... a complete machine-readable copy of the corresponding
> source code"
> * Price: aiming for below 100$
>
>
> How will the device be distributed?
>
> OpenWrt itself cannot handle this for a ton of reasons. This is why we
> spoke with the SFC early. The idea is that BPi will distribute the
> device using the already established channels and for every device sold
> a donation will be made to ourSFC earmarked fund for OpenWrt. This money
> can then be used to cover hosting expenses or maybe an OpenWrt summit.
>
> SFC is committed to working with us in various ways on this project —
> including making sure OpenWrt'strademark is properly respected, that
> this router isabeautiful example of excellent GPL/LGPL compliance,
> andthatthis becomes a great promotional opportunity for our project and
> FOSS generally!
>
>
> FAQ
>
> * Why are there are 2 different flash chips?
> - the idea is to make the device (almost!) unbrickable and very easy to
> recover
> - NAND will hold the main loader (U-Boot) and the Linux image and 

Re: OpenWrt One - celebrating 20 years of OpenWrt

2024-01-09 Thread John Crispin


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.


    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

2024-01-09 Thread Janusz Dziedzic
wt., 9 sty 2024 o 13:21 Daniel Golle  napisał(a):
>
> On Tue, Jan 09, 2024 at 12:56:55PM +0100, Robert Marko wrote:
> > ---SNIP---
> >
> > > Why not 6GHz?
> >
> > 6GHz requires an external card, and I doubt you can fit that in the
> > target price.
>
> Afaik we could use MT7976A as DBDC front-end supporting 2.4 GHz + 5/6 GHz
> instead of MT7976C which only supports 2.4 GHz + 5 GHz.
> However, that would still cover only two bands and most people will want
> 6 GHz *in addition* to the 5 GHz band and not instead.

Exactly, I think HW without 6GHz is useless this days.

___
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

2024-01-09 Thread John Crispin

On 09.01.24 12:58, Rafał Miłecki wrote:


So are you looking for just a generic interest feedback? Or some
technical comments? What are next steps for this project and do you
could use some community help?


just general feedback. it felt a bit weird to jump straight into voting.

    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

2024-01-09 Thread Daniel Golle
On Tue, Jan 09, 2024 at 12:56:55PM +0100, Robert Marko wrote:
> ---SNIP---
> 
> > Why not 6GHz?
> 
> 6GHz requires an external card, and I doubt you can fit that in the
> target price.

Afaik we could use MT7976A as DBDC front-end supporting 2.4 GHz + 5/6 GHz
instead of MT7976C which only supports 2.4 GHz + 5 GHz.
However, that would still cover only two bands and most people will want
6 GHz *in addition* to the 5 GHz band and not instead.

___
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

2024-01-09 Thread Rafał Miłecki

On 9.01.2024 11:49, John Crispin wrote:

If the community likes the idea outlined below in greater details, we would 
like to start a vote.


I'm afraid it's a bit unclear what do you expect here ;) People at IRC
started wondering too.

I love idea of this project and I'll surely be interested in buying
some units. I hope we can take care of some case with OpenWrt branding.

So are you looking for just a generic interest feedback? Or some
technical comments? What are next steps for this project and do you
could use some community help?

--
Rafał Miłecki

___
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

2024-01-09 Thread Robert Marko
---SNIP---

> Why not 6GHz?

6GHz requires an external card, and I doubt you can fit that in the
target price.

Regards,
Robert
>
> BR
>
>
> Janusz
>
> ___
> 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

2024-01-09 Thread Janusz Dziedzic
wt., 9 sty 2024 o 11:54 John Crispin  napisał(a):
>
> tl;dr
>
> In 2024 the OpenWrt project turns 20 years! Let's celebrate this
> anniversary by launching our own first and fully upstream supported
> hardware design.
>
> If the community likes the idea outlined below in greater details, we
> would like to start a vote.
>
> ---
>
> The idea
>
> It is not new. We first spoke about this during the OpenWrt Summits in
> 2017 and also 2018. It became clear start of December 2023 while
> tinkering with Banana Pi style devices that they are already pretty
> close to what we wanted to achieve in ’17/‘18. Banana PIs have grown in
> popularity within the community. They boot using a self compiled Trusted
> Firmware-A (TF-A)and upstream U-Boot (thx MTK/Daniel) and some of the
> boards are already fully supported by the upstream Linux kernel. The
> only nonopen sourcecomponents are the 2.5 GbE PHYandWi-Fi firmware
> blobsrunning on separate cores that areindependent of the main SoC
> running Linuxand the DRAM calibration routines which are executed early
> during boot.
>
> I contacted three project members (pepe2k, dangole, nbd) on December 6th
> to outline the overall idea. We went over several design proposals, 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. We would like to propose the following as
> our "first" community driven HW platform called "OpenWrt One/AP-24.XY".
>
> Together with pepe2k (thx a lot) I discussed this for many hours and we
> worked out the following project proposal. Instead of going insane with
> specifications, we decided to include some nice features we believe all
> OpenWrt supported platforms should have (e.g. being almost
> unbrickablewith multiple recovery options, hassle-free system console
> access, on-board RTC with battery backup etc.).
>
> This is our first design, so let's KiSS!
>
>
> Hardwarespecifications:
>
> * SOC: MediaTek MT7981B
> * Wi-Fi: MediaTek MT7976C (2x2 2.4 GHz + 3x3/2x2 + zero-wait DFS 5Ghz)

Why not 6GHz?

BR


Janusz

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


OpenWrt One - celebrating 20 years of OpenWrt

2024-01-09 Thread John Crispin

tl;dr

In 2024 the OpenWrt project turns 20 years! Let's celebrate this 
anniversary by launching our own first and fully upstream supported 
hardware design.


If the community likes the idea outlined below in greater details, we 
would like to start a vote.


---

The idea

It is not new. We first spoke about this during the OpenWrt Summits in 
2017 and also 2018. It became clear start of December 2023 while 
tinkering with Banana Pi style devices that they are already pretty 
close to what we wanted to achieve in ’17/‘18. Banana PIs have grown in 
popularity within the community. They boot using a self compiled Trusted 
Firmware-A (TF-A)and upstream U-Boot (thx MTK/Daniel) and some of the 
boards are already fully supported by the upstream Linux kernel. The 
only nonopen sourcecomponents are the 2.5 GbE PHYandWi-Fi firmware 
blobsrunning on separate cores that areindependent of the main SoC 
running Linuxand the DRAM calibration routines which are executed early 
during boot.


I contacted three project members (pepe2k, dangole, nbd) on December 6th 
to outline the overall idea. We went over several design proposals, 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. We would like to propose the following as 
our "first" community driven HW platform called "OpenWrt One/AP-24.XY".


Together with pepe2k (thx a lot) I discussed this for many hours and we 
worked out the following project proposal. Instead of going insane with 
specifications, we decided to include some nice features we believe all 
OpenWrt supported platforms should have (e.g. being almost 
unbrickablewith multiple recovery options, hassle-free system console 
access, on-board RTC with battery backup etc.).


This is our first design, so let's KiSS!


Hardwarespecifications:

* SOC: MediaTek MT7981B
* Wi-Fi: MediaTek MT7976C (2x2 2.4 GHz + 3x3/2x2 + zero-wait DFS 5Ghz)
* DRAM: 1 GiB DDR4
* Flash: 128 MiB SPI NAND+ 4 MiB SPI NOR
* Ethernet: 2x RJ45 (2.5 GbE + 1 GbE)
* USB (host): USB 2.0 (Type-A port)
* USB (device, console): Holtek HT42B534-2 UART to USB (USB-C port)
* Storage: M.2 2042 for NVMe SSD (PCIe gen 2 x1)
* Buttons: 2x (reset + user)
* Mechanical switch: 1x for boot selection (recovery, regular)
* LEDs: 2x (PWM driven), 2x ETH Led (GPIO driven)
* External hardware watchdog: EM Microelectronic EM6324 (GPIO driven)
* RTC: NXP PCF8563TS (I2C) with battery backup holder(CR1220)
* Power: USB-PD-12V on USB-C port (optional802.3at/afPoE via RT5040 module)
* Expansion slots: mikroBUS
* Certification: FCC/EC/RoHS compliance
* Case: PCB size is compatible to BPi-R4 and the case design can be re-used
* JTAG for main SOC: 10-pin 1.27 mm pitch (ARM JTAG/SWD)
* Antenna connectors: 3x MMCX for easy usage, assembly and durability
* Schematics: these will be publicly available (license TBD)
* GPL compliance: 3b. "Accompany it with a written offer ... to give any 
third party ... a complete machine-readable copy of the corresponding 
source code"

* Price: aiming for below 100$


How will the device be distributed?

OpenWrt itself cannot handle this for a ton of reasons. This is why we 
spoke with the SFC early. The idea is that BPi will distribute the 
device using the already established channels and for every device sold 
a donation will be made to ourSFC earmarked fund for OpenWrt. This money 
can then be used to cover hosting expenses or maybe an OpenWrt summit.


SFC is committed to working with us in various ways on this project — 
including making sure OpenWrt'strademark is properly respected, that 
this router isabeautiful example of excellent GPL/LGPL compliance, 
andthatthis becomes a great promotional opportunity for our project and 
FOSS generally!



FAQ

* Why are there are 2 different flash chips?
- the idea is to make the device (almost!) unbrickable and very easy to 
recover
- 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 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


* 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


* 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


*