Re: Mark lantiq and omap as source only
Hi Paul, > I haven’t seen much progress happening regarding bringing the targets lantiq > or omap to Kernel 5.15. That fact is currently the last blocker for branching > another release. > Instead of postponing another release I’d like to mark both targets as > source-only and do the 23.05 branch, starting with a RC0. If either of the > two targets are fixed within the RC phase, they should be re-added, as > discussed during the last meeting. what are the problems with lantiq 5.15? For omap: - The upstream kernel changed the ethernet default and the driver will use 2 static vlan ids (configurable via dts) to tag the traffic of port 1 and port 2. ACK for OMAP. I'll try to fix it before the release. Best, lynxis ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
new musl libc release 1.2.4 (2023-05-01) (was Re: [musl] busybox problem on powerpc PPC/32bit (hardware TP-Link-WDR-4900-v1))
On Sun, Feb 12, 2023 at 05:34:43PM -0500, Rich Felker wrote: > On Sun, Feb 12, 2023 at 08:17:04AM +, Bastian Bittorf wrote: > > On Sat, Feb 11, 2023 at 02:30:44PM -0500, Rich Felker wrote: > > > > > .hidden __hwcap > > > > > .long __hwcap-. > > > > > -1: mflr 4 > > > > > - lwz 5, 0(4) > > > > > - lwzx 4, 4, 5 > > > > > - andis. 4, 4, 0x80 > > > > > +1: mflr 6 > > > > > + lwz 5, 0(6) > > > > > + lwzx 6, 6, 5 > > > > > + andis. 6, 6, 0x80 > > > > > beq 1f > > > > > .long 0x11c35b01 /* evldd 14,88(3) */ > > > > > .long 0x11e36301 /* ... */ > > > > It works! New musl release including this fix is out: https://musl.libc.org/releases/musl-1.2.4.tar.gz Is anybody already working on upgrading musl for OpenWRT? bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Objective of OpenWRT/x86?
> On May 1, 2023, at 6:59 PM, Alberto Bursi wrote: > > > > On 01/05/23 06:40, Philip Prindeville wrote: >>> On Apr 28, 2023, at 11:18 PM, Elliott Mitchell wrote: >>> >>> On Fri, Apr 28, 2023 at 12:04:15PM -0600, Philip Prindeville wrote: > [snip] >>> See above: the radios and antennae I can get as add-ons for a Xeon-D 1U pizza box or even an APU6 mPCIe slot are vastly inferior to what ODM purpose-built hardware like an U6-LR can do in terms of cost and performance. Um... you can't "virtualize" WiFi in any VM I've ever seen. >>> >>> You can though pass PCIe devices to a VM. The hardware will physically >>> attach to the control host, but a VM will be able to do anything it wants >>> with it. >> So the guest has the potential to crash or hang the host? > > Passthrough devices aren't really handled by the host OS (it's commonly > required to blacklist their kernel drivers to make sure the host does NOT > touch them) so in most cases if something hard-crashes and a kernel panics > it's still all drama that happens inside the VM. This is how it usually goes > in my experience. > > GPU passthrough can cause a whole host to lock up and require power cycle. > I've seen that happen in the wild only once (it was repeatable, fun times), > but imho it's a IOMMU or GPU issue not a "normal" thing that should happen. > > -Alberto You can also lock up the PCIe bus so that the CPU can't access the bus or bus-attached devices like disk controllers, network interfaces, etc. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt vs Defense positions
On Tue, May 2, 2023 at 6:24 AM Peter Naulls wrote: > > Another impression I have, is that the OpenWrt project is very important > > for many yet under-resourced. > > There are some important tasks that would help with the long-term > > maintenance (e.g. merging of the mtk_nand for > > Does anyone know how much > > contributions come from people working for companies in OpenWrt? >> Who knows. I will say that OpenWrt has formed a large part of my career. As > measured by patches (which frankly, is something of a time-consuming hurdle), > my > contributions are very very small, but all my OpenWrt work has been under > companies. Embedded Linux was, until recently, my "career" since 1997 or so, when I started working with the handhelds.org project, and later worked at MontaVista. Very little of what I have done since 2003 was under corporate aegis. CeroWrt, and the five years spent reworking the Linux wifi stack in make-wifi-fast came out of my savings, mostly, with a bit of support from comcast, nlnet, and gfiber. When I failed to get a round of external funding to keep the project alive, after we heaved the most core fq_codel bits over the wall, I gave up. There are still bugs left over in that, hanging over my head, no-one else has been able to solve. The wifi industry as a whole took a major wrong turn that perhaps wifi7 will get it out of, but I don´t know. There are so many other problems in embedded linux today, not least of which is the failure to keep up with mainline linux. Complexity collapse seems nigh!, and the skills required to cross compile stuff seem to be fading. Of particular irony for me persists in the initial joy I had felt upon learning Starlink was using openwrt, only to find that even their most recent product is leveraging... wait for it... LEDE, and so locked down as to be impossible to upgrade. Going back to the original subject of this thread, I would hope that more cash spent on testing and securing openwrt would come from *somewhere*. > > > -- Podcast: https://www.linkedin.com/feed/update/urn:li:activity:7058793910227111937/ Dave Täht CSO, LibreQos ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt vs Defense positions
On Tue, May 02, 2023 at 09:34:01AM -0400, Peter Naulls wrote: > On 5/2/23 09:31, Enrico Mioso wrote: > > On Tue, May 02, 2023 at 09:24:52AM -0400, Peter Naulls wrote: > > > On 5/2/23 07:26, Enrico Mioso wrote: > > > > > > > > Another impression I have, is that the OpenWrt project is very > > > > important for many yet under-resourced. > > > > There are some important tasks that would help with the long-term > > > > maintenance (e.g. merging of the mtk_nand for mt7621 and the upstrema > > > > one, if at all possible), which require time and highly motivated > > > > person to carry on. > > > > > > I was that person, but at this point, the upstream m7621 NAND driver works > > > correctly, *except* when the MMC is also enabled. The mtk_nand driver is > > > very old and I did get it to run correctly for reads under current kernel, > > > but it > > > didn't seem to have any further value here, and many obvious faults - see > > > my > > > discussion on this a few months back. If there's specific work you know > > > of > > > here, I'd be very interested. > > > > Thanks for your reply. > > > > No, I don't know wether work is ongoing on that at the moment, sorry. > > Yes, but there must have been some issue that caused this comment - is there > some backstory here? Oh no, I was just thinking about this in "long-term maintenance" terms. > > Enrico ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt vs Defense positions
On 5/2/23 09:31, Enrico Mioso wrote: On Tue, May 02, 2023 at 09:24:52AM -0400, Peter Naulls wrote: On 5/2/23 07:26, Enrico Mioso wrote: Another impression I have, is that the OpenWrt project is very important for many yet under-resourced. There are some important tasks that would help with the long-term maintenance (e.g. merging of the mtk_nand for mt7621 and the upstrema one, if at all possible), which require time and highly motivated person to carry on. I was that person, but at this point, the upstream m7621 NAND driver works correctly, *except* when the MMC is also enabled. The mtk_nand driver is very old and I did get it to run correctly for reads under current kernel, but it didn't seem to have any further value here, and many obvious faults - see my discussion on this a few months back. If there's specific work you know of here, I'd be very interested. Thanks for your reply. No, I don't know wether work is ongoing on that at the moment, sorry. Yes, but there must have been some issue that caused this comment - is there some backstory here? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt vs Defense positions
On Tue, May 02, 2023 at 09:24:52AM -0400, Peter Naulls wrote: > On 5/2/23 07:26, Enrico Mioso wrote: > > On Mon, May 01, 2023 at 04:56:36PM -0400, Peter Naulls wrote: > > > On 5/1/23 16:42, Dave Taht wrote: > > > > > > > > > > one of the constraints OpenWrt has been placed under, historically, is the > > need to fit in small flash memoris, so fitting some libraries and > > infrastructure maybe a little bit of a stretch here. > > Furthermore, OpenWrt has been tought to be a platform, not a "finished" > > solution: this is not meant bo be an "excluse", just to note that some > > particular problems, and their solutions, have not been integrated in the > > core. > > In some cases, like for ModemManager, the problems where related to size > > and complexity, I think. > > Yes, although that's more historic; one of the reasons we did in fact go to > NAND below is due to size constraints; and indeed with ModemManager. It > took us a long time to get ModemManager working how we liked it, since it's > not a 100% > solution all by itself, and our needs are very specific. > > > > Another impression I have, is that the OpenWrt project is very important > > for many yet under-resourced. > > There are some important tasks that would help with the long-term > > maintenance (e.g. merging of the mtk_nand for mt7621 and the upstrema one, > > if at all possible), which require time and highly motivated person to > > carry on. > > I was that person, but at this point, the upstream m7621 NAND driver works > correctly, *except* when the MMC is also enabled. The mtk_nand driver is > very old and I did get it to run correctly for reads under current kernel, > but it > didn't seem to have any further value here, and many obvious faults - see my > discussion on this a few months back. If there's specific work you know of > here, I'd be very interested. Thanks for your reply. No, I don't know wether work is ongoing on that at the moment, sorry. Enrico > > > > As for what will happen with OpenWrt when it will become used in some > > important places, I don't have an answer of course. > > Does anyone know how much contributions come from people working for > > companies in OpenWrt? > > Who knows. I will say that OpenWrt has formed a large part of my career. As > measured by patches (which frankly, is something of a time-consuming > hurdle), my > contributions are very very small, but all my OpenWrt work has been under > companies. > > > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt vs Defense positions
On 5/2/23 07:26, Enrico Mioso wrote: On Mon, May 01, 2023 at 04:56:36PM -0400, Peter Naulls wrote: On 5/1/23 16:42, Dave Taht wrote: one of the constraints OpenWrt has been placed under, historically, is the need to fit in small flash memoris, so fitting some libraries and infrastructure maybe a little bit of a stretch here. Furthermore, OpenWrt has been tought to be a platform, not a "finished" solution: this is not meant bo be an "excluse", just to note that some particular problems, and their solutions, have not been integrated in the core. In some cases, like for ModemManager, the problems where related to size and complexity, I think. Yes, although that's more historic; one of the reasons we did in fact go to NAND below is due to size constraints; and indeed with ModemManager. It took us a long time to get ModemManager working how we liked it, since it's not a 100% solution all by itself, and our needs are very specific. Another impression I have, is that the OpenWrt project is very important for many yet under-resourced. There are some important tasks that would help with the long-term maintenance (e.g. merging of the mtk_nand for mt7621 and the upstrema one, if at all possible), which require time and highly motivated person to carry on. I was that person, but at this point, the upstream m7621 NAND driver works correctly, *except* when the MMC is also enabled. The mtk_nand driver is very old and I did get it to run correctly for reads under current kernel, but it didn't seem to have any further value here, and many obvious faults - see my discussion on this a few months back. If there's specific work you know of here, I'd be very interested. As for what will happen with OpenWrt when it will become used in some important places, I don't have an answer of course. Does anyone know how much contributions come from people working for companies in OpenWrt? Who knows. I will say that OpenWrt has formed a large part of my career. As measured by patches (which frankly, is something of a time-consuming hurdle), my contributions are very very small, but all my OpenWrt work has been under companies. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt vs Defense positions
On Mon, May 01, 2023 at 04:56:36PM -0400, Peter Naulls wrote: > On 5/1/23 16:42, Dave Taht wrote: > > > > > How a ragtag bunch of unincorporated (mostly?) peacenik hippie types > > can co-exist with devices being built by militaries out of this stuff > > I have few ideas. I prefer to shrink the world, and produce stable, > > secure, software, for everyone that wants it, but I look at the > > contentious places where it also goes (like space, or spacex) and > > wonder how it will all end up, and who will maintain it, improve it, > > or attempt to subvert it. > > Yes, and on a parallel note about security (not "Security" aka Defense), > OpenWrt is good, but not excellent. This has been a long term interest > of mine, largely due to career need rather than enthusiasm per se - the > product I'm working on now has been through multiple security reviews - much > of it without question is theater. > > See a discussion I started on this some months ago - there's been a bit > of a historic lack of appetite for this topic, partly because some of > the theater is certainly high-class nonsense, and partly because of lack of > resources - OpenWrt doesn't really have a dedicated security effort (if I > missed > something in recent months than I apologize), and some of the suggestions > I've made have gone into the ether. My 2 cents: one of the constraints OpenWrt has been placed under, historically, is the need to fit in small flash memoris, so fitting some libraries and infrastructure maybe a little bit of a stretch here. Furthermore, OpenWrt has been tought to be a platform, not a "finished" solution: this is not meant bo be an "excluse", just to note that some particular problems, and their solutions, have not been integrated in the core. In some cases, like for ModemManager, the problems where related to size and complexity, I think. Another impression I have, is that the OpenWrt project is very important for many yet under-resourced. There are some important tasks that would help with the long-term maintenance (e.g. merging of the mtk_nand for mt7621 and the upstrema one, if at all possible), which require time and highly motivated person to carry on. As for what will happen with OpenWrt when it will become used in some important places, I don't have an answer of course. Does anyone know how much contributions come from people working for companies in OpenWrt? Enrico > > Still, I think there's a growing recognition of its use - certainly > many home routers and no little number of special-user routers run it > as well as commercial applications and of course the original topic > I raised. OpenWrt now has vastly more clout in the world than superficial > visibility would suggest. > > > > ___ > 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
