Re: OpenWrt One - celebrating 20 years of OpenWrt
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
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
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
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
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
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
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
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
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
subscribe
smime.p7s Description: S/MIME cryptographic signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
odhcpd PRs
Please take a look at the PRs here: https://github.com/openwrt/odhcpd/pulls They need some attention :) ___ 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
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: PKG_MAINTAINER_HANDLE
On 2024-01-08 16:03, Paul Spooren wrote: Hi Paul, PKG_MAINTAINER:=Joe Bloggs PKG_MAINTAINER_HANDLE:=github: @joe; https://forum.openwrt.org/u/joe/ Plan B co-opt existing PKG_MAINTAINER field, but perhaps it's possible? e.g: PKG_MAINTAINER:=Joe Bloggs , github: @Joe I think for that you could use a Codeowners file. Best, Paul In this case, what takes priority? If both Codeowners and Makefile PKG_MAINTAINER exist, which is preferred? Do we only expect handles in Codeowners and PKG_MAINTAINER email in Makefile? Codeowners lives side-by-side with Makefile or repo root? I dislike information spread across several different places: it further behoves the hunt to track down relevant information. Today to make a PR, I already have to spend five minutes chasing this info down if I want things to stand a chance of going smoothly, initially. This is friction for newcomers and for low-hanging-fruit fixes. If all of the information is in one place, it's easy (easier). ___ 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
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
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
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: GPON project?
On Tue, 9 Jan 2024 at 14:59, Dave Taht wrote: > > Honestly, if progress is not made towards making GPON accessible in > FOSS, the next generation of fiber routers will be as locked down as > cablemodems are. While I do know of many ISPs using active ethernet > fiber instead, GPON is big in some places. Considering that GPON isn't a new thing and is rather widely deployed (At least in Europe) it would be awesome for FOSS products to exist but I have yet to see any progress made towards it despite the specification itself being public, but the drivers/blobs that actually interact with (mostly Realtek) GPON SoC-s are currently black boxes. I am unaware of any project working towards FOSS GPON or XGPON(Or any new 10G variants). Regards, Robert > > On Tue, Jan 9, 2024 at 7:39 AM Robert Marko wrote: > > > > 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) > >
Re: OpenWrt One - celebrating 20 years of OpenWrt
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
GPON project?
Honestly, if progress is not made towards making GPON accessible in FOSS, the next generation of fiber routers will be as locked down as cablemodems are. While I do know of many ISPs using active ethernet fiber instead, GPON is big in some places. On Tue, Jan 9, 2024 at 7:39 AM Robert Marko wrote: > > 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
Re: OpenWrt One - celebrating 20 years of OpenWrt
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
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
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
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
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
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
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
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
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
---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
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
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 *
Re: [PATCH dt-schema] schemas: chosen: Add OpenWrt LEDs properties for system states
On 09/01/2024 09:23, Rafał Miłecki wrote: > From: Rafał Miłecki > > OpenWrt project provides downstream support for thousands of embedded > home network devices. Its custom requirement for DT is to provide info > about LEDs roles. Currently it does it by using custom non-documented > aliases. While formally valid (aliases.yaml doesn't limit names or > purposes of aliases) it's quite a loose solution. > > Document 4 precise "chosen" biding properties with clearly documented > OpenWrt usage. This will allow upstreaming tons of DTS files that noone typo: none > cared about so far as those would need to be patched downstream anyway. From all this description I understand why you want to add it, but I don't understand what are you exactly adding and how it is being used by the users/OS. > > Signed-off-by: Rafał Miłecki > --- > A few weeks ago I was seeking for a help regarding OpenWrt's need for > specifing LEDs roles in DT, see: > > Describing LEDs roles in device tree? > https://lore.kernel.org/linux-devicetree/ee912a89-4fd7-43c3-a79b-16659a035...@gmail.com/T/#u > > I DON'T think OpenWrt's current solution with aliases is good enough: > * It's not clearly documented > * It may vary from other projects usa case > * It may be refused by random maintainers I think > > I decided to suggest 4 OpenWrt-prefixed properties for "chosen". I'm > hoping this small custom binding is sth we could go with. I'm really > looking forward to upstreaming OpenWrt's downstream DTS files so other > projects (e.g. Buildroot) can use them. > > If you have any better fitting solution in mind please let me know. I > should be fine with anything that lets me solve this downstream mess > situation. > > dtschema/schemas/chosen.yaml | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/dtschema/schemas/chosen.yaml b/dtschema/schemas/chosen.yaml > index 6d5c3f1..96d0db7 100644 > --- a/dtschema/schemas/chosen.yaml > +++ b/dtschema/schemas/chosen.yaml > @@ -264,4 +264,13 @@ properties: > patternProperties: >"^framebuffer": true > > + "^openwrt,led-(boot|failsafe|running|upgrade)$": > +$ref: types.yaml#/definitions/string > +description: > + OpenWrt choice of LED for a given role. Neither this explains it. What is "OpenWrt choice"? Choice like what? What are the valid choices? > Value must be a full path (encoded > + as a string) to a relevant LED node. What do you mean by full path? DT node path? Then no, use phandles. Anyway, we have existing properties for this - LED functions. Just choose LED with given function (from sysfs) and you are done. If function is missing in the header: feel free to go, least for me. Also: please Cc LED maintainers on all future submissions of this. Best regards, Krzysztof ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH dt-schema] schemas: chosen: Add OpenWrt LEDs properties for system states
From: Rafał Miłecki OpenWrt project provides downstream support for thousands of embedded home network devices. Its custom requirement for DT is to provide info about LEDs roles. Currently it does it by using custom non-documented aliases. While formally valid (aliases.yaml doesn't limit names or purposes of aliases) it's quite a loose solution. Document 4 precise "chosen" biding properties with clearly documented OpenWrt usage. This will allow upstreaming tons of DTS files that noone cared about so far as those would need to be patched downstream anyway. Signed-off-by: Rafał Miłecki --- A few weeks ago I was seeking for a help regarding OpenWrt's need for specifing LEDs roles in DT, see: Describing LEDs roles in device tree? https://lore.kernel.org/linux-devicetree/ee912a89-4fd7-43c3-a79b-16659a035...@gmail.com/T/#u I DON'T think OpenWrt's current solution with aliases is good enough: * It's not clearly documented * It may vary from other projects usa case * It may be refused by random maintainers I think I decided to suggest 4 OpenWrt-prefixed properties for "chosen". I'm hoping this small custom binding is sth we could go with. I'm really looking forward to upstreaming OpenWrt's downstream DTS files so other projects (e.g. Buildroot) can use them. If you have any better fitting solution in mind please let me know. I should be fine with anything that lets me solve this downstream mess situation. dtschema/schemas/chosen.yaml | 9 + 1 file changed, 9 insertions(+) diff --git a/dtschema/schemas/chosen.yaml b/dtschema/schemas/chosen.yaml index 6d5c3f1..96d0db7 100644 --- a/dtschema/schemas/chosen.yaml +++ b/dtschema/schemas/chosen.yaml @@ -264,4 +264,13 @@ properties: patternProperties: "^framebuffer": true + "^openwrt,led-(boot|failsafe|running|upgrade)$": +$ref: types.yaml#/definitions/string +description: + OpenWrt choice of LED for a given role. Value must be a full path (encoded + as a string) to a relevant LED node. + + Property user may use specified path to control proper LED during current + system boot phase. + additionalProperties: false -- 2.35.3 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
