Re: Upstream U-Boot for Linksys WRT1900ACS V2
On Fri, Jul 31, 2026 at 01:26:39PM +, Brice GIBOUDEAU wrote: > Yes I can provide a set of patchs and contribute to your version but for that > there is two things we should tackle before. > - If you have a reference on how to contribute to OpenWrt the proper way > please share it. The best would be (unfortuantely) to use a Github pull request as that triggers a lot of CI to statically analyse, test-build and have some bots look at your work. If you don't want to use Github, sending a patch series using git-format-patch or git-send-email to this mailing list is also acceptable. Read this: https://openwrt.org/submitting-patches > - I would like to enable other routers before pushing this to OpenWrt > official repo. For now there is only one Board. I need contributors before to > extend a bit what I have done that is very specific to one hardware release. While uboot-mvebu (like all uboot-* packages) covers a whole SoC family, a build is by nature always for a single specific board. Getting more boards supported is of course always nice, but by no means required to first add support for a specific single board. Having that in our repo and automatically generating (~ daily) snapshot builds will also give it more visibility, and more likely attract testers and other contributors to work on similar boards with the same SoC. Out of experience, once a first boards is supported, many other boards based on the same SoC follow quickly. That being said, a platform-specific README covering the recovery methods available (JTAG, some BootROM feature to load from the UART or via USB, or load from external/removable storage...) which come handy during development or with a bricked board is of course also appreciated and will help others with similar boards to dare to attack theirs without being afraid of producing a brick and needing to wire up the flash chip to an external programmer. Cheers Daniel > > Regards > > "Daniel Golle" [email protected] – July 31, 2026 at 3:00 PM > > Hi, > > > > On Fri, Jul 31, 2026 at 01:24:43PM +0200, Brice GIBOUDEAU via openwrt-devel > > wrote: > > > Hello, > > > > > > I’m sharing some work I did to fix a mistake I did by erasing my U-Boot > > > without a backup… yes I know ;-) > > > > > > If this work can be useful for some of you I put the link to the repo > > > below and if some of you want to enable it on other WRTxxx products don’t > > > hesitate to contribute. > > > > > > My work is based on the upstream version of U-Boot and not the very aging > > > version provided by Linksys. > > > > > > You can find it here: > > > > > > https://github.com/TheMiNuS/wrt1900acsv2-uboot > > > > We generally like to host replacement (and enhanced) loaders for > > supported devices. The way do this is typically a set of patches > > including defconfig and maybe a default environment, on top of > > mainline U-Boot. In this particular case, imho it would be the best to > > extend > > https://github.com/openwrt/openwrt/tree/main/package/boot/uboot-mvebu > > instead of having a patch set (leave alone an opqaue source tree) for > > a single board. If you can extract your work into patches to be > > applied there, that would be the best. Create all patches in a way > > that can be applied upstream -- not all of your work may be suitable > > or target upstream, but hardware drivers and defconfig typically the > > answer is typically 'yes'. > > > > If you have questions or need any help with that, let me know. > > > > ___ > > openwrt-devel mailing list > > [email protected] > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > > ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Upstream U-Boot for Linksys WRT1900ACS V2
Hi, On Fri, Jul 31, 2026 at 01:24:43PM +0200, Brice GIBOUDEAU via openwrt-devel wrote: > Hello, > > I’m sharing some work I did to fix a mistake I did by erasing my U-Boot > without a backup… yes I know ;-) > > If this work can be useful for some of you I put the link to the repo below > and if some of you want to enable it on other WRTxxx products don’t hesitate > to contribute. > > My work is based on the upstream version of U-Boot and not the very aging > version provided by Linksys. > > You can find it here: > > https://github.com/TheMiNuS/wrt1900acsv2-uboot We generally like to host replacement (and enhanced) loaders for supported devices. The way do this is typically a set of patches including defconfig and maybe a default environment, on top of mainline U-Boot. In this particular case, imho it would be the best to extend https://github.com/openwrt/openwrt/tree/main/package/boot/uboot-mvebu instead of having a patch set (leave alone an opqaue source tree) for a single board. If you can extract your work into patches to be applied there, that would be the best. Create all patches in a way that can be applied upstream -- not all of your work may be suitable or target upstream, but hardware drivers and defconfig typically the answer is typically 'yes'. If you have questions or need any help with that, let me know. ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: BondingShouldBeFree Open-source Network Aggregation & Redundancy Solution
On Sat, May 23, 2026 at 06:46:33PM +, Chester A. Unal wrote: > On 23/05/2026 17:34, Jonas Lochmann wrote: > > Am Sat, May 23, 2026 at 02:03:17PM +, schrieb Chester A. Unal: > > > Daniel, Jonas. > > > > > > I've been keeping track of MP-QUIC for a while now. The RFC is still a > > > draft but there's a working group and they're making steady progress, last > > > I checked a few months ago. I'm waiting for the RFC to finalise and have a > > > proper implementation ready before I try it. > > > > I am also waiting to see the end result. Not only what the implementations > > provide but how common its deployment will be. > > > > With OpenWrt and IPv6, it works out of the box to let the clients know > > that they are in multiple IPv6 subnets and the clients pick one IP > > per subnet. I once developed a local proxy server application that > > randomly chose one source IP/subnet per TCP socket because the default > > address selection is deterministic and does not distribute load over > > multiple links. However, with a good MP-QUIC result, the usage of > > multiple uplinks would work automatically in this case, without my > > extra proxy server and maybe with load distribution within one stream. > > Failover is already part of the regular QUIC. > > True. The problem with MPTCP is, and this should apply to MP-QUIC too, the > host that creates the connections usually does not have access to the > multiple paths. It's usually a router in between that does. In IPv6-enabled deployments (which are becoming the norm, also because of the v4 address shortness) this is radically different, multi-homing all the way to the edge is common. > That's why, > even if every host on the internet supported MPTCP or MP-QUIC, you'd still > need to run a proxy programme on your router to be able to utilise multiple > paths. True for IPv4 legacy Internet access where the router does NAT, not true for IPv6. ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: BondingShouldBeFree VPN
On Sat, May 23, 2026 at 03:00:50PM +0200, Jonas Lochmann wrote: > I am combining multiple internet connections since many years for > companies based on cheap consumer internet connections. So I know > the topic and the possible solutions. > > When I looked last time into it, MPTCP was basically nowhere > supported. No protocol is useful if the other endpoint does not > support it. While QUIC is currently pushed, the multi path version > of it is not and it does not seem to distribute load well. > Did that change recently? > > So you either depend on the other end supporting the protocol you > like or you make a tunnel. That's what you do according to the forum > posts. So in the end, you are selling a VPN with another marketing > than your competitors. You can run the server-side yourself, so from what I understood the "sale" here is mostly for a (open) protocol stack to implement asymmetric link aggregation (as opposed to using proprietary, vendor-specific solutions to do the same thing, eg. MikroTik) > > > I provide services to ISPs and other interested parties to implement > > the solution to their infrastructure. Contact me here. > > Why should an ISP care about that? In my country, there is an ISP > selling a bonded solution but this is an expensive ISP and even > with bonding cheaper ISPs provide better connectivity. It looks > like this ISP bought some hardware/software solution for that that > includes their network infrastructure and the device for the end user. Not all (esp. wireless) ISPs operate on their own physical infrastructure. Some developing countries still rely primarily on 4G/5G mobile backhaul, or even copper for the last mile. And especially in those emerging markets aggregating multile mobile network uplinks of different operator networks is the only way to gain reliable connectivity. ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] econet: add EN751627 subtarget and ZyXEL EX3301-T0 support
On Thu, Apr 16, 2026 at 12:18:18PM +0200, Caleb James DeLisle wrote: > > On 16/04/2026 09:20, [email protected] wrote: > > Thanks for your notes, I'm taking this as a teachable moment because > > I need to learn more about this process and device - I don't know how > > this device can boot and run if you target 24kc in the mkimage. > > There are a fair few devices that are 1004kc, e.g. MT7621, they work as 24kc > - though I imagine they may be a little bit slower because they don't use > all of the CPU instructions. Yes, 24kc code should on 1004kc. Just 4k (ie. old MIPS R1 ABI instead of MIPS R2) doesn't. ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Activated Claude Code review on new PRs
On Wed, Apr 15, 2026 at 01:53:55AM +0200, Hauke Mehrtens wrote: > Review this OpenWrt pull request for problems and policy violations. Many of the prompt instructions seem redundant with the mechanical existing CI. I'd not include them here again, it's a waste of resources, as the classic CI costs a fraction -- and LLMs are not actually that good doing those mechanical and precisely defined things. It could be better to ask the LLM to create scripts to carry out those mechanical tasks than telling it to actually perform them by itself. Also, asking for more abstract things like "check if the commit message accurately describes the intention of the author as well as ALL the changes made by the commit" can work well. Apart from that, imho this is a very good source of inspiration when it comes to this class of tasks, (and you probably know it): https://github.com/masoncl/review-prompts Having some useful MCPs accessible during a code review also makes the results much better -- compare it to having a hammer and a wrench, or having to use your bare hands for the same task. eg. https://github.com/facebookexperimental/semcode (which is used heavily by the review-prompts above) Just my 2 cents... > > Check every commit in the PR for the following. Report each problem > as an inline comment on the relevant line, or in the top-level > comment when there is no specific line to attach it to. > Compare the changes with other commits to similar files. > When new files like new dts files are added compare them to the existing > files if they follow the same style. > > ## Commit message rules (CI-enforced — hard failures) > > - Subject line must match `: `. > The description must start with a lowercase letter. > - Commit body must not be empty (only a Signed-off-by line is not enough > - GitHub noreply addresses are rejected. > - The name and email in Signed-off-by must exactly match the commit author > field. > - Subject line must not end with a period. > - The commit body must not start with "This PR …" — write in imperative form > as if it is the commit message, not a PR description. > > ## PR structure > > - No merge commits. The branch must be rebased on top of main. > - Each commit must be a self-contained logical change. A later > commit must not undo or partially revert an earlier one in the > same series. > - Draft PRs ([WIP] or GitHub Draft state) are acceptable while > hardware testing is ongoing, but flag if a non-draft PR > appears to lack hardware testing evidence. > > ## Kernel patches > > - Kernel patches that are not OpenWrt-specific (no OpenWrt > dependencies) should be submitted upstream to the Linux kernel > mailing list. Flag any such patches and suggest upstreaming. > - Kernel patch files must have a properly git patch header > - Check that patches are placed in the correct directory > (e.g. `pending-` vs `backport`). > > ## DTS / Device Tree files > > - Use the new array syntax for `reg` and similar properties. > - LED nodes must use `color` and `function` properties — the deprecated > `label` property must not be used. > - MAC addresses must be assigned via `nvmem` cells in DTS, not hardcoded or > left to random assignment at boot. > - `label-mac-device` must point to the interface whose MAC address is > printed on the device label sticker. > - Bootloader and factory partitions must have `read-only`. > - Multiple `compatible` strings must be separate quoted entries on one line, > not a single string with a comma inside. > - `device_type` must not appear except on `memory` and `cpu` nodes. > > ## New device support > > The commit message for any new device must include: > - Hardware specs: SoC, RAM, flash size and type, Ethernet ports, > WiFi chips and bands, LEDs, buttons, USB ports. > - Serial/UART console pinout (GND, RX, TX, VCC) and baud rate. > - MAC address assignment table for every interface (LAN, WAN, > 2.4 GHz, 5 GHz) and confirmation they match vendor firmware. > - Step-by-step installation instructions (factory and sysupgrade). > - Recovery instructions (how to return to stock firmware). > > > ## Platform-specific checks > > - **qualcommax**: WiFi board data must be submitted to > `openwrt/firmware_qca-wireless` first; the Makefile hash must > be updated in the same PR. > > ## Coding style > > - Match the indentation style of the surrounding file. > - No accidental file mode changes (+x on non-executable files). > - Sort list entries (dependencies, device profiles) alphabetically. > - Run `./scripts/checkpatch.pl` on kernel C patches — flag any > obvious checkpatch violations visible in the diff. > > ## Output rules > > - For every problem tied to a specific file and line number, call > mcp__github_inline_comment__create_inline_comment to post an > inline comment directly on that diff line. > - For problems not tied to a specific line (e.g. missing commit > body, wrong author), include them in the top-level comment. > - Do
Re: Banana Pi-R4 (Pro) uboot status
On Mon, Mar 09, 2026 at 12:01:56PM -0600, Philip Prindeville wrote: > > > > On Mar 9, 2026, at 11:17 AM, Daniel Golle wrote: > > > > On Mon, Mar 09, 2026 at 11:04:29AM -0600, Philip Prindeville via > > openwrt-devel wrote: > >> Hi, > >> > >> What is the status of uboot on the variants of the BPi-R4? I have a > >> couple of Pro's I'd like to be able to boot from NVMe, as called out last > >> August. Checking in to see what progress there's been. > > > > No such feature is planned at the moment for OpenWrt, as replied back > > then. This may change once standatization of OpenWrt's boot method has > > been completed, as that would include booting off arbitrary storage > > devices, including NVMe or removable USB storage. > > > > See also > > https://github.com/openwrt/openwrt/pull/22177 > > Yow. That's a big commit. Besides not passing the formalities checks, what > else is gating it? It's a tech demo which allows testing the upstream submission for U-Boot and the flat-image-tree spec. The suggested changes are discussed at the respective upstream projects. ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Banana Pi-R4 (Pro) uboot status
On Mon, Mar 09, 2026 at 11:04:29AM -0600, Philip Prindeville via openwrt-devel wrote: > Hi, > > What is the status of uboot on the variants of the BPi-R4? I have a couple > of Pro's I'd like to be able to boot from NVMe, as called out last August. > Checking in to see what progress there's been. No such feature is planned at the moment for OpenWrt, as replied back then. This may change once standatization of OpenWrt's boot method has been completed, as that would include booting off arbitrary storage devices, including NVMe or removable USB storage. See also https://github.com/openwrt/openwrt/pull/22177 ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Debugging EcoNet's MT7530 PHYs
On Fri, Feb 13, 2026 at 03:57:15PM +0100, Caleb James DeLisle wrote: > I just took a look at it and it seems like it might be the same - or at > least nearly the same. But this is a lot of code which is not upstream, so > that means my efforts can't be upstreamed until this is, so I can't continue > on ethernet because producing work that is not sent upstreamed is not in my > plan. > > So until this is sorted out, I'm going to have to do other stuff. I suggest you could start with carrying Ansuel's patch upstream, it's not uncommon for people to submit work done by others as long as you fully understand what is being done, this is not a problem. In general, as most of the changes are related to the mt7530 it would anyway be the best to discuss everything on the netdev kernel mailinglist, OpenWrt is by far not the only user of that driver and development happens upstream. I've talked with Chester Arınç Ünal who is one of the key maintainers when it comes to mt7530, and he isn't reading the OpenWrt lists, for example, and only got aware of your upcoming contributions because I told him off-list. > > Thanks, > > Caleb > > > On 12/02/2026 13:28, Benjamin Larsson wrote: > > On 2/12/26 02:07, Caleb James DeLisle wrote: > > > > > > Problem is, vendor code is (as usual) some of the most hideous crap > > > imaginable. But as far as phy tuning, I'm planning on at least > > > punching in all of the values and not skipping anything. However > > > there's a lot of code for finding those values and I think I'd > > > rather just get them from the vendor OS and write them directly. > > > > > Hi, this is a patch to a patch but the point is that the logic already > > exists, and they are calibrated in runtime because they are not board > > specific. > > > > https://github.com/Ansuel/openwrt/commit/6049d6501d00383f1c90b0ada0464eb6973fe884#diff-a43aa8f792576a1c708c1e97a7feac5c37b9b956e5fe11f143ea6cfb681a05a3 > > > > > > We should build on the frame work that is used by AN7581/AN7583 because > > the hardware share a common heritage. > > > > MvH > > > > Benjamin Larsson > > > > > > ___ > openwrt-devel mailing list > [email protected] > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Debugging EcoNet's MT7530 PHYs
On Wed, Feb 11, 2026 at 11:44:12AM +0100, Caleb James DeLisle wrote: > > On 11/02/2026 11:26, Daniel Golle wrote: > > On Wed, Feb 11, 2026 at 11:13:26AM +0100, Caleb James DeLisle wrote: > > > On 10/02/2026 23:12, Benjamin Larsson wrote: > > > > If I understand correct, the ref SDK just sets up a transparent bridge > > > > and lets the packets flow through? If that is correct is that an option > > > > here? > > > When use_soc_lan is unset, this is what happens. When use_soc_lan is set, > > > it > > > does a bunch of highly awkward stuff to add support for one extra port on > > > the internal switch. It's an option, probably to treat the internal switch > > > as part of the eth driver - however this will not work on EN7526C which no > > > external switch, internal is exposed. > > > > And IMO we should not stack stags. If it is possible to pass stags > > > > through with the pass-through bit intact it should be possible to > > > > address all ports on both switches with just one stag. > > > > > > > > I was hoping the PT_OPTION PVC bit would set the stag pass through bit > > > > on incoming frames. > > > Stacking stags does potentially have a performance penalty in the tag > > > parser > > > - I say "potentially" because it's already walking a list which could be > > > an > > > array index, and even 2 array indexes is faster than what we have now. > > > > > > But trying to use the PT bit as designed makes it impossible to > > > differentiate between a packet that came from port N of the external > > > switch > > > and a packet that came from port N of the internal. Vendor code doesn't > > > support having the same port number active on both internal and external, > > > if > > > you try it will quietly overwrite the switch_port_map entry in > > > init_ethernet_port_map(), so I surmise this is a real silicon bug, not a > > > misconfiguration on my end. > > > > > > But (so far), stacking tags seems to work, so I would much prefer it to > > > inter-switch rules, i.e. "you can't enable this port in the DT because you > > > have one with the same number on the other switch". > > > > > So if the vendor SDK doesn't allow using the same port number on both, > > the on-die and the MCM switch, that means there won't be any boards > > around doing that, right? Nobody is designing new boards with this > > silicon at this point, all existing boards had to adhere to those rules. > > Hence I don't see why the extra overhead of stacked special tags would > > be worth it, especially also given that stacked special tags also won't > > work with the hardware offloading PPE/HWNAT, and likely also break other > > stuff such as TX checksum offloading. > > > > > BTW Vendor code (see: TCSUPPORT_MULTI_SWITCH_EXT) suggests there are > > > boards > > > with multiple external switches. Probably a board integrator hung another > > > 7530 off of one of the RGMII interfaces. Per my reading, vendor code falls > > > back on VLANs, giving up on the stag entirely. I haven't confirmed that > > > transmit works yet, but assuming it does, stacked stags should Just Work > > > in > > > this use case whereas the PT bit clearly would not. > > Have you seen any boards actually using an additional (ie. third) MT7530 > > connected as external IC? If this feature is only a theoretical option > > which none of the board markers choose to implement I think it's worth > > ignoring it and not supporting it upstream, especially if the vendor SDK > > just uses the swconfig driver with VLANs rather than DSA. > > > Okay, I'll put a "no port reuse" check in mt7530.c and in tag_mtk.c I'll > just the dsa_conduit_find_user() with a relaxed walker that ignores switch > ID, then make mtk_tag_xmit() set the PT bit if switch ID is non-zero. > Chaining will support 1 downstream switch on port 5, and any port used on > one switch cannot be used on the other. In case the MCM switch is being used to provide user ports, are any ports of the on-die switch other than the CPU port and the port connecting the MCM switch used as well? If using the MCM switch anyway effectively turns the on-die switch into a "2 port switch" only forwarding between those 2 ports, it would be worth investigating if MTRAP register can be used similar like on MT7530 (on MT7531 it doesn't exist), see mt7530_setup_port5(). ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Debugging EcoNet's MT7530 PHYs
On Wed, Feb 11, 2026 at 11:13:26AM +0100, Caleb James DeLisle wrote: > > On 10/02/2026 23:12, Benjamin Larsson wrote: > > If I understand correct, the ref SDK just sets up a transparent bridge > > and lets the packets flow through? If that is correct is that an option > > here? > When use_soc_lan is unset, this is what happens. When use_soc_lan is set, it > does a bunch of highly awkward stuff to add support for one extra port on > the internal switch. It's an option, probably to treat the internal switch > as part of the eth driver - however this will not work on EN7526C which no > external switch, internal is exposed. > > > > And IMO we should not stack stags. If it is possible to pass stags > > through with the pass-through bit intact it should be possible to > > address all ports on both switches with just one stag. > > > > I was hoping the PT_OPTION PVC bit would set the stag pass through bit > > on incoming frames. > > Stacking stags does potentially have a performance penalty in the tag parser > - I say "potentially" because it's already walking a list which could be an > array index, and even 2 array indexes is faster than what we have now. > > But trying to use the PT bit as designed makes it impossible to > differentiate between a packet that came from port N of the external switch > and a packet that came from port N of the internal. Vendor code doesn't > support having the same port number active on both internal and external, if > you try it will quietly overwrite the switch_port_map entry in > init_ethernet_port_map(), so I surmise this is a real silicon bug, not a > misconfiguration on my end. > > But (so far), stacking tags seems to work, so I would much prefer it to > inter-switch rules, i.e. "you can't enable this port in the DT because you > have one with the same number on the other switch". > So if the vendor SDK doesn't allow using the same port number on both, the on-die and the MCM switch, that means there won't be any boards around doing that, right? Nobody is designing new boards with this silicon at this point, all existing boards had to adhere to those rules. Hence I don't see why the extra overhead of stacked special tags would be worth it, especially also given that stacked special tags also won't work with the hardware offloading PPE/HWNAT, and likely also break other stuff such as TX checksum offloading. > BTW Vendor code (see: TCSUPPORT_MULTI_SWITCH_EXT) suggests there are boards > with multiple external switches. Probably a board integrator hung another > 7530 off of one of the RGMII interfaces. Per my reading, vendor code falls > back on VLANs, giving up on the stag entirely. I haven't confirmed that > transmit works yet, but assuming it does, stacked stags should Just Work in > this use case whereas the PT bit clearly would not. Have you seen any boards actually using an additional (ie. third) MT7530 connected as external IC? If this feature is only a theoretical option which none of the board markers choose to implement I think it's worth ignoring it and not supporting it upstream, especially if the vendor SDK just uses the swconfig driver with VLANs rather than DSA. ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Debugging EcoNet's MT7530 PHYs
Hi Caleb,
On Tue, Feb 10, 2026 at 10:07:55PM +0100, Caleb James DeLisle wrote:
> Welp, that didn't take long.
>
> It turns out when I remove PORT_STAG on the receiving side (internal port
> 5), the switch mistakes the first 2 bytes of the stag for a length, and if
> the packet is actually shorter than that length, it drops. So 0004 worked
> fine, but 0104 didn't until I sent a longer packet.
>
> Clearing L2LEN_CHK on the AGC register works around the issue and packets
> are received in full with correctly stacked stags.
>
> If I can make the passthrough bit copy, or stop it from copying the port
> number when I have PORT_STAG set, that would be of course superior, but if I
> have to use the hack to get the feature then I'll send the patchset like
> that.
This whole arrangement is kinda similar to good-old MT7620 which also
had an on-die MT7530 with only FE ports and a single RGMII which can be
used to connected an external MT7530. In this case it is common to use
muxing to patch the external switch directly to the GMAC, as in that
case usually all other ports of the internal MT7530 are anyway unused.
The same should be possible on the EcoNet platform, but of course only
makes sense if there are either two GMACs which are both connected to
the in-die switch with one of on a port of the on-die MT7530 which can
be muxed directly to the TRMGII connecting the MCM MT7530.
This obviously has the disadvantage that traffic between the two switch
instances will then have to go via the CPU, but if PPE offloading is
similar to that in MediaTek SoCs it could be offloaded and at least not
waste CPU cycles (but still compete for the limited bandwidth with
traffic from/to WiFi or PON interface).
The main question whether it makes sense to use muxing to directly patch
the MCM MT7530 to a GMAC (if possible at all) is kinda how many TP PHY
ports the whole package got and how they are commonly used.
Cheers
Daniel
>
> Thanks,
>
> Caleb
>
>
> On 10/02/2026 20:25, Caleb James DeLisle wrote:
> > Hello guys,
> >
> > I have an update on this MT7530. As I mentioned in my initial email
> > there are two switches that are stacked, so I'm needing to do quite a
> > bit of patching to mt7530.c to create anything that is going to work.
> >
> > I'm trying to handle incoming traffic from the MCM ("external") switch
> > to the on-die switch. It comes in port 4 of the external, where I have a
> > cable attached, then goes to port 6 which the external is treating as a
> > CPU port. Then it comes in port 5 of the internal. Here's my values for
> > the PVC register:
> >
> > ext 4 0x810001c0 ACC_FRM=all VLAN_ATTR=transparent EG_TAG=consistent
> > STAG_VPID=0x8100
> > ext 6 0x0920 ACC_FRM=all PORT_STAG VLAN_ATTR=user EG_TAG=consistent
> > PT_OPTION STAG_VPID=0x0
> > int 5 0x810001e0 ACC_FRM=all PORT_STAG VLAN_ATTR=transparent
> > EG_TAG=consistent STAG_VPID=0x8100
> > int 6 0x0120 ACC_FRM=all PORT_STAG VLAN_ATTR=user EG_TAG=consistent
> > STAG_VPID=0x0
> >
> > When PT_OPTION is set on port 6 of the external, it sets the Passthrough
> > bit on the Special Tag before sending it to the internal switch. When
> > int 5 has PORT_STAG set, the Passthrough bit is required otherwise it
> > will drop STAG'd packets. However, when it's set the switch does a weird
> > stupid thing and it copies the port number from what was received from
> > the external switch - but it DOESN'T copy the passthrough bit. So you
> > end up with this:
> >
> > [ port 4 ][ port 4 +PT ][ packet header ]
> >
> > And the obvious problem is this is indistinguishable from a packet that
> > comes from port 4 of the internal switch and has an stag directly under
> > the eth header.
> >
> > ---
> >
> > Another angle is to remove the PORT_STAG from internal port 5, and then
> > you get this:
> >
> > [ port 5 ][ port 4 +PT ][ packet header ]
> >
> > In that case you can also remove PT_OPTION from external port 6, but
> > sending ANY kind of VLAN packet from the outside gets it filtered and
> > RxFiltering gets incremented. No matter what I do, I can't figure out
> > how to stop VLAN packets from getting dropped except by putting
> > PORT_STAG on the receiving port (internal port 5). No configuration of
> > internal port6 prevents it, even if it's a dumb switch, is still drops
> > them.
> >
> >
> > Anyone have any ideas?
> >
> >
> > Thanks,
> >
> > Caleb
> >
> >
> >
> >
> > On 28/01/2026 14:26, Caleb James DeLisle wrote:
> > > Update: It turns out the reset controller I was using only reset the
> > > on-die switch, Benjamin found the reset register for the external
> > > switch and now everything is behaving MUCH more like normal. I'd say
> > > at this point I'm no longer stuck.
> > >
> > > Thanks,
> > >
> > > Caleb
> > >
> > >
> > > On 27/01/2026 18:26, Caleb James DeLisle wrote:
> > > > >
> > > > > Would there be any reason not to set BMCR_PDOWN in
> > > > > mt7530_phy_config_init() so we know they're in a consistent
> > > > > state?
> > >
Re: Debugging EcoNet's MT7530 PHYs
On Tue, Jan 27, 2026 at 11:43:00AM +0100, Caleb James DeLisle wrote: > Hello, thank you Felix. > > I have a small update: Even if the switch is otherwise untouched, even in > the bootloader, setting BMCR_ANRESTART is fatal. The bootloader does seem to > set BMCR_ANRESTART during startup, and BMCR_ANENABLE is set during > operation. I gather I should define config_aneg and do some ritual in there, > but mt7530.c and mtk-ge.c don't seem to be doing anything so I'm not sure > where to look. Are you resetting the PHYs in some way before accessing them? Ie. either by using a reset register of the switch or by assigning genphy_soft_reset to .soft_reset. Especially if you are not sure the PHY is freshly reset before accessing it from within Linux, check the page select register (0x1f in C22 mode). Should that be non-zero you might not actually be touching what you believe is the AN_RESTART bit, but maybe something entirely different because you are operating on a different page of registers on which register 0 isn't BMCR. > > Currently working on getting the vendor OS going so I can try resetting the > port and see if I can track down what they're doing. > > Thanks, > > Caleb > > > On 27/01/2026 11:05, Felix Baumann wrote: > > Hello arinc9, > > > > maybe you have an idea or could help him out? :) > > > > Regards > > Felix Baumann > > > > Am 25. Januar 2026 00:53:25 MEZ schrieb Caleb James DeLisle : > > > Oh sorry, one thing I completely forgot to mention: > > > > > > I have the reset line labeled "GSW" configured - and it should be > > > resetting one or maybe both switches. Also of course mt7530.c resets via > > > MDIO. None of this affects the PHY, it still works until the first time > > > BMCR_ANRESTART or BMCR_PDOWN is asserted. > > > > > > Thanks, > > > > > > Caleb > > > > > > > > > On 25/01/2026 00:45, Caleb James DeLisle wrote: > > > > Hello guys, > > > > > > > > > > > > I'm working on the DSA for the EN751221 and I think I'm a bit stuck. > > > > > > > > > > > > Background: > > > > > > > > This is a really strange configuration, there are actually two MT7530 > > > > switches. The first one is MMIO (vendor code says it's in the SoC die), > > > > and the second one is MDIO (identified in vendor code as an MCM). > > > > AFAICT the SoC switch is configured with only two ports active, > > > > Port6->CPU and Port5->MCM Switch. The MCM switch and its PHYs are hung > > > > off of the MDIO bus of the SoC switch, and to avoid collisions of PHY > > > > numbers, the SoC switch uses PHYs numbered 8,9,10,11,12 in place of > > > > 0,1,2,3,4. All of the PHYs (for both switches) identify as 03a2.9412, > > > > except for #12 which ids as 03a2.9451. > > > > > > > > I THINK the configuration is that the SoC switch port 5 uses PHY#12 > > > > (borrowed from port4) to talk TRGMII to MCM switch port6, PHY#12 is the > > > > odd one in terms of ID so it is probably a TRGMII passthrough. > > > > > > > > There is vendor code which seems to tune PHY#0 (similar to > > > > mt7530_setup_port6() from linux/mt7530.c except with different > > > > frequency), I gather these CORE_PLL_* are not actually modifying PHY#0 > > > > but rather it's a backdoor to controlling the whole switch (?). In the > > > > vendor code, it also tunes PHY#12 exactly the same way, so I may > > > > surmise that PHY#12 is the portal from the SoC switch to the MCM switch. > > > > > > > > What is clear and has been tested is that traffic flows into one of the > > > > ports of the MCM switch, then from there it goes to port6 which is > > > > connected to port5 of the SoC switch, then through port6 of the SoC > > > > switch to the ETH engine. I just don't know what PHYs are being used to > > > > do it. > > > > > > > > In any case, this isn't what's blocking me right now. > > > > > > > > > > > > The problem: > > > > > > > > Right now, I can get traffic to pass if I do not touch the phys at all, > > > > but of course that's not going to be acceptable in upstream. So I'm > > > > currently focusing on PHY#2 and trying to make it link up - I have a > > > > cable plugged in to the relevant port. I gather PHY#2 can't possibly be > > > > muxed with anything, so I shouldn't need to worry about anything except > > > > what MDIO messages are sent to PHY#2 (I'm not even trying to pass > > > > traffic, just see it's linked up, so even the switch could even be > > > > kaput). Furthermore, since this is an MCM module, I gather it should be > > > > identical silicon to the MCM switch in the MT7621, so to just make it > > > > link up, I really shouldn't be having a lot of difficulty (I am). > > > > > > > > I stubbed mt7530_phy_config_init() so it wouldn't change anything from > > > > what the bootloader had set, and I isolated the problem to the call to > > > > BMCR_ANRESTART. If this is not called, basically nothing on the PHY is > > > > touched except for a small change to the , and I have a stable > > > > connection. If
Re: Upcoming update to 6.18 and scripts
Hi Elliott, sorry for the not completely on-topic takeover, but I had to ;) On Sat, Dec 13, 2025 at 04:57:22PM -0800, Elliott Mitchell wrote: > [...] > The script was written using Perl since Perl's string handling was > rather easier for initial work. It should readily convert to Python, > but that requires indication that would be worth the time required. Python's rather annoying habbit to frequently release slightly incompatible updated versions of the interpreter rather Perl the preferred language in my eyes, given that it is sufficient for the task. > After that it might be appropriate to announce plans to remove Perl from > OpenWRT and only already existing submissions are allowed to use. Why? Perl 5 is actively maintained and I don't see it going away any time soon. ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: EcoNet: MT7612E not working
On Sun, Oct 26, 2025 at 03:07:55PM +0100, Caleb James DeLisle wrote: > This is a bit of a long-shot but I'm at a loss here. On both of my EcoNet > devices with MT7612 chips, it fails to start. MT7613 and MT7603 both work. > I'm suspicious of my PCI controller because it's something I worked on, but > I don't see any evidence of PCI issues. > > > Is there anything really unique about MT7612, particularly how it uses PCI ? > > > MT7613E / Slot 2 -> Works (TP-Link Archer VR1200v (v2)) > > MT7603 / Slot 1 or slot 2 -> Works (ZyXEL PMG5617GA and SmartFiber XP8421-B > respectively) > > MT7612 / Slot 1 or slot 2 -> Fails (SmartFiber XP8421-B and ZyXEL PMG5617GA > respectively) > > > Here is my bootlog: > > [ 13.252551] mt76x2e :02:00.0: enabling device ( -> 0002) > [ 13.258716] pcibios_plat_dev_init: bus 2, slot 0 > [ 13.263689] mt76x2e :02:00.0: ASIC revision: 76120044 > [ 13.269738] mt76x2_eeprom_init > [ 13.272871] mt76_get_of_eeprom 80004328 > [ 13.276719] mt76_get_of_data_from_nvmem eeprom > [ 13.385361] mt76x2_eeprom_load 1 > [ 13.388635] mt76x2_eeprom_load found=1 > [ 13.523388] urngd: v1.0.2 started. > [ 14.042816] mt76x2e :02:00.0: Invalid MAC address, using random > address b6:db:5e:21:55:82 Are you sure the EEPROM data passed to the driver is correct? I wonder because it should also contain a valid MAC address... > [ 14.083630] mt76x2e :02:00.0: ROM patch build: 20141115060606a > [ 14.113187] mt76x2e :02:00.0: Firmware Version: 0.0.00 > [ 14.118716] mt76x2e :02:00.0: Build: 1 > [ 14.122875] mt76x2e :02:00.0: Build Time: 201607111443 > [ 14.572779] mt76x2e :02:00.0: Firmware failed to start > [ 14.578409] mt76x2e :02:00.0: probe with driver mt76x2e failed with > error -145 > > > I've added a few debug logs to confirm eeprom is loaded correctly and passes > mt76x2_check_eeprom(). > Firmware and ROM patch match (working) vendor OS bit-for-bit. > > Any ideas where else to look? If the problem is not the missing or wrong EEPROM data, maybe the PCIe reset line is inverted or configured wrongly (-> pinctrl)? Just guessing, of course... ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: luci-app-attendedsysupgrade and owut by default?
On Sat, Sep 27, 2025 at 07:16:33PM +0200, Hauke Mehrtens wrote: > How well can we integrate DNS into the LuCI web interface? Very good question. I'm not into that whole web side of things at all. > DNS is also not authenticated, it should be fine if the attacker could only > prevent the UI from showing an update notification, but it should not be > able to tell the user where to get the update. That's what I thought: Only indicate the presence of a newer release, not where to get it. > I think we would get some negative feedback from users when we remove apk > from the default images. We could offer an option in the ASU web interface > to remove APK. > If we have a button to generate a default image without apk in the firmware > selector UI it would be sufficient: > https://firmware-selector.openwrt.org/?version=24.10.3&target=mediatek%2Fmt7622&id=linksys_e8450 > Removing it manually from the list is a bit complicated for the novice user. On many devices the only possible outcome of trying to use the package manager is a brick because rootfs_overlay got only 1 or 2 JFFS2 blocks total. So even **deleting** a package would result in a brick as the list of installed packages would be copied to the rootfs_overlay as a consequence of *any* change... Apart from just not installing the package manager, I believe we should also not install 'ca-bundle' on SMALL_FLASH devices, and also select CONFIG_CLEAN_IPKG=y by default. Together with an easy to use way to generate and install custom ASU-generated images for such a devices the outcome would be something much more intuitive and user-friendly than an anyway broken package manager (opkg or apk are equally affected by this problem, obviously). > > > Do we have to install luci-app-attendedsysupgrade and owut for this or is > > > it > > > possible with less? > > > > Either of the two packages is sufficient, we don't need both of them. > > > > > > > > Should we add luci-app-attendedsysupgrade as a dependency to > > > luci/collections/luci/Makefile ? > > > > I'd say yes, but that's just my opinion. > > I think this is a good option. > > > > Should we move utils/attendedsysupgrade-common from the package feed to > > > the > > > main repository? > > > > I suggest to merge the content of the utils/attendedsysuprade-common > > package into base-files, as the packaging overhead is bigger than the > > actual content (a single UCI configuration file). > > I agree with you. > > Maybe we should handle the ASU signing key a bit special. > This key is not as good protected as the other keys. > Maybe store it in /etc/opkg/asu-key/ and use this key for signature checks > initialized by the tools using ASU intentionally only. +1 makes a lot of sense! > So to summarize: > * Add luci-app-attendedsysupgrade as a dependency to the LuCI default > collections for all builds with use LuCI. > * Add OWUT for !SMALL_FLASH > * The automatic checks for updates should be opt in, we can keep it like it > is for now and improve later. +1 > > I would keep apk for now, but make it easy for users to generate images > without apk in the firmware selector UI. Ok, but lets somehow expose CONFIG_CLEAN_IPKG as an option to the IB and ASU as well. That, together with dropping libuclient, ca-bundle and owut can be a good option for SMALL_FLASH devices which are then still suitable for running LuCI and offer a good overall UIX. ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [VOTE] OpenWrt Two
On Thu, Oct 09, 2025 at 07:40:31PM +0100, David Woodhouse wrote: > On Mon, 2025-02-17 at 22:58 +0900, Sungbo Eo wrote: > > On 2025-02-13 03:44, John Crispin wrote: > > > Hi, > > > > > > starting a [VOTE] to get approval allowing me to begin the development > > > of OpenWrt "Two". > > > > > > "Two" will have all of the features that "One" has with the following > > > upgrades. > > > > > > * MT7988 > > > * 10G SFP > > > * 5G copper > > > * 4 port 2.5G copper > > > * 1-2 port 1G copper > > > * Tri-band Wi-Fi 7 > > > > > > "Two" will be produced by GL.iNet and we are exploring options for US/EU > > > based distribution. > > > > > > "Two" will (hopefully) be in the 250$ region with yet again a portion of > > > that being donated to the project. > > > > > > expected availability is late '25. > > And still PoE? On which port? > > I'm just starting to play with the OpenWrt One that's been sitting on > my desk for a while. I'm trying to understand why anyone would get PoE > on the *WAN* port, if that's coming for their ISP's fibre/VDSL dongle. > Seems like that port is always just going to be a single wire to > whatever the uplink is. The One got 1x 1GE and 1x 2.5GE, the assignment which of them is LAN and WAN is pretty arbitary and can be changed according to your needs. The decission to make 2.5GE port the PoE input was to make the One suitable as an access point supplied by a 2.5GE PoE switch -- we wanted the faster port to be with PoE. > > Seems to me like I'd always want PoE to come from the internal network > on the *LAN* side, surely? > > Which is fine on the One, as I can just use the 2.5G/PoE port as the > internal one, connect the VDSL dongle to the 1G port, and wonder why > the box and default configuration have them mislabelled. On my case there aren't any labels destinguishing either port as WAN or LAN. It's all just default configuration. > > But on the Two, it's going to matter more. I'd really want the PoE to > be on one of the four 2.5G ports attached to the switch, and *not* the > single port. Otherwise there's going to be a lot more software bridging > than necessary... Thanks to 'bridger'[1] it is easy to avoid CPU-intense "software bridging" from happening on MediaTek platforms which comes with MediaTek's PPE offloading engine. [1]: https://github.com/nbd168/bridger ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: luci-app-attendedsysupgrade and owut by default?
Hi, On Thu, Sep 25, 2025 at 10:33:51PM +0200, Hauke Mehrtens wrote: > Hi, > > I would like to have the basic attended sysupgrade features in the default > images for the next major release. > > I am not very familiar with the feature and what is needed. > > I think LuCI should inform the user when a new major release is available. Currently both, the LuCI app as well as owut only show possible updates when instructed by the user to do so. We should better think twice before having all devices with those tools installed query online services for updates when ever the admin logs in, this has wide ranging implications regarding the user's privacy as well, RAM usage for package lists, data consumption on metered connections, ... I'd therefore restrict this to query for release updates (and not just a newer snapshot build in case of a device currently running a snapshot image, and also only query for package updates upon user requests). Checking the availability of an newer release could be done using a TXT record in DNS, for example, which would be much more lightweight (on both ends) than using HTTPS JSON RPC queries for that. Neither of the ASU clients currently supports anything like that, but it would obviously be quite easy to implement in either luci-mod-admin-full or the ASU clients. > There should be a button in LuCI which will tell ASU to create an image and > then install it using sysupgrade. > > We should also have this feature on the command line, at least that you can > ask a tool if an upgrade is available and then tell it to upgrade including > all packages. > > Maybe we should restrict this to large flash devices. One of the design goals of ASU was to support devices with very small flash. In fact, having an ASU client (owut or the LuCI app) installed takes less space than keeping a full package manager incl. unstripped metadata of the installed packages -- so on small flash devices I'd rather drop the (in this case anyway pretty useless) package manager and keep only an ASU client instead. > > Do we have to install luci-app-attendedsysupgrade and owut for this or is it > possible with less? Either of the two packages is sufficient, we don't need both of them. > > Should we add luci-app-attendedsysupgrade as a dependency to > luci/collections/luci/Makefile ? I'd say yes, but that's just my opinion. > > Should we move utils/attendedsysupgrade-common from the package feed to the > main repository? I suggest to merge the content of the utils/attendedsysuprade-common package into base-files, as the packaging overhead is bigger than the actual content (a single UCI configuration file). > > Should we also move utils/owut from the package feed to the main repository > and add it as a default dependency to DEFAULT_PACKAGES. I'd say yes for !SMALL_FLASH devices. > > Is this all needed or does this feature also work with less new packages? The approach of both clients a slightly different: - owut talks to the configured ASU server directly over HTTPS. Hence it requires network connectivity with the ASU server, and depends on libuclient (+ ucode bindings), libustream-ssl and ca-certs or ca-bundle being installed. - The LuCI app does not require connectivity (nor CA certs) on the device itself but instead has the browser accessing LuCI query the ASU server on its behalf. Hence, only the browser accessing the LuCI app needs connectivity with the ASU server while the device itself doesn't. Cheers Daniel ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: license about rssileds package
On Sun, Aug 03, 2025 at 02:03:44PM +0200, Felix Baumann via openwrt-devel wrote: > Am 3. August 2025 07:08:12 MESZ schrieb Giuseppe Lippolis > : > >I'm going to extend the feature supported by > > > >package/network/utils/rssileds/files/rssileds.init > > > >But I noticed at line 2: > > > ># (C) 2012 Daniel Golle, Allnet GmbH > > > > > >So my question is: can I modify that file or shall I refrain from doing so? Go ahead, I wrote that and it was supposed to be under GPL-2.0-or-later just like the .c file of the the rssileds service itself. ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Banana Pi-R4 and NVMe
> Hi, > > I have a BPi-R4 (v1.1) and I've installed a Toshiba 1TB NVMe stick in it. I > refreshed 24.10.2 and rebooted, then installed kmod-nvme, pciutils, pciids, > etc. and rebooted. > > I don't see the NVMe for some reason: > > root@OpenWrt:~# lspci > :00:00.0 PCI bridge: MEDIATEK Corp. Device 7988 (rev 01) > :01:00.0 Network controller: MEDIATEK Corp. Device 7990 > 0001:00:00.0 PCI bridge: MEDIATEK Corp. Device 7988 (rev 01) > 0001:01:00.0 Network controller: MEDIATEK Corp. Device 7991 > root@OpenWrt:~# > > What am I missing? What have others done to make this work? What version of > board do you have? What brand/model memory stick are you using? What > drivers/packages have you installed? What are your dip switch settings? It looks like the NVMe is not detected in the PCIe bus at all. Please post complete kernel logs (dmesg). Depending on which production run your V1.1 board belongs to you may be facing a known design issue documented here: https://forum.banana-pi.org/t/bpi-r4-nvme-i2c/17152/2?u=dangowrt Note that this may affect **and even break/burn** some NVMe controllers, so make sure those two 0-ohn resistors are not populated as described in that thread. I've told this to SinoVoip/BananaPi but apparently a lot of boards were already out at sellers and old/broken versions **are still being sold by some of them**. If the R228 and R230 are not present and the SSD is still not detected you may be facing a PCIe interoperability issue, or maybe the (rather large) SSD is drawing too much power, or it just doesn't come up fast enough to be present when the bus is being scanned (in that latter case it should work after a soft reboot). ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Target bananapi_bpi-r4-common
On Fri, Jul 04, 2025 at 04:41:35PM -0600, Philip Prindeville wrote: > On Jul 4, 2025, at 12:54 PM, Daniel Golle wrote: > > On Fri, Jul 04, 2025 at 11:47:26AM -0600, Philip Prindeville wrote: > >> > >> Yeah, I’ve been thinking about us developing an Amazon EC2 image for the > >> market place for people who have CGNAT, for instance, but might want to > >> lease a VM with a fixed IP address, host DNS there, and then do > >> port-forwarding over VPN... and we could have the royalties go to the > >> project. > > > > Yes, I agree we need to do that and facilitate easy deployment of > > OpenWrt images on the various clouds. It's not my area of expertise, but > > I know that Paul Spooren has previously been working on that. > > > I’ll ask the #homelab group at Amazon if they have interest in contributing > to this. We might even be able to get a few free VMs to help with > development. > Nice, lets see how that goes. > We have an SD driver even if the SD slot is empty from the factory. Why not > an NVMe driver baked in, even if the M.2 slot is empty from the factory? I > don’t really see the difference. The M.2 slot exposes a PCIe bus. We *do* ship the PCIe host controller driver. There are many things you can connect using PCIe, not just NVMe SSDs. While in theory the same is true for SDIO, we do include the MMC block storage driver because it is anyway already needed for the eMMC. And even if that would not be true, another reason for shipping a hypthetical SD card storage driver would also be that the SD card can be used to boot from, while there is no way to boot from anything connected to the PCIe bus on that board. Maybe I have to understand why that is such an urge for you, so let me ask you why it is such a problem that the kmod-nvme package (and maybe also filesystem and partitioning tools you may need in order to use an NVMe in a meaningful way) needs to be installed and isn't included in the *default* image? Why can't you just install all that on the systems you need it? Why can't you just create an image with the ImageBuilder which includes that? Independently of the specific case above: Including *all* kernel modules and potentially needed firmware for all those modules is really not an option. Take a look at https://packages.debian.org/sid/linux-image-arm64 and understand that even just a include-everything kernel with all modules is about 90 MB. And linux-firmware is currently about 1.2 GB (not all of that needs to be included, of course, but who would work to decide what should be?) Given that the current average OpenWrt device comes with a total of 128 MB SPI-NAND flash, that's clearly too much. Even on devices with a 4 GB eMMC it be a pain. > > > > > >> > >> How much work would it be, anyway, to have the options to build images > >> that provision /var at install time, and a “sysupgrade” that supports it > >> and doesn’t lose your configuration… > > > > One solution could be to have two variants of the 'base-files' package: > > One with /var being tmpfs (like now), and one new, let's call it > > 'base-files-persistent-var' which would treat /var as persistent storage > > on an additional volume, or even as part of rootfs_data. > > > Or the boot script could simply peek into /etc/config/fstab and see if > there’s a mount for /var ... True, we could also setup the symlink /var -> /tmp dynamically if there isn't any entry for that in /etc/config/fstab. Currently the symlink itself is part of the base-files package. > > > > The problem is that it doesn't end there, as an unknown number of > > packages also assumes that /var == /tmp, and all of them will have to be > > fixed. > > > At this point I’d settle for /var/log working… though if I ran a mail > front-end (a relay only, not a mail store) on my OpenWRT, I’d probably want > mail storage (/var/spool/mqueue or whatever) to be persistent so that > undelivered email doesn’t get lost in the case of a reboot. logger should already handle if the logfile is on a mounted volume. You need to install 'blockd' for that to work though, as blockd is in charge of emitting the notification about a newly mounted filesystem. ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Target bananapi_bpi-r4-common
On Fri, Jul 04, 2025 at 11:47:26AM -0600, Philip Prindeville wrote: > > On Jun 24, 2025, at 5:52 AM, Daniel Golle wrote: > > > > On Mon, Jun 23, 2025 at 08:15:15PM -0600, Philip Prindeville wrote: > >>> On Jun 14, 2025, at 3:33 AM, Daniel Golle wrote: > >>>>> On Jun 13, 2025, at 5:01 PM, Daniel Golle wrote: > >>>>> On Fri, Jun 13, 2025 at 04:03:37PM -0600, Philip Prindeville via > >>>>> openwrt-devel wrote: > >>>>>> Should the BPi-R4 be more richly provisioned? It's got 4 or 8GB of > >>>>>> DRAM so it's hardly a "skinny" platform. > >>>>> > >>>>> I would leave that to the user and keep the default image with just what > >>>>> is necessary. Diverging and creating "rich" images for specific devices > >>>>> imho opens a can of worms which will require continous maintainance. > >>>>> How would we decide which packages to include? How would we draw the > >>>>> line > >>>>> for each and every board whether in our opinion the amount of flash and > >>>>> ram is enough for any particular feature, and why some features are > >>>>> present while others aren't? > >>>> > >>>> Busybox has defaults that people are welcome to turn off. Why not have > >>>> something homologous for targets? > >>> > >>> I don't understand...? Of course anyone who builds from source is free to > >>> select all packages they want and is in no way bound to the default > >>> package selection. > >> > >> That goes both ways. People can also unselect all the packages they don’t > >> want. > > > > People, yes. Automated build processes, such as the buildbots generating > > the images for downloads.openwrt.org will just use the default. > > And that's what people expect and is written in the various (3rd party) > > docs, how-tos and so on. > > > You’d think there would be an easy way to mark in the targets a list of > platforms to not build via the automation, so we could built the “banana > pi-r4 lite” in the automation, but leave it to users to build “banana pi-r4 > full” (or whatever) themselves. Technically this is easy. However, OpenWrt is democratically goverend project with many participants. We need clear rules regarding what is allowed and what isn't. When it comes to images: We want one image for each hardware. There is a grey-zone here, for boards which have different incompatible variants and for those we can have as many images as there are variants (some SBC devboards, for example, come with a version with eMMC and a version with SPI-NAND, it is not really cool but acceptable to have two different images in order to allow the stock/vendor bootloader to work). Having several images with merely a different default software configuration is not acceptable, and I don't think that changing the rules regarding that would fly with the other developers. > >> We keep acting like every platform is a WRT54G w/ 64MB. They’re not. If > >> we have room, let’s stretch out legs. > > > > 4MB of flash and 16MB of RAM in case of the WRT54G btw, 32MB of RAM > > on the WRT54GL version supported by OpenWrt ;) > > > > Imho it should be up to the user to decide what to do with additional > > resources. We obviously cannot ship everything, it will always have to > > be a subset of the available packages. > > > Well, and that’s to my point: if we support more memory in the form of NVMe, > then users will have the room for whatever they choose to install. And that's already true. Users can install kmod-nvme and setup extroot on the NVMe, which potentially gives you terrabytes of space for software and data of all kinds. > > > > We already do have a 'small_flash' flag for devices with very little > > flash, and we do have (not very often used) device types 'basic', 'nas', > > and 'router' which influences the default selection. We could think > > about introducing more device types. > > > > Also this is a "two way road", in the sense that users chose OpenWrt > > images even for eg. x86_64 VMs exactly because they fit into a very > > small amount of storage and don't need much RAM. What you see as a flaw > > others (including myself) see as a strength. > > > Yeah, I’ve been thinking about us developing an Amazon EC2 image for the > market place for people who have CGNAT, for instance, but might want to lease >
Re: Target bananapi_bpi-r4-common
On Mon, Jun 23, 2025 at 08:15:15PM -0600, Philip Prindeville wrote: > > On Jun 14, 2025, at 3:33 AM, Daniel Golle wrote: > >>> On Jun 13, 2025, at 5:01 PM, Daniel Golle wrote: > >>> On Fri, Jun 13, 2025 at 04:03:37PM -0600, Philip Prindeville via > >>> openwrt-devel wrote: > >>>> Should the BPi-R4 be more richly provisioned? It's got 4 or 8GB of DRAM > >>>> so it's hardly a "skinny" platform. > >>> > >>> I would leave that to the user and keep the default image with just what > >>> is necessary. Diverging and creating "rich" images for specific devices > >>> imho opens a can of worms which will require continous maintainance. > >>> How would we decide which packages to include? How would we draw the line > >>> for each and every board whether in our opinion the amount of flash and > >>> ram is enough for any particular feature, and why some features are > >>> present while others aren't? > >> > >> Busybox has defaults that people are welcome to turn off. Why not have > >> something homologous for targets? > > > > I don't understand...? Of course anyone who builds from source is free to > > select all packages they want and is in no way bound to the default > > package selection. > > That goes both ways. People can also unselect all the packages they don’t > want. People, yes. Automated build processes, such as the buildbots generating the images for downloads.openwrt.org will just use the default. And that's what people expect and is written in the various (3rd party) docs, how-tos and so on. As I said, maintaining dedicated package selections for thousands of devices is not feasible for a small team of volunteer maintainers. There has to be a clear rule which packages should be included for each board. For now this rule is to include the default selection of packages for the class of device (ie. "router" in this case) plus the kernel drivers and userland tooling for whatever hardware the board comes with. We risk getting into endless discussions whether packages for a specific use-case should be included on a specific board. Of course, again, the community is free to provide such rich images for specific devices, and if you take a look into the forums you will find plenty of them. > >>> The 2.5GE PHY is built-into the SoC and apart from being populated > >>> differently the boards are identical, there is no iway to detect in > >>> software which variant we are dealing with. SinoVoip equips the R4 with > >>> some I2C EEPROMs which would be perfectly suitable to be used to indicate > >>> the board variant or even contain a factory-assigned MAC address. Sadly > >>> they come all empty. > >> > >> > >> Well, it's EEPROM, so it can be reblown, right? > > > > Sure, but as it isn't done in factory it's just another piece of > > persistent memory the user can do with what ever they want. > > We cannot use it to find out which board we are dealing with. > > > >> Don't know anything about that. I do my own monolithic builds from > >> scratch. Don't use image-builder. > > > > Ok, then you can anyway always divert from defaults in any way you > > want. What is restricting you? > > > Nothing, but I’m not an expert in the hardware of every platform. Having the > profile preselect most of the relevant packages and drivers for me would be > helpful. > > For instance, the BPi-R4 I got came with an image that doesn’t have NVMe > drivers/utilities installed, nor does it seem to have a uboot that can boot > from NVMe. The board also doesn't come with an NVMe. It comes with an M.2 slot, and PCIe drivers are included. What ever you want to connect to that M.2 slot is up to you. Without any adapters this could already in this case as well be an AHCI SSD as well, or a SATA host controller offering actual SATA ports, ... > We keep acting like every platform is a WRT54G w/ 64MB. They’re not. If we > have room, let’s stretch out legs. 4MB of flash and 16MB of RAM in case of the WRT54G btw, 32MB of RAM on the WRT54GL version supported by OpenWrt ;) Imho it should be up to the user to decide what to do with additional resources. We obviously cannot ship everything, it will always have to be a subset of the available packages. We already do have a 'small_flash' flag for devices with very little flash, and we do have (not very often used) device types 'basic', 'nas', and 'router' which influences the default selection. We could think about introducing mo
Re: Target bananapi_bpi-r4-common
On Fri, Jun 13, 2025 at 09:00:31PM -0600, Philip Prindeville wrote: > > > > On Jun 13, 2025, at 5:01 PM, Daniel Golle wrote: > > > > On Fri, Jun 13, 2025 at 04:03:37PM -0600, Philip Prindeville via > > openwrt-devel wrote: > >> > >> Should the BPi-R4 be more richly provisioned? It's got 4 or 8GB of DRAM > >> so it's hardly a "skinny" platform. > > > > I would leave that to the user and keep the default image with just what > > is necessary. Diverging and creating "rich" images for specific devices > > imho opens a can of worms which will require continous maintainance. > > How would we decide which packages to include? How would we draw the line > > for each and every board whether in our opinion the amount of flash and > > ram is enough for any particular feature, and why some features are > > present while others aren't? > > > Busybox has defaults that people are welcome to turn off. Why not have > something homologous for targets? I don't understand...? Of course anyone who builds from source is free to select all packages they want and is in no way bound to the default package selection. > > The 2.5GE PHY is built-into the SoC and apart from being populated > > differently the boards are identical, there is no way to detect in > > software which variant we are dealing with. SinoVoip equips the R4 with > > some I2C EEPROMs which would be perfectly suitable to be used to indicate > > the board variant or even contain a factory-assigned MAC address. Sadly > > they come all empty. > > > Well, it's EEPROM, so it can be reblown, right? Sure, but as it isn't done in factory it's just another piece of persistent memory the user can do with what ever they want. We cannot use it to find out which board we are dealing with. > Don't know anything about that. I do my own monolithic builds from scratch. > Don't use image-builder. Ok, then you can anyway always divert from defaults in any way you want. What is restricting you? > > > Yeah, probably. I'll look for them. > > > >> > >> Oh, one other question... I see there's a FPC connector for an extra LAN > >> port (not clear if it's switched or not). Has anyone used that and what's > >> the cable to make that work? Is there a knock-out machined into the case > >> of an extra port? And the diagram here: > >> > >> https://docs.banana-pi.org/en/BPI-R4_Pro/BananaPi_BPI-R4_Pro > > > > That's the R4 Pro, it's again a different board which isn't yet > > publicly available. > > > Oh, quite right. Here's the "standard" board: > > https://docs.banana-pi.org/en/BPI-R4/BananaPi_BPI-R4 > > And as you say, 10 GBE WAN (SFP), 1GBE WAN, 3x GBE switched. ... OR the 2.5G-PoE variant with only a single SFP+ cage and another 2.5GE RJ-45 instead instead. ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Target bananapi_bpi-r4-common
On Fri, Jun 13, 2025 at 04:03:37PM -0600, Philip Prindeville via openwrt-devel wrote: > > Should the BPi-R4 be more richly provisioned? It's got 4 or 8GB of DRAM so > it's hardly a "skinny" platform. I would leave that to the user and keep the default image with just what is necessary. Diverging and creating "rich" images for specific devices imho opens a can of worms which will require continous maintainance. How would we decide which packages to include? How would we draw the line for each and every board whether in our opinion the amount of flash and ram is enough for any particular feature, and why some features are present while others aren't? Of course, the community is free to create and share such images, and for many devices (incl. the R4) there are community-made images, some built from source, some made with the ImageBuilder or using online tools like the OpenWrt Firmware Selector and asu. However, we would not be able to maintain support for 2k devices if we would also have to maintain an individual package selection for all those devices which goes beyond offering minimal hardware support. > > Also, why are two different targets required for the same hardware? I get > that the "10G SFP WAN" and "2.5G/10G WAN" ports are combo so that only one > PHY can be in use at a time, but why can't a single target support both and > just detect which is connected? There are two different boards variants: - 2x SFP+ cages and 4x 1GE RJ-45 - 1x SFP+ cage, 1x 2.5GE RJ-45 and 4x 1GE RJ-45 The 2.5GE PHY is built-into the SoC and apart from being populated differently the boards are identical, there is no way to detect in software which variant we are dealing with. SinoVoip equips the R4 with some I2C EEPROMs which would be perfectly suitable to be used to indicate the board variant or even contain a factory-assigned MAC address. Sadly they come all empty. Hence, as they are two distinct board variants and there is no way to detect the variant in software, we need two images. That's different from a "combo port" on devices where both, SFP cage and RJ-45 MDI are physically present but only one of them can be used at a time. On such boards the presence indicator (MODDEF0) of the SFP cage can be used to switch between the SFP cage and the RJ-45 port (which also isn't supported yet by vanilla Linux or OpenWrt, but it's still a different story and will be supported in future) > > Do we want to auto-select more packages like (say) mwan3 for instance? I > think we have enough memory that we could include it and if it's not used > it's not the end of the world. Apart from the argument above, it also simply isn't possible to include packages from the packages feed in images created by the phase1 buildbot... > > I'd include: > > lldpd > curl > 6in4 (or 6to4 or both?) > avahi > collectd > firewall3 (or firewall4) > hwclock > iftop > ip-full > iptasn & iptgeoip > ntp* > snmp > *swan > xfrm > zoneinfo > > But that's me. I'd rather have it and not need it than need it and not have > it. > > Are there other BPi-R4 users that want to start a thread? There are some threads on the forum you may want to join. > > Oh, one other question... I see there's a FPC connector for an extra LAN port > (not clear if it's switched or not). Has anyone used that and what's the > cable to make that work? Is there a knock-out machined into the case of an > extra port? And the diagram here: > > https://docs.banana-pi.org/en/BPI-R4_Pro/BananaPi_BPI-R4_Pro That's the R4 Pro, it's again a different board which isn't yet publicly available. > > Says "PoE Module RT5400" but I can't find any info on that. There's this: > > https://www.amazon.com/youyeetoo-BPI-RT5400-Isolation-BPI-F2P-BPI-WiFi/dp/B0D61ZKFL6 > > But it doesn't include the BPi-R4 in the description. Is it PD (my guess) or > PI (for driving an external device)? It's PD, and typically SinoVoip/BPi will make boards which include the PoE module, ie. you can order the board with or without PoE functionality. ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PR] Add new platform: EcoNet EN751221 (DSL / XPON modems)
Hi Caleb, first of all thank you for taking care of the EcoNet legacy MIPS platforms -- they are pretty popular and running up-to-date Linux on them would be very nice. Supporting xPON or xDSL WAN is still a lot more work, obviously, but it's good to start from somewhere. On Wed, Jun 04, 2025 at 02:36:31PM +0200, Caleb James DeLisle wrote: > Hello all, > > > This is my second submission of a PR to add support for EcoNet. Per > community feedback, > > I submitted the bulk of the platform code upstream where it has been > reviewed and accepted. > > https://patchwork.kernel.org/project/linux-mips/list/?series=960479&state=* > > > What is submitted here that is not upstream is support for SPI NAND flash. > This depends on > > a MediaTek BMT framework which is not upstream. Nothing should prevent you from submitting support for the SPI host controller or the SPI-NAND chip to upstream Linux. MediaTek BMTv1/v2 as well as NMBM are legacy bad-block management systems, nowadays everybody should just be using UBI instead. If the (binary) bootloader expects a BMT-variant, as the source should be GPLv2 you can build it from source without expecting BMT and use UBI instead. > > Any comments and reviews would be most appreciated. > > > https://github.com/openwrt/openwrt/pull/19021 Looking at the series I noticed that you are patching SPI subsystem in order to support BMT, and you also add another vendor-specific driver as well as DT attribute for that. If you want to use BMT at all in order to not have to replace the bootloader it would be better to extend the existing support for the various MediaTek BMT and NMBM variants, see target/linux/generic/files/drivers/mtd/nand/ Ie. if what ECONET is doing is really different from any of the existing MediaTek BMT variants, please just implement OPs for struct mtk_bmt_ops instead of adding a new standalone driver which needs to hook into SPI NAND subsystem. Cheers Daniel ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/6] libsepol: update to version 3.8.1
Hi Dominick,
On Fri, Mar 28, 2025 at 03:28:06PM +0100, Dominick Grift wrote:
> ...
> diff --git a/package/libs/libsepol/Makefile b/package/libs/libsepol/Makefile
> index b1a34d293e..e9072d01ea 100644
> --- a/package/libs/libsepol/Makefile
> +++ b/package/libs/libsepol/Makefile
> @@ -6,12 +6,12 @@
> include $(TOPDIR)/rules.mk
>
> PKG_NAME:=libsepol
> -PKG_VERSION:=3.5
> +PKG_VERSION:=3.8.1
> PKG_RELEASE:=1
>
> PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
>
> PKG_SOURCE_URL:=https://github.com/SELinuxProject/selinux/releases/download/$(PKG_VERSION)
> -PKG_HASH:=78fdaf69924db780bac78546e43d9c44074bad798c2c415d0b9bb96d065ee8a2
> +PKG_HASH:=0e78705305f955abd4c0654d37a5477ee26349ab74db9e2b03a7868897ae1ddf
somehow this fails to build for me on Arch Linux (gcc (GCC) 14.2.1 20250207)
make[2]: Entering directory '/usr/src/openwrt/package/libs/libsepol'
. /usr/src/openwrt/include/shell.sh;
/usr/src/openwrt/staging_dir/host/bin/libdeflate-gzip -dc
/usr/src/openwrt/dl/libsepol-3.8.1.tar.gz | tar -C
/usr/src/openwrt/build_dir/hostpkg/libsepol-3.8.1/.. -xf -
[ ! -d ./src/ ] || cp -fpR ./src/*
/usr/src/openwrt/build_dir/hostpkg/libsepol-3.8.1
touch
/usr/src/openwrt/build_dir/hostpkg/libsepol-3.8.1/.prepared373c40fbd50048c5dd856777f1d054e4_6664517399ebbbc92a37c5bb081b5c53
(cd /usr/src/openwrt/build_dir/hostpkg/libsepol-3.8.1/; if [ -x configure ];
then cp -fpR /usr/src/openwrt/scripts/config.{guess,sub}
/usr/src/openwrt/build_dir/hostpkg/libsepol-3.8.1// && CC="ccache
/usr/src/openwrt/staging_dir/host/bin/gcc" CFLAGS="-O2
-I/usr/src/openwrt/staging_dir/host/include
-I/usr/src/openwrt/staging_dir/hostpkg/include
-I/usr/src/openwrt/staging_dir/target-aarch64_cortex-a53_musl/host/include"
CXX="ccache /usr/src/openwrt/staging_dir/host/bin/g++"
CPPFLAGS="-I/usr/src/openwrt/staging_dir/host/include
-I/usr/src/openwrt/staging_dir/hostpkg/include
-I/usr/src/openwrt/staging_dir/target-aarch64_cortex-a53_musl/host/include"
CXXFLAGS="-O2 -I/usr/src/openwrt/staging_dir/host/include
-I/usr/src/openwrt/staging_dir/hostpkg/include
-I/usr/src/openwrt/staging_dir/target-aarch64_cortex-a53_musl/host/include"
LDFLAGS="-L/usr/src/openwrt/staging_dir/host/lib
-L/usr/src/openwrt/staging_dir/hostpkg/lib
-L/usr/src/openwrt/staging_dir/target-aarch64_cortex-a53_musl/host/lib"
CONFIG_SHELL="/usr/bin/env bash" bash ./configure
--target=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--build=x86_64-pc-linux-gnu --disable-dependency-tracking --program-prefix=""
--program-suffix="" --prefix=/usr/src/openwrt/staging_dir/hostpkg
--exec-prefix=/usr/src/openwrt/staging_dir/hostpkg
--sysconfdir=/usr/src/openwrt/staging_dir/hostpkg/etc
--localstatedir=/usr/src/openwrt/staging_dir/hostpkg/var
--sbindir=/usr/src/openwrt/staging_dir/hostpkg/bin ; fi )
touch /usr/src/openwrt/build_dir/hostpkg/libsepol-3.8.1/.configured
CFLAGS="-O2 -I/usr/src/openwrt/staging_dir/host/include
-I/usr/src/openwrt/staging_dir/hostpkg/include
-I/usr/src/openwrt/staging_dir/target-aarch64_cortex-a53_musl/host/include"
CPPFLAGS="-I/usr/src/openwrt/staging_dir/host/include
-I/usr/src/openwrt/staging_dir/hostpkg/include
-I/usr/src/openwrt/staging_dir/target-aarch64_cortex-a53_musl/host/include"
CXXFLAGS="-O2 -I/usr/src/openwrt/staging_dir/host/include
-I/usr/src/openwrt/staging_dir/hostpkg/include
-I/usr/src/openwrt/staging_dir/target-aarch64_cortex-a53_musl/host/include"
LDFLAGS="-L/usr/src/openwrt/staging_dir/host/lib
-L/usr/src/openwrt/staging_dir/hostpkg/lib
-L/usr/src/openwrt/staging_dir/target-aarch64_cortex-a53_musl/host/lib" make
-j1 -C /usr/src/openwrt/build_dir/hostpkg/libsepol-3.8.1/.
PREFIX=/usr/src/openwrt/staging_dir/hostpkg
SHLIBDIR=/usr/src/openwrt/staging_dir/hostpkg/lib
make[3]: Entering directory '/usr/src/openwrt/build_dir/hostpkg/libsepol-3.8.1'
make -C src
make[4]: Entering directory
'/usr/src/openwrt/build_dir/hostpkg/libsepol-3.8.1/src'
cc -I/usr/src/openwrt/staging_dir/host/include
-I/usr/src/openwrt/staging_dir/hostpkg/include
-I/usr/src/openwrt/staging_dir/target-aarch64_cortex-a53_musl/host/include -O2
-I/usr/src/openwrt/staging_dir/host/include
-I/usr/src/openwrt/staging_dir/hostpkg/include
-I/usr/src/openwrt/staging_dir/target-aarch64_cortex-a53_musl/host/include -I.
-I../include -D_GNU_SOURCE -I../cil/include -DHAVE_REALLOCARRAY -fPIC -c -o
assertion.o assertion.c
In file included from assertion.c:23:
/usr/src/openwrt/staging_dir/hostpkg/include/sepol/policydb/conditional.h:57:18:
error: two or more data types in declaration specifiers
57 | uint32_t bool;
| ^~~~
In file included from
/usr/src/openwrt/staging_dir/hostpkg/include/sepol/policydb/expand.h:30,
from assertion.c:26:
/usr/src/openwrt/staging_dir/hostpkg/include/sepol/policydb/conditional.h:57:22:
warning: declaration does not declare anything
57 | uint32_t bool;
| ^
assertion.c: In function 'report_failure':
assertion.c:48:44: warning: passin
Re: openwrt ONE: not getting enough PoE power
On Sat, Mar 15, 2025 at 06:27:38AM -0700, David Lang wrote: > I think the concern being raised is why didn't it power itself via the USB > port even if the PoE was low. +1 > > Also, I don't have mine handy, but is the PoE module plugged in or soldered > in? I thought it was a plugin It's soldered and cannot be removed easily. ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] kernel: Mediatek: fix EEE registers init
Hi Qingfang,
I've been testing EEE support on MT7986 as well as MT7988 with your
patches on top of OpenWrt's Linux 6.6.82.
I noticed that while the LPI timer of the MT753x DSA switch ports is
30us by default it is deplayed as 0us on the SoC's Ethernet ports, which
seems wrong... I guess this should be fixed as well.
Cheers
Daniel
On Wed, Mar 12, 2025 at 10:40:55PM +0800, Qingfang Deng wrote:
> Hi Jonas,
>
> Due to major API changes upstream, the feature wasn't backported as-is.
> https://web.git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=952d7325362ffbefa6ce5619fb4e53c2159ec7a7
>
> The original commit does not need fixes.
>
> Regards,
> Qingfang
>
> [Resent as plaintext mode]
>
>
> On Wed, Mar 12, 2025 at 10:21 PM Jonas Gorski wrote:
> >
> > Hi,
> >
> > On Sat, Mar 8, 2025 at 7:01 PM Qingfang Deng wrote:
> > >
> > > After booting, a "transmit queue 0 timed out" warning followed by a
> > > register dump was observed. The dump indicates that mtk_hw_init() does
> > > not initialize the EEECR during probe. This occurs because the
> > > netdev is allocated in mtk_add_mac(), which is called after
> > > mtk_hw_init(). Consequently, the EEECR register remains uninitialized
> > > until a reset is triggered, causing mtk_hw_init() to run again with a
> > > valid netdev, at which point the register is finally set.
> > >
> > > To address this, instead of modifying the probe sequence, latch the Tx
> > > LPI enable state and timer value, and move the EEECR register
> > > initialization to mtk_mac_link_up() to ensure proper setup when the
> > > interface comes up.
> > >
> > > Additionally, the splat reveals that LPI functionality is controlled by
> > > the MAC_MCR_EEE bits in the MCR register. Update mtk_set_eee() to
> > > modify these bits accordingly.
> > >
> > > Fixes: d8315d5358d5 ("kernel: backport Mediatek SoC EEE support")
> > > Fixes: edddbaf79ccf ("kernel: Mediatek: set default EEE Tx LPI timer")
> > > Signed-off-by: Qingfang Deng
> > > ---
> > > ...et-ethernet-mediatek-add-EEE-support.patch | 57 ---
> > > ..._eth_soc-add-hw-dump-for-forced-rese.patch | 4 +-
> > > ...net-mtk_eth_soc-enable-threaded-NAPI.patch | 2 +-
> > > ..._eth_soc-reset-all-TX-queues-on-DMA-.patch | 2 +-
> > > ..._eth_soc-compile-out-netsys-v2-code-.patch | 4 +-
> > > ..._eth_soc-work-around-issue-with-send.patch | 6 +-
> > > ...ernet-mtk_eth_soc-use-napi_build_skb.patch | 4 +-
> > > ...-mediatek-enlarge-DMA-reserve-buffer.patch | 2 +-
> > > ..._eth_soc-fix-memory-corruption-durin.patch | 2 +-
> > > ..._eth_soc-add-paths-and-SerDes-modes-.patch | 26 -
> > > ...th_soc-reduce-rx-ring-size-for-older.patch | 16 +++---
> > > ..._eth_soc-do-not-enable-page-pool-sta.patch | 4 +-
> > > 12 files changed, 71 insertions(+), 58 deletions(-)
> > >
> > > diff --git
> > > a/target/linux/generic/backport-6.6/753-v6.15-net-ethernet-mediatek-add-EEE-support.patch
> > >
> > > b/target/linux/generic/backport-6.6/753-v6.15-net-ethernet-mediatek-add-EEE-support.patch
> > > index d9b86ae36e..b908d133b5 100644
> > > ---
> > > a/target/linux/generic/backport-6.6/753-v6.15-net-ethernet-mediatek-add-EEE-support.patch
> > > +++
> > > b/target/linux/generic/backport-6.6/753-v6.15-net-ethernet-mediatek-add-EEE-support.patch
> > > @@ -23,34 +23,23 @@ Signed-off-by: Qingfang Deng
> > > MAC_MCR_FORCE_DPX | MAC_MCR_FORCE_TX_FC |
> > > MAC_MCR_FORCE_RX_FC);
> > >
> > > -@@ -811,6 +812,18 @@ static void mtk_mac_link_up(struct phyli
> > > +@@ -811,6 +812,15 @@ static void mtk_mac_link_up(struct phyli
> > > if (rx_pause)
> > > mcr |= MAC_MCR_FORCE_RX_FC;
> > >
> > > -+ if (mode == MLO_AN_PHY && phy && phy_init_eee(phy, false) >= 0) {
> > > -+ switch (speed) {
> > > -+ case SPEED_2500:
> > > -+ case SPEED_1000:
> > > -+ mcr |= MAC_MCR_EEE1G;
> > > -+ break;
> > > -+ case SPEED_100:
> > > -+ mcr |= MAC_MCR_EEE100M;
> > > -+ break;
> > > -+ }
> > > ++ if (mode == MLO_AN_PHY && phy && mac->tx_lpi_enabled &&
> > > phy_init_eee(phy, false) >= 0) {
> > > ++ mcr |= MAC_MCR_EEE100M | MAC_MCR_EEE1G;
> > > ++ mtk_w32(mac->hw,
> > > ++ FIELD_PREP(MAC_EEE_WAKEUP_TIME_1000, 17) |
> > > ++ FIELD_PREP(MAC_EEE_WAKEUP_TIME_100, 36) |
> > > ++ FIELD_PREP(MAC_EEE_LPI_TXIDLE_THD,
> > > mac->txidle_thd_ms),
> > > ++ MTK_MAC_EEECR(mac->id));
> > > + }
> > > +
> >
> > Please don't modify backported patches, they represent upstream
> > accepted changes, so they are immutable in that regard (apart from
> > required changes for adapting them to older kernels).
> >
> > Just add a patch on top that fixes the behavior, and ideally also send
> > it upstream to netdev so it gets proper revie
Re: BPI-R4 with Filogic 880 (Arm Cortex-A73): Spectre-BHB.
On Wed, Mar 05, 2025 at 02:13:04PM +0100, Martin Schiller wrote: > CONFIG_MITIGATE_SPECTRE_BRANCH_HISTORY was disabled with commit > 6b007d2512ad (treewide: disable spectre mitigation on unaffected Arm64 > targets) for all targets in target/linux/mediatek/filogic folder, but > the Arm Cortex-A73 in the Filogic 880 are affected [0]. > > So should we enable CONFIG_MITIGATE_SPECTRE_BRANCH_HISTORY for this > subtarget again? > > On the other hand, the target.mk in this subtarget folder states it is > CPU_TYPE:=cortex-a53, which is not correct for all the supported systems > in this subtarget. > > Do we have to split this subtarget into filogic830, filogic880, etc.? Imho it would make most sense to merge all the A53 subtargets, ie. no longer treat MT7622 separately. Afaik there is no real reason to do this. Then we can have a new A73 subtarget for MT7988 (and potentially other future SoC). > > Regards, > Martin > > [0] > https://developer.arm.com/Arm%20Security%20Center/Speculative%20Processor%20Vulnerability ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One JTAG
On Thu, Feb 27, 2025 at 12:07:22PM +0100, Charlemagne Lasse wrote: > Am Do., 27. Feb. 2025 um 09:41 Uhr schrieb John Crispin : > > > > JTAG has been tested and works fine, I managed to upload a ram uboot and > > reflash a board. obviously no mikrobus module can be populated. However > > it is recommended to use mtk_uartboot for worst case scenario recovery > > as described in the wiki > > i am talking about embedded development (like debugging) and not > recovery for a board when you have no initialization routine at all. We mostly intended JTAG for low-level firmware development, such as building a secure-boot enabled bootchain (ie. porting OP-TEE and fTPM) to work on that SoC. The JTAG signals of the SoC are shared with any other signals, due to pincount constraints of the MT7981B SoC we cannot use all features at the same time. pin 4 (JTAG_JTDO): device 11004000.serial function uart group uart2_0_tx_rx pin 5 (JTAG_JTDI): device 11004000.serial function uart group uart2_0_tx_rx pin 6 (JTAG_JTMS): device 11007000.i2c function i2c group i2c0_0 pin 7 (JTAG_JTCLK): device 11007000.i2c function i2c group i2c0_0 pin 8 (JTAG_JTRST_N): GPIO pinctrl_moore:520 (gpio-watchdog) This means you cannot use the UART and I2C exposed on the mikrobus socket at the same time with JTAG, and the watchdog should not be active. Also note that apart from Linux pinctrl, also ARM TrustedFirmware-A sets JTAG pins into GPIO state when started for security reasons: https://github.com/mtk-openwrt/arm-trusted-firmware/blob/mtksoc/plat/mediatek/mt7981/drivers/gpio/mt7981_gpio.c#L393 Using JTAG to debug the Linux kernel is not very practical anyway, imho there are better ways to do this. However, if you like to use JTAG to eg. debug U-Boot or OP-TEE you should build TF-A with ENABLE_JTAG=1. > > And it is definitely not working because you can't have the SoC > configured for JTAG on these pins while using it at the same time for > SPI and UART. And it is also unclear what the md32_ejtag_en does now. md32_ejtag_en exposes JTAG of the DSP inside the EN8811H 2.5G Ethernet PHY. It has nothing to do with the JTAG of the SoC. ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [VOTE] OpenWrt Two
On Wed, Feb 12, 2025 at 07:44:58PM +0100, John Crispin wrote: > starting a [VOTE] to get approval allowing me to begin the development of > OpenWrt "Two". +1 ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [VOTE] OpenWrt Two
On Thu, Feb 13, 2025 at 04:06:50PM +0100, John Crispin wrote: > > On 13.02.25 16:03, [email protected] wrote: > > Very interesting. > > Would also a SATA port be feasible ? > > the device will support ssd via pcie I hope that, like on the OpenWrt One, the M.2 slot is going to be on the top side of the board, so you could easily add an AHCI controller to have 2 or even 6 SATA ports for little money, see: https://www.aliexpress.com/item/1005007857109494.html https://www.aliexpress.com/item/1005006634906484.html (choose NVME to 2 SATA) ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 24.10 release status
On Mon, Feb 03, 2025 at 01:13:38AM +0100, Hauke Mehrtens wrote: > Hi, > > I had a look at the current issues for 24.10. Most of them are looking > harmless. > > Since 24.10.0-rc7 eeprom paring is broken for some devices, see: > https://github.com/openwrt/openwrt/issues/17818 > > I think this broke it: > https://github.com/openwrt/openwrt/commit/150aa9aeee509dba5255885618d8df372670e8f3 > > I would just revert to tomorrow if no one comes up with a real fix. Then the > MAC address is wrong, but at least the wifi comes up. > > > Linksys EA7500v1 and Linksys EA8500 do not get correct mac addresses and > then network is not working, see: > https://github.com/openwrt/openwrt/issues/17157 > Let me add https://github.com/openwrt/openwrt/issues/17808 to this which looks like a similar problem with MAC address assignment, but it's on MT7621 and effects the Ethernet port. > > I am planning to tag 24.10.0 final on Monday evening. > > Hauke ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 24.10 release status
On Fri, Jan 24, 2025 at 11:03:28PM +, Chester A. Unal wrote: > On 24/01/2025 22:15, Hauke Mehrtens wrote: > > > @arinc9: > > > > > > > > Currently we have the following known bugs: > > > > > > > > [...] > > > > * Ethernet link unstable on some mt7530 switches. Deactivate EEE > > > > (Energy-Efficient Ethernet) as a workaround, see: > > > > https://github.com/openwrt/openwrt/issues/17351 > > > > > > Any idea what could be going on there? > > Here are the facts to consider: > > We have only started receiving reports of the unstable link issue with the > 24.10 branch. > > I believe the MT753X DSA subdriver did not receive changes in years with > regards to EEE or any other parts of the code that would cause link > instability. I am giving this opinion as a maintainer of the said > subdriver. > > There's a report by Florian [1], stating that the same issue appears with a > PHY that is not part of the MT7530 switch hardware. So the issue is > apparent on a system that does not have the MT7530 switch involved, and the > only common part of the reports is the MediaTek Ethernet driver. Thanks for the quick summary. Note that regarding Florian's report, on the WAX206 the RTL8221B-BV-VG PHY is connected to port 5 of the MT7531AE switch [1] and hence NOT to the MAC of MT7622 SoC. So it can of course still be an issue with that PHY (which has been giving us some trouble in general), but I'd be very confused if you insist that it would be caused by mtk_eth_soc, and would ask you to explain why you think that would be the case. [1]: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/mediatek/dts/mt7622-netgear-wax206.dts;h=4881004ac3b750bccb639e60da16196b2bd7129a;hb=HEAD#l186 ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 24.10 release status
On Fri, Jan 24, 2025 at 10:05:04PM +0100, Hauke Mehrtens wrote: > @Daniel: Is this PR fine about the rtl 2.5G PHY ready to merge or just a > test? > https://github.com/openwrt/openwrt/pull/17701 Well, it seems to resolve the issue, but I don't think it's the correct fix. Feel free to merge and backport, now that I've been stairing at that issue for some time I think that we already got some other work-arounds for what is probably the same issue under the hood: - 052732bddb generic: 6.6: fix early RTL8221B detection - 28b3a5e6b5 generic: net: phy: realtek: detect early version of RTL8221B So this is basiacally the same issue: The PHY (or the MDIO bus on those MediaTek SoCs?) not responding meaningful values to (C22 and C45) reads for some time early during boot. Increasing the PHY reset assert and deassert times also doesn't reliably fix the issue; and why should the same PHY require 100x the specified time after reset has been deasserted than it needs on other boards?! And then the fact that swapping gmac0 and gmac1 in DT also fixes it, another hint that we are dealing with something related to timing of the MDIO bus driver rather than an issue related to the PHY itself. Plus MediaTek got this rather odd patch in their SDK: https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+/refs/heads/master/autobuild/unified/global/24.10/files/target/linux/mediatek/patches-6.6/999-2700-net-ethernet-mtk_eth_soc-add-mdio-reset-delay.patch (importing that to OpenWrt however doesn't fix the issue with RTL8221B) All that being said, it's probably better to have that work-around than having broken Ethernet on some but not all devices using RTL8221B-VB-CG... @arinc9: > > Currently we have the following known bugs: > > [...] > * Ethernet link unstable on some mt7530 switches. Deactivate EEE > (Energy-Efficient Ethernet) as a workaround, see: > https://github.com/openwrt/openwrt/issues/17351 Any idea what could be going on there? ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] mediatek: filogic: add support for GatoNetworks GDSP
Hi Enrico,
the patch generally looks very good.
Few things:
- It would be better to use NVMEM in device tree to assign MAC
addresses.
- You could use 'fitblk' in order to have the bootloader validate the
whole image before booting and prevent bootloops in case of corrupted
squashfs (eg. due to loss of power during sysupgrade).
- Maybe split this patch into three, so it becomes easier to read:
1/3 Add device to U-Boot
2/3 Add device to uboot-envtools
3/3 Add device to mediatek target
See comments inline below illustrating the first two points.
On Sun, Nov 03, 2024 at 05:30:34PM +0100, Enrico Mioso wrote:
> [...]
> --- /dev/null
> +++ b/target/linux/mediatek/dts/mt7981b-gatonetworks-gdsp.dts
> @@ -0,0 +1,377 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +
> +/dts-v1/;
> +#include "mt7981.dtsi"
> +
> +/ {
> + model = "GatoNetworks GDSP";
> + compatible = "gatonetworks,gdsp", "mediatek,mt7981";
> +
> + aliases {
> + serial0 = &uart0;
> + label-mac-device = &wifi;
> + led-boot = &sg1;
> + led-failsafe = &sg1;
> + led-running = &sg1;
> + led-upgrade = &sg1;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + bootargs = "console=ttyS0,115200n1
> earlycon=uart8250,mmio32,0x11002000";
rootdisk = <&firmware>;
> + };
> [...]
> + partition@18 {
firmware: partition@18 {
> + label = "firmware";
> + reg = <0x18 0x1E8>;
> + };
> [...]
> + gatonetworks,gdsp)
> + local factory_dev="/dev/mtd$(find_mtd_index "Factory")"
> + label_mac=$(get_mac_binary $factory_dev 0x4)
Why not use NVMEM and mac-base to read and assign the MAC address?
> [...]
> ---
> a/target/linux/mediatek/filogic/base-files/etc/hotplug.d/ieee80211/11_fix_wifi_mac
> +++
> b/target/linux/mediatek/filogic/base-files/etc/hotplug.d/ieee80211/11_fix_wifi_mac
> @@ -89,6 +89,11 @@ case "$board" in
> addr=$(mtd_get_mac_binary "Odm" 0x81)
> [ "$PHYNBR" = "1" ] && macaddr_add $addr 3 >
> /sys${DEVPATH}/macaddress
> ;;
> + gatonetworks,gdsp)
> + addr=$(get_mac_label)
> + [ "$PHYNBR" = "0" ] && echo "$addr" > /sys${DEVPATH}/macaddress
> + [ "$PHYNBR" = "1" ] && macaddr_setbit_la $(macaddr_add $addr 1)
> > /sys${DEVPATH}/macaddress
Same here, use NVMEM and mac-base if possible.
> --- a/target/linux/mediatek/filogic/base-files/lib/upgrade/platform.sh
> +++ b/target/linux/mediatek/filogic/base-files/lib/upgrade/platform.sh
> @@ -111,6 +111,7 @@ platform_do_upgrade() {
> ;;
> cudy,re3000-v1|\
> cudy,wr3000-v1|\
> + gatonetworks,gdsp|\
Move the device into group of devices uses fitblk.
> [...]
> +define Device/gatonetworks_gdsp
> + DEVICE_VENDOR := GatoNetworks
> + DEVICE_MODEL := gdsp
> + DEVICE_DTS := mt7981b-gatonetworks-gdsp
> + DEVICE_DTS_DIR := ../dts
> + IMAGES := sysupgrade.bin
> + IMAGE_SIZE := 32768k
> + DEVICE_PACKAGES := kmod-mt7915e kmod-mt7981-firmware mt7981-wo-firmware \
> +kmod-usb-net-qmi-wwan uqmi kmod-usb3 kmod-usb-serial-option \
> +-kmod-phy-aquantia
Add 'fitblk' package.
Set KERNEL and KERNEL_INITRAMFS like BPi-R3.
___
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 24.XX release plan
On Wed, Oct 23, 2024 at 07:52:23PM +, Eric wrote: > On Wednesday, October 23rd, 2024 at 10:25, Christian Marangi (Ansuel) > wrote: > > > Well mainly it's the luci app and extensive testing. > > Is there a version of 'ubus call rpc-sys packagelist' reworked to handle the > APK package lists living somewhere that I could play with? I had a local branch of rpcd which reads APKv2 status files instead of OPKG status, pushed it as a patch into Paul's apk tree in February this year, but don't have it on my laptop which I travel with right now. Sadly Paul seems to have deleted that old apk branch from back then, but it's easy to implement it again if needed before I return home. > > https://github.com/openwrt/rpcd/blob/master/sys.c#L184 > > If we're sticking with opkg, I'd like to see > https://github.com/openwrt/rpcd/issues/6 fixed, as it may impact upgrade > tools. That we should do anyway: https://github.com/openwrt/rpcd/pull/8 ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 24.XX release plan
On Wed, Oct 23, 2024 at 07:25:53PM +0200, Christian Marangi (Ansuel) wrote: > Il giorno mer 23 ott 2024 alle ore 19:22 Daniel Golle > ha scritto: > > > > On Wed, Oct 23, 2024 at 05:52:30PM +0200, Christian Marangi (Ansuel) wrote: > > > Il giorno mer 23 ott 2024 alle ore 17:51 Petr Štetiar > > > ha scritto: > > > > > > > > Hauke Mehrtens [2024-09-21 11:51:19]: > > > > > > > > Hi, > > > > > > > > > We should already start building up the build infrastructure for a > > > > > 24.10 > > > > > branch now. > > > > > @ynezz: What is needed for that? > > > > > > > > tl;dr basically just the openwrt-24.10 branches in the Git repositories > > > > > > > > Rough procedure is here > > > > https://openwrt.org/docs/guide-developer/releases/buildbot-major-releases > > > > > > > > > > I think it's too late for APK > > > > > > If everyone is OK I can take care of branching this week with the current > > > state. > > > > I don't think we should wait with APK -- even if initially packages in > > the package feeds are still failing because their version string is not ok > > for APK, creating a release branch with APK being the default package > > manager will make it clear to everyone this is going to happen and the > > remaining (trivial) changes can be done to packages in their respective > > feeds. > > > > I understood that index based trust is now impemented in APK: > > https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/11008 > > > > What else is missing? > > > > Well mainly it's the luci app and extensive testing. If we really want > we can ""abuse"" the rc stage for testing. I think it's pretty normal that not everything in feeds is ready at the moment we create a release branch. Creating the release branch and starting 24.10-SNAPSHOT builds also doesn't imply creating a release candidate right away imho. > > APK is already usable. Exactly, from my experience it works fine, I've tested ImageBuilder and run some APK-based images -- just not my own local server with package indexes and all that... If on the buildbot side everything is ready to do the switch, then lets do it as soon as possible I'd say. ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 24.XX release plan
On Wed, Oct 23, 2024 at 05:52:30PM +0200, Christian Marangi (Ansuel) wrote: > Il giorno mer 23 ott 2024 alle ore 17:51 Petr Štetiar > ha scritto: > > > > Hauke Mehrtens [2024-09-21 11:51:19]: > > > > Hi, > > > > > We should already start building up the build infrastructure for a 24.10 > > > branch now. > > > @ynezz: What is needed for that? > > > > tl;dr basically just the openwrt-24.10 branches in the Git repositories > > > > Rough procedure is here > > https://openwrt.org/docs/guide-developer/releases/buildbot-major-releases > > > > I think it's too late for APK > > If everyone is OK I can take care of branching this week with the current > state. I don't think we should wait with APK -- even if initially packages in the package feeds are still failing because their version string is not ok for APK, creating a release branch with APK being the default package manager will make it clear to everyone this is going to happen and the remaining (trivial) changes can be done to packages in their respective feeds. I understood that index based trust is now impemented in APK: https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/11008 What else is missing? ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] linux: generic: net: dsa: mv88e6xxx LED support
Hi Linus, thank you for your patch contribution. On Sun, Oct 06, 2024 at 05:32:04PM +0200, Linus Walleij wrote: > This solution that is needed for some routers to provide proper > LED activity when controlled directly by the MV88E6xxx switch, > has just been merged in upstream Linux. > [...] > diff --git > a/target/linux/generic/pending-6.6/714-net-dsa-mv88e6xxx-Support-LED-control.patch > > b/target/linux/generic/pending-6.6/714-net-dsa-mv88e6xxx-Support-LED-control.patch > new file mode 100644 > index ..8557fe2510b8 > --- /dev/null > +++ > b/target/linux/generic/pending-6.6/714-net-dsa-mv88e6xxx-Support-LED-control.patch > [...] > diff --git > a/target/linux/generic/pending-6.6/768-net-dsa-mv88e6xxx-Request-assisted-learning-on-CPU-port.patch > > b/target/linux/generic/pending-6.6/768-net-dsa-mv88e6xxx-Request-assisted-learning-on-CPU-port.patch > index 3f3d7572e015..92f87f619873 100644 > --- > a/target/linux/generic/pending-6.6/768-net-dsa-mv88e6xxx-Request-assisted-learning-on-CPU-port.patch > +++ > b/target/linux/generic/pending-6.6/768-net-dsa-mv88e6xxx-Request-assisted-learning-on-CPU-port.patch As both patches are now already part of mainline Linux they should go into target/linux/generic/backport-6.6/ with a 'v6.13' prefix (as they are expected to be part of Linux v6.13). ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: BPI-R4: Copper SFP issues
On 1 August 2024 07:26:35 UTC, Martin Schiller wrote: >Hi! > >I've got some issues bringing up copper SFPs in a BananaPi BPI-R4 runnig >the latest OpenWrt master. Using the original Firmware pre-installed on >the BPI-R4 makes the modules work as expected: > >I've tested with a HPE J8177C 1GBASE-T module as well as with a FS >SFP-10G-T module. > >Any ideas what could be wrong here? > >Here are the debug log outputs: >[ 81.554779] mtk_soc_eth 1510.ethernet eth2: validation with support >00,,, failed: -EINVAL >[ 81.565458] sfp sfp1: sfp_add_phy failed: -EINVAL >[ 81.570155] sfp sfp1: SM: exit present:up:fail Looks like you are simply missing kmod-phy-marvell as well as kmod-phy-marvell-10g. Do you have those driver module packages installed? ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: files for jailed process's
On Tue, Jul 30, 2024 at 03:40:25PM +0200, e9hack wrote: > Hi, > > if a process is started via procd in a jail and uses some files, changes to > those files outside the jail are not reflected inside the jail. For E.g. > dnsmasq runs in a jail. The configuration is changed, that only the host file > does change. Sending SIGHUP to dnsmasq results in reloading of the unmodified > host file. > > Is it possible to change this behaviour? What you are observing is typically caused by the file being replaced rather than edited. In that case, the mount-bind on the old file will remain, and you will not be able to access the new (replacement) file inside the jail. This is due to the nature of mount --bind which attaches itself to a specific inode on the filesystem rather than to a filename. There are two ways to work around this problem: 1. Actually edit instead of replace the file. 2. procd_add_jail_mount_ro a folder instead of a file. In that way, the replaced file will also show up. As in most cases only strategy 2 is truely a good option we have already moved resolv.conf.auto into a folder of its own. If the same problem also occurs for other dnsmasq config files, we shall introduce a folder for all of them and add that using procd_add_jail_mount_ro to make it accessible inside the jail instead of calling procd_add_jail_mount_ro for individual files. ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: sysupgrade.openwrt.org IPv6 appears dead
Hi Eric, Hi Digitalocean operators, On Wed, Jun 26, 2024 at 10:54:36PM +, Eric via openwrt-devel wrote: > [...] > 11: digitalocean-ic-378007.ip.twelve99-cust.net 162.834ms > 12: 2a03:b0c0:fffe::92 151.227ms > 13: no reply > ... all no reply > 30: no reply > Too many hops: pmtu 1500 > Resume: pmtu 1500 > > I seem to recall that twelve99 has a less than stellar reputation for this > sort of issue... > > How would one report such a problem? Or do we just wait for the routing > tables to get updated? inet6num: 2a03:b0c0::/32 netname:US-DIGITALOCEANLLC-20121228 country:NL Something seems wrong with the route from twelve99 to our host at digitalocean, as hop 12 is within DO network and our sysupgrade.openwrt.org box is hosted with DO. Maybe Paul or someone with direct contact to DO can create a ticket there, I'm not sure if sending an email to the noc@ address is enough. Cheers Daniel ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: sysupgrade.openwrt.org IPv6 appears dead
Hi Eric, On Wed, Jun 26, 2024 at 09:44:04PM +, Eric 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. > Date: Wed, 26 Jun 2024 21:44:04 + > From: Eric > To: openwrt-devel , Paul Spooren > > Subject: sysupgrade.openwrt.org IPv6 appears dead > > Maybe DNS isn't updating or something? > > In any case, attempts to grab stuff from https://sysupgrade.openwrt.org are a > crapshoot, depending on whether the client chooses the IPv4 or IPv6 address. > > This 'wget' keeps retrying forever, while '-4' gets the file without pause. > > $ wget -6 --connect-timeout=10 > https://sysupgrade.openwrt.org/json/v1/overview.json > --2024-06-26 14:41:43-- https://sysupgrade.openwrt.org/json/v1/overview.json > Resolving sysupgrade.openwrt.org... 2a03:b0c0:3:d0::1574:1 > Connecting to sysupgrade.openwrt.org|2a03:b0c0:3:d0::1574:1|:443... failed: > Operation timed out. > Retrying. > please check your IPv6 routing and firewall, it definitely works fine for me: [daniel@box ~]$ wget -6 --connect-timeout=10 https://sysupgrade.openwrt.org/json/v1/overview.json --2024-06-26 22:53:54-- https://sysupgrade.openwrt.org/json/v1/overview.json Loaded CA certificate '/etc/ssl/certs/ca-certificates.crt' Resolving sysupgrade.openwrt.org (sysupgrade.openwrt.org)... 2a03:b0c0:3:d0::1574:1 Connecting to sysupgrade.openwrt.org (sysupgrade.openwrt.org)|2a03:b0c0:3:d0::1574:1|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 17634 (17K) [application/json] Saving to: ‘overview.json’ overview.json 100%[=>] 17.22K --.-KB/sin 0.04s 2024-06-26 22:53:55 (449 KB/s) - ‘overview.json’ saved [17634/17634] [daniel@box ~]$ tracepath -6 sysupgrade.openwrt.org 1?: [LOCALHOST]0.013ms pmtu 1500 1: [privacy] 0.369ms 1: [privacy] 0.306ms 2: [privacy] 0.824ms asymm 1 3: [privacy] 4: [privacy] 4.474ms asymm 3 5: [privacy] 6: [privacy] 39.110ms asymm 5 7: fra2-edge1.digitalocean.com 38.661ms asymm 6 8: fra2-edge1.digitalocean.com 39.138ms asymm 6 9: no reply 10: no reply 11: no reply 12: no reply 13: no reply 14: asu-01.infra.openwrt.org 39.495ms reached Resume: pmtu 1500 hops 14 back 12 Cheers Daniel ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt's out-of-tree 204-module_strip.patch causes issues
On 1 June 2024 20:23:20 UTC, "Arınç ÜNAL" wrote: >I've been working on porting MP-DCCP to Teltonika SDK 7.6.10. The SDK is >based off of OpenWrt, close to 22.03.6. After spending hours on figuring >out why my MP-DCCP port works on the vanilla 5.10.201 but not OpenWrt's >5.10.201, I've started looking for OpenWrt's out-of-tree kernel patches. I >was able to pinpoint it to >target/linux/generic/hack-5.10/204-module_strip.patch. I see that this >patch is still there for 6.6 on the main branch of the OpenWrt repository. I guess that's the price to pay for space reduction And I guess the fact that Teltonika bases their OS on OpenWrt is also because they manage to implement a dual-boot system with 16MB of flash, so there is some direct causal connection here, SPI-NOR still being much more reliable and cheaper than an eMMC which could fit Debian or whatever other OS... Anyway, does that warning also occur if CONFIG_MODULE_STRIPPED isn't selected? And is there any functional impact besides that warning? > >For my case, I just removed this patch and moved on. I'm only sending this >email as proof that OpenWrt's out-of-tree patches cause issues. > >[1.897757] [ cut here ] >[1.902441] WARNING: CPU: 0 PID: 1 at fs/sysfs/group.c:116 >internal_create_group+0x3ac/0x3d4 >[1.911179] Modules linked in: >[1.914253] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.10.201 #0 >[1.920346] Hardware name: Mediatek Cortex-A7 (Device Tree) >[1.925936] [] (unwind_backtrace) from [] >(show_stack+0x10/0x14) >[1.933688] [] (show_stack) from [] >(dump_stack+0x88/0x9c) >[1.940917] [] (dump_stack) from [] (__warn+0x9c/0xf8) >[1.947796] [] (__warn) from [] >(warn_slowpath_fmt+0x68/0x78) >[1.955287] [] (warn_slowpath_fmt) from [] >(internal_create_group+0x3ac/0x3d4) >[1.964258] [] (internal_create_group) from [] >(mpdccp_link_sysfs_init+0x90/0xb4) >[1.973489] [] (mpdccp_link_sysfs_init) from [] >(mpdccp_link_module_init+0x24/0xdc) >[1.982889] [] (mpdccp_link_module_init) from [] >(do_one_initcall+0x54/0x1f4) >[1.991769] [] (do_one_initcall) from [] >(kernel_init_freeable+0x22c/0x280) >[2.000474] [] (kernel_init_freeable) from [] >(kernel_init+0x8/0x118) >[2.008657] [] (kernel_init) from [] >(ret_from_fork+0x14/0x2c) >[2.016229] Exception stack(0xc1079fb0 to 0xc1079ff8) >[2.021282] 9fa0: > >[2.029465] 9fc0: > >[2.037645] 9fe0: 0013 >[2.044348] ---[ end trace a1a1b229e3c1a883 ]--- > >Arınç > >___ >openwrt-devel mailing list >[email protected] >https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: measured boot / fTPM and OpenWrt One
Hi Michael,
On Fri, May 10, 2024 at 03:03:27PM -0400, Michael Richardson wrote:
>
> Daniel Golle wrote:
> > On Mon, Apr 29, 2024 at 03:04:37PM -0400, Michael Richardson wrote:
> >>
> >> {sorry for the long delay, been unwell}
> >>
> >> Bjørn Mork wrote:
> >> > Maybe it is possible to deploy the system with secure boot and a
> >> > protected IDevId key by default, but allowing the user/owner to erase
> >> > the key and disable secure boot? This way all use cases could be
> >> > supported, including playing with the BL2 code etc.
> >>
> >> It won't work that way. If someone can easily turn off secure boot,
> then so can malware.
>
> > Malware cannot remove or add a physical jumper or press a physical
> button
> > on the board (we got a jumper to write-protect the SPI-NOR flash).
>
> Well, that's certainly true. It is not always possible to talk to the
> outside world from inside that initial boot enclave. That's the detail that
> we need.
> Do we even have a spare GPI(o) pin that can be used for this?
> (It can't be used for anything else)
While I see your point and believe this is generally possible, it's more
than just one bit needed here: It would mean to move the whole GPIO controller
into secure land and then make all the other bits again available to non-secure
land via SMC calls or something like that...
>
> > The only option of having secure boot enabled would be to allow users to
> > permanently disable it, otherwise the resulting hardware would not be
> > worth being called "Open", as it would, in fact, be closed.
>
> The board could ship with it disabled, and the user could blow the fuse to
> enable it.
If the fuse was documented or the tool for doing this available without
signing an NDA with MediaTek, then yes. Both is currently not the case.
> I am not really a fan of secure boot, I prefer measured boot.
> To get that, we need to have a possible fTPM enabled, and this generally has
> to happen before u-boot. This is annoying, I agree.
>
> If you look at the diagram at:
> https://mediatek.gitlab.io/aiot/doc/aiot-dev-guide/master/sw/yocto/boot.html
>
> which is *not* our CPU/SOC, but is probably consistent with things, then you
> see that to get fTPM, it happens before u-boot.
Yes, it's exactly the same on the router SoCs, or it least it *can* be
done like that (TF-A as trusted boot firmware). I've also seen U-Boot
instead of bl2 loading BL31 and OP-TEE, but that's probably considered
legacy stuff from the last decade.
>
> Some would argue that a board that ships with a private key in storage that
> is not, at ship-time, protected, is worthless, but I disagree. It's a
> risks/benefits tradeoff.
> (Note: I'm the lead editor for RFC9334)
>
> I've been down this road a few times with other boards, and the supply chain
> is
> generally very difficult to work with on this. This is one reason I would
> really like to make some progress here. It helps us get in front of the
> situation, providing a good reference on how to do this sanely.
>
> And because I think that many of our (other) platforms will find themselves
> thinking they are forced down the secureboot path by recent UK, USA
> legislation: probably not quite literally by the legislation, but the lawyers
> and PHBs will think it.
It's a bit funny that the blame for that curse commonly goes to the
FCC and UK authorities, because the discussion started with the ETSI
Radio Emissions Directive (RED) 10 years ago...
>
> I've removed the rest of your well-thought discussion about minimal security.
> What I care about it getting an initial credential into the device, and to be
> able to leverage that to get HTTPS for the admin interface, and for that to
> lead to APIs for managing IoT devices.
>
> > dealing with it kinda means living in denial and darkness. Hence,
> > despite all the critizism, I do appreciate your work and effort to allow
> > people to get their hands on OP-TEE, fTPM, ... on the OpenWrt One.
>
> Yes, so this one place that is very hard for people to learn about, because
> the pre-uboot steps are hidden :-(
ARM TrustedFirmware-A is easy to understand code and released under an
Open Source license, we build it from source in OpenWrt for that platform.
OP-TEE is an Open Source project as well, and so is Microsoft's fTPM.
Just got to put the pieces together, but the pink elephant are the missing
documentation and tools for the efuses to make the BootROM validate bl2
signature...
>
> >> I hope we can go the other way.
>
Re: Install LuCI for snapshots builds
On Tue, May 07, 2024 at 11:52:02PM +0200, Robert Marko wrote: > On Tue, 7 May 2024 at 23:25, Paul Spooren wrote: > > > > Hi all, > > > > For some reason (resource usage?) our snapshot builds do not include the > > LuCI web interface. I think it’s an advantage to have LuCI installed in > > snapshot images since a) it installed for all releases anyway and b) often > > it’s just nice to have the web interface directly available. > > > > Is anyone against having the interface installed by default? I remember > > from multiple (in-person) discussion with fellow developers, that they’d > > prefer it being installed. > > > > If it’s an oversight I’d like to see it added to the default packages (via > > the builedbot config), if there’s a reason to keep it from snapshots, I’d > > like to understand the details. > > +1 for LuCI by default in snapshots as well from me. I understand the usability we may gain from that but you should all be aware that this basically means only having a single buildbot phase with a very slow turnover time, and that is a HUGE disadvantage for development and use of the buildbot as classic CI took. Let me explain why: Currently the snapshot builders are only building **target-specific** packages as well as packages included in the image by default. (We call that "phase1"). That means that a single build takes around 2~3 hours, depending on the target and the machine carrying out the build. In this way we manage to have every target build once approximately every 24 hours. If we wanted to include LuCI, that would basically mean that we will not only have to include all the LuCI modules and applications, but also **all their dependencies** which is basically half of the packages feed. A full build of the packages feed (called "phase2") takes around 4 additional hours (best-case) and up to 17h (worst-case). We also don't build for each (sub-)targets (think: ramips/mt7621), but only for each architecture (think: mips24kc), and many (sub-)targets share the same architecture. This results in every **architecture** being re-built approximately every two days. If we would do this for all (sub-)targets, the number would obviously be even worse, we'd probably only see fresh images once or twice a week, which is too slow to catch problems and too long for users to test changes in a timely manner. It would be a humongous slow down of development and testing on generic and core parts. For me it would mean that I would have to invest a mid four-digit $ amount into hardware to still be able to do meaningful development, and probably it would mean that for quite a few of us. What I could imaging is to have an **additional** build stop on top of that, lets call it "phase3". That could be triggered on completion of phase2 and then assemble images for all (sub-)targets using that architecture including LuCI **in addition** to the phase1 snapshot builds. From a usability point of view, maybe the answer can be much easier and the solution is already there: 1. Go to https://firmware-selector.openwrt.org/ 2. Select 'SNAPSHOT' on the right. 3. Enter the device you want to put OpenWrt on or update. 4. Click on "Customize installed packages and/or first boot script" 5. Add 'luci' (or 'luci-ssl' or 'luci-ssl-openssl', ...) to the list of to-be-installed packages. Maybe we can have an easier way to do that in that web UI and then everybody will be happy? And yes, the images generated using the firmware-selector are being cached there. In this way only the first user requesting an image with additional packages (luci in this case) would have to wait ~ 1 minute for the image to be generated, every subsequent user requesting the same image would be served instantly. The advantage would also be that we don't generated huge amounts of images for legacy devices without any users, nor for "science-fiction" R&D platforms. Just my 2 cents... ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One / project update
Hi Michael,
On Mon, Apr 29, 2024 at 03:04:37PM -0400, Michael Richardson wrote:
>
> {sorry for the long delay, been unwell}
>
> Bjørn Mork wrote:
> > Maybe it is possible to deploy the system with secure boot and a
> > protected IDevId key by default, but allowing the user/owner to erase
> > the key and disable secure boot? This way all use cases could be
> > supported, including playing with the BL2 code etc.
>
> It won't work that way. If someone can easily turn off secure boot, then so
> can malware.
Malware cannot remove or add a physical jumper or press a physical button
on the board (we got a jumper to write-protect the SPI-NOR flash).
The only option of having secure boot enabled would be to allow users to
permanently disable it, otherwise the resulting hardware would not be
worth being called "Open", as it would, in fact, be closed.
Believing that secure boot could provide protection from malware also misses
an important point: Most malware nowadays doesn't even strive for
persistency but rather relies on exploitable run-time vulnerabilities.
We are in an always-online world, the classic "boot sector virus" is
an archaic thing from the 1980s.
Hence, a simple reboot would get rid of most IoT malware already today
and without secure boot, as leaving a trace on the flash would make the
infection recognizable: Cutting the power and dumping the content of the
flash is easy for malware analists. Dumping the content of the (DDR4)
RAM of a rootkit'ed system is not at all, it's nearly impossible.
The only really meaningful way to enhance system security on a technical
level is hence to reduce the attack surface and makeing sure the system
cannot be exploited at runtime. That means a whole lot of things,
ranging from human and machine review (ideally formal verification),
reproducible builds and a cryptographically trusted supply chain down to
language guarantees such as memory safety, making sure the code is easy
to understand, always keeping complexity as low as possible and much
more.
As secondary measures the principle of least privileges should be
applied, sandboxing, memory address randomization, even mandatory
access control systems like SELinux all have their place there.
Needless to say that there have also been vulnerabilities in the secure
enclaves as well as their secure operating systems, and that offered a
whole new dimension to nasty and persistent, and hard to detect malware.
So while I can see that having stuff like measured boot and TPM
encrypted credentials is generally nice to have, it quickly becomes
obvious that all that only works on a trusted computing environment, and
even then is only moderately meaningful if you consider the common
malware attack vectors: If an endpoint can authenticate my client using
credentials protected by a TPM or secure enclave, so can anyone else
*temporarily* in control of the client system at the same level of
privileges. And measured boot would not provide any meaningful way to
prevent that.
I think the recent increase of rather simple two-way-repeater attacks on
things like contactsless (and PIN-less) NFC payment systems as well as
car thefts aided by repeating Keyless Go demonstrates that point very
well.
Imho the whole secure boot fuzz is mostly about protecting the system
and its *remote* operators ("platform providers") from the actual users.
It's really very useful for that: SaS and other kind of intellectual
property licencing and subscriptions businesses. Things like Widevine
which is made to prevent users from source-ripping 4k HDR video content.
All that being said, I still believe it's important to have the core
components of all that stuff available as reproducible free open source
software, so people can learn how it all works and play with it
hands-on, just because it became ubiquitous in modern life and not
dealing with it kinda means living in denial and darkness. Hence,
despite all the critizism, I do appreciate your work and effort to allow
people to get their hands on OP-TEE, fTPM, ... on the OpenWrt One.
> I hope we can go the other way.
>
> I'm willing to do the legwork, and I can sign an NDA if necessary, and then
> communicate what needs to be said.
NDA with whom? MediaTek?
When it comes to OpenWrt and the OpenWrt One: As a first step we would
have to come up with the methods to run the necessary PKI infrastructure
in a democratic and distributed way, without requiring any NDAs and
without any single point of responsibility or potential bus-factor.
Cheers
Daniel
>
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
___
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/2] realtek/rtl839x: respect phy-is-integrated property
Hi Stijn, On Sat, Apr 27, 2024 at 01:40:07AM +0300, [email protected] wrote: > Respect the phy-is-integrated property on ethernet-phy nodes. > > There are RTL8393M switches where the PHYs at address 48 and 49 are > provided by an external RTL8214FC. Hardcoding them to use the internal > SerDes makes it impossible to use the ports connected to such an > external PHY. Respect the phy-is-integrated property on ethernet-phy > nodes as a first step to support such ports. Yes, we should get rid of all mentions of port addresses in the Ethernet driver. Thank you for taking care of that. Sidenote: Those aren't actual (MDIO bus) PHY addresses. RealTek switches got an internal mapping which is setup by the driver which map the addresses of the actual PHYs on actual physical MDIO (aka SMI) busses to the ports of the switch. MDIO bus uses 5-bit address, hence an address greater than 31 is nonsense and should rather be called a port address or a port-mapped PHY address. Transparently exposing the actual physical busses and having the driver reverse the augmentation of the addresses using the (hardware) mapping between switch ports and PHYs would probably be the best, and allow for the use of generic PHY (and PHY package) drivers instead of a lot of RealTek-specific hacks. I started working on that some time ago and may get back to it if I find the time. > > The potential impact for this should be limited to RTL8393 based > switches, and looking at the commit messages and device tree files of > the supported switches based on this SoC, the SFP and/or combo ports are > either not working (D-Link DGS-1210-52, Netgear GS750E, TP-Link > SG2452P/T1600G-52PS), use PHYs at a different address (Panasonic > SwitchM48EG PN28480K), or already have the phy-is-integrated property > set on the PHYs at address 48 and 49. > > Signed-off-by: Stijn Tintel Acked-by: Daniel Golle > --- > .../realtek/files-5.15/drivers/net/ethernet/rtl838x_eth.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git > a/target/linux/realtek/files-5.15/drivers/net/ethernet/rtl838x_eth.c > b/target/linux/realtek/files-5.15/drivers/net/ethernet/rtl838x_eth.c > index 54e592aeaa..71e7937336 100644 > --- a/target/linux/realtek/files-5.15/drivers/net/ethernet/rtl838x_eth.c > +++ b/target/linux/realtek/files-5.15/drivers/net/ethernet/rtl838x_eth.c > @@ -1658,7 +1658,7 @@ static int rtl839x_mdio_read_paged(struct mii_bus *bus, > int mii_id, u16 page, in > int err; > struct rtl838x_eth_priv *priv = bus->priv; > > - if (mii_id >= 48 && mii_id <= 49 && priv->id == 0x8393) > + if (priv->phy_is_internal[mii_id]) > return rtl839x_read_sds_phy(mii_id, regnum); > > if (regnum & (MII_ADDR_C45 | MII_ADDR_C22_MMD)) { > @@ -1797,7 +1797,7 @@ static int rtl839x_mdio_write_paged(struct mii_bus > *bus, int mii_id, u16 page, > struct rtl838x_eth_priv *priv = bus->priv; > int err; > > - if (mii_id >= 48 && mii_id <= 49 && priv->id == 0x8393) > + if (priv->phy_is_internal[mii_id]) > return rtl839x_write_sds_phy(mii_id, regnum, value); > > if (regnum & (MII_ADDR_C45 | MII_ADDR_C22_MMD)) { > -- > 2.43.2 > > > ___ > openwrt-devel mailing list > [email protected] > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One / project update
On Fri, Apr 12, 2024 at 05:37:22PM -0400, Michael Richardson wrote: > > John Crispin wrote: > >> using OP-TEE and fTPM. > > > pretty high on my list once we find the time > > > > https://trustedfirmware-a.readthedocs.io/en/latest/components/spd/index.html > > > https://trustedfirmware-a.readthedocs.io/en/latest/components/spd/optee-dispatcher.html > > Where you thinking about OP-TEE as the BL32, or were you thinking that we > could attempt this: >OP-TEE OS after boot via an SMC call by enabling the option for >OPTEE_ALLOW_SMC_LOAD Imho only OP-TEE as BL32 really makes sense. Running U-Boot as secure OS is insane and nobody should be doing that, especially not on a SoC which can be brought up with TF-A BL2. > > my reading of this is that it only works if you securely boot a linux kernel. > If we had a securely boot (the u-boot checks the signature) linux kernel, > then nobody could change their kernel. > > -- > Michael Richardson. o O ( IPv6 IøT consulting ) >Sandelman Software Works Inc, Ottawa and Worldwide > > > > > ___ > openwrt-devel mailing list > [email protected] > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One / project update
On Fri, Apr 12, 2024 at 01:38:01PM -0400, Michael Richardson wrote: > > John Crispin wrote: > > On 12.04.24 15:30, Michael Richardson wrote: > >> Is the MT7981B specification available publically at this point? > >> > >> I can find a 7986 sheet on hackaday, but who knows how it differs > (marketing > >> people and their numbers) > >> > > Hi > > > http://mirror2.openwrt.org/docs/ > > Thank you, I'm reading through now. > > I didn't grok all the GPIO pin sharing, there are a lot of choices there > which I think you've already made when you listed the high-level specs. > > Will we be able to support the: > "the hardware-based NAT engine with QoS embedded in MT7981B" > Any IPv6 support down there? Yes, for various tunnel protocols even. > Is it the "NEON"? > > I see 64 Tx queues for wired ethernet, but I imagine Dave Taht will want to > know if there are per-host queues for the wireless. Hmm. Well, it looks like > there are at least 4, but I could have mis-understood. > > In the first PDF, there is mention of: >Security Support 2 * 256-bit multi-key on OTP eFuse >Support 64 version OTP eFuse for anti-rollback Those features require proprietary tools provided by MediaTek only to clients under NDA. Unless some 3rd-party reverse-engineers those tools, we won't ever use those features. Also note that those 256-bit keys are *symmetric* keys probably, so not that useful for IDevID. > > which is often the key to getting IDevID deployed, but I didn't find further > mention of that in the three datasheets. Another option for deploying IDevID is using MMU to prevent access to the SPI-NOR I/O range from non-secure land and handling cryptographic operations entirely in the secure enclave, e.g. using OP-TEE and fTPM. This is possible without burning any fuses and without any proprietary tools (but will probably not be implemented in time for the firmware which will ship with the device -- however, it can be done after, I can help and point who ever wants to do it to the right directions.) > > I found: 11008014 GLOBAL_SEC_EN, but I think it has to do with locking down > the timers, or some I2C thing. > > (I turned on hypothes.is while reading the PDFs, if someone wants to see my > notes) > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works|IoT architect [ > ] [email protected] http://www.sandelman.ca/| ruby on rails > [ > > > ___ > openwrt-devel mailing list > [email protected] > https://lists.openwrt.org/mailman/listinfo/openwrt-devel signature.asc Description: PGP signature ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One / project update
Hi Ivan, On Thu, Apr 11, 2024 at 10:15:58AM +, Ivan Ivanov wrote: > > there are no Wifi-5+ chips on the market that can run without blobs > > This is true, but at the same time - undoubtedly - some chips are more > likely to be liberated from blobs than the others. Some WiFi chip may > have been partially researched (i.e. someone tried to reverse-engineer > its binary blob) or at least a detailed-enough public PDF datasheet is > available so that its clear how the hardware operates, while some > other WiFi chip may lack these advantages and even use a firmware > signature that prevents the binary blob replacement by the opensource > alternative. > > What I am afraid of, and what forces me to write e-mails like this > once-in-a-while - is a POSSIBILITY that OpenWrt One project has not > taken this "liberation-potential" into consideration while choosing a > chip for a new router - and as result, it may turn out after that > OpenWrt One project becomes popular and the people would like it to > become blobless (i.e. by some crowdfunding initiative), but then find > out it impossible to liberate because of some technical limitation > like that firmware signature. We are well aware of that and of course would appreciate any efforts towards a blob-less system. The advantage of the chosen MT7981+MT7976 chip combination is that it is generally well-understood and people of our community have been working with the vendor (MediaTek) to write a high-quality WiFi driver for it. It this moment, this is definitely as good as it gets, the situation for all other modern WiFi chips is a lot worse. For this SoC we are going to have open source datasheets which cover most parts. We already got an Open Source implementation of the ARM TrustedFirmware-A as well as U-Boot (see DDR4-exception below, however). > > > Could you please list the wifi chips you know of which ether have > > a) completely open source firmware, or > > b) no firmware at all (neither loaded in ram, nor in internal flash)? > > The best WiFi hardware capable of working on 100% opensource, I am > aware of and using at the moment, is based on the chips of Atheros > ath9k / ath9k_htc families: > 1) Netgear WNDR3800 router, SoC : Atheros AR7161 rev 2, yes it is > 802.11n but it supports 5 GHz, and my ISP is slower than 300 Mbps in > any case > (bought it locally but you may visit this page for a more complete > description - shop [dot] vikings [dot] > net/product/wndr3800-wlan-router/ ) > This router runs on LibreCMC (fork of OpenWRT to designate the routers > which could work on 100% opensource) and its U-Boot is blobless too > AFAIK And here comes the next serious limitation: You won't find *any* device using DDR3 or more recent and faster DRAM chips which do not need to run proprietary code to carry out the initial calibration of the DRAM controller. The DRAM consortium enforce this with their patents and licensing strategies down to the SoC companies. Literally *all* of them ever since DDR3 require such blobs which have increased size with every generation of DRAM. In case of MediaTek those blobs are neither obfuscated nor not signed, they are merely compiled objects with a symbol table (which is probably the most relaxed interpretation of those DRAM consortium rules, but who knows, even the rules themselves are not public). > 2) AR9462 MiniPCIe WiFi module, also 802.11n with 5 GHz support, for > G505S laptop with a coreboot opensource BIOS > (btw this G505S is the most powerful coreboot-supported laptop without > Intel ME/AMD PSP backdoors, has a quadcore AMD and up to 16/32GB RAM) AR9462 can't be bought new any more at this point in time. I remember that TP-LINK had licenced some older QCA silicon and was still building batches of it for a while, but even this is now more than 5 years ago and I believe they have stopped doing that. > 3) There are also ath9k-based USB adapters which work on 100% > opensource, but those with 5 GHz support are rare (haven't been able > to find in the wild) Also those you can't order or buy new anywhere at this point. > > However, of course it does not mean that there is nothing newer than > this "ath9k" that could theoretically work on 100% opensource without > any blobs in userspace. Sorry, but none of those blobs run in userspace. Userspace is 100% built from Free Open Source Software for practically all OpenWrt-supported devices. What we do have are blobs which are part of linux-firmware and published under a license which allows their free distribution, and those blobs are uploaded to the WiFi chip itself, and they typically contain bytecode which is run on the various built-in processors of those WiFi chips. As you correctly stated, there isn't any post-WiFi-4 chip which does not require such firmware blobs. > A couple of years ago I've seen someone trying to reverse-engineer a > newer chip's blob (think it was 802.11ac ), but a Google does not want > me to find this page atm :P They key factors
Re: [PATCH 0/9] odhcpd patchset
On Fri, Apr 05, 2024 at 02:53:03AM +0200, Paul Donald wrote:
> From: Paul Donald
>
> refactor and fix limit prefix preferred_lt to valid_lt in accordance with
> RFC4861
All changes look good and I generally agree. Thank you!
Please avoid duplicate commit titles ("various: refactor") as well as
empty commit messages as that makes the project git history harder to
read and understand.
Also, in case of automated refactoring it would be great if you can
include the method (e.g. sed script) used for carrying them out in the
commit message. I know they are trivial and the those scripts can
easily be inferred by reviewers, however, having a sed-script and
apply that locally, then compare it with your suggested patch is
easier than reviewing the patch itself (esp. when it comes to
accidental ommissions).
>
> Tested on 23.05.0
I assume the patchset is intended to be applied on the current git
HEAD of odhcpd.git, right? Also that is something worth mentioning in
the cover letter.
For the whole series:
Reviewed-by: Daniel Golle
>
> Paul Donald (9):
> various: refactor
> various: refactor
> various: Comment fixes
> router: inherit user-assigned preferred_lifetime
> router: Limit prefix preferred_lt to valid_lt in accordance with
> RFC4861
> router: Apply updated values from RFC8319 (updates RFC4861)
> config: ra_management is deprecated comment
> router: Type comments
> ndp: Comments
>
> src/config.c| 1 +
> src/dhcpv4.c| 2 +-
> src/dhcpv6-ia.c | 140
> src/dhcpv6.c| 6 +--
> src/dhcpv6.h| 8 +--
> src/ndp.c | 4 +-
> src/netlink.c | 56 +--
> src/odhcpd.c| 8 +--
> src/odhcpd.h| 4 +-
> src/router.c| 72 ++---
> src/router.h| 21 +++-
> 11 files changed, 176 insertions(+), 146 deletions(-)
>
> --
> 2.44.0
>
>
> ___
> openwrt-devel mailing list
> [email protected]
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Conclusions from CVE-2024-3094 (libxz disaster)
On Mon, Apr 01, 2024 at 02:49:46PM +0200, Petr Štetiar wrote: > Daniel Golle [2024-03-30 15:30:49]: > > Hi, > > > In many ways, we are already better > > I would probably avoid such bold statements and would be more humble, since > you never know why OpenWrt wasn't directly targeted. We are not "better" but "better off". You cut my sentence in a quite significant place here. Mind that little word "off" here which makes all the difference. I assume you misread my statement, no offence, of course. It did not at all intend to be a bold statement regarding OpenWrt's security practises what-so-ever. Again: "In many ways, we are already better off than most Linux distros out there -- not because of deliberate decisions with security in mind, but because of our tendency to minimalism and avoiding bloat due to resource limitations on the target devices, and having a reduced attack surface is just an indirect consequence of that." Maybe I should have added ", at best." at the end of the sentence. > > > I believe that the current tendency to use tarballs rather than > > (reproducible!) git checkouts is also problematic to begin with. > > Git checkouts are currently problematic as well, IIRC the build is going to > happily use whatever Git is happy with. I mean, if the hash of the downloaded > tarball source code doesn't match, then the tarball is removed and Git clone > is performed, new source code tarball is produced, but the tarball hash is not > going to be checked again. > > Perhaps this package source code integrity checks should be mandatory, not > optional? I agree, especially also as PKG_SOURCE_VERSION isn't necessarily a hash, but can also be a reference to a git tag -- and that can be replaced by a malicious maintainer or git hoster (though it would be kinda stupid, as everyone with a downstream copy of the repo would most likely notice that). Never the less: A git tag does not really replace an integrity check, especially as we also don't very signed git tags at all. > > > So why not **always** use that instead of potentially shady and hard to > > verify tarballs? > > In this case, they were targeting specific audience and this attack vector was > cheapest/fastest, so the source code origin doesn't really matter. I tend to slightly disagree, because an attacker will always chose what ever means are necessary or sufficient. Using tarballs instead of checkouts increases the attack surface in the sense that validating the tarball content is extra work for package maintainers. > > > Why do we need to rely one proprietary hacks such as Gibhub codeload > > just to safe a few megabytes of traffic and a few seconds of build > > time? > > Ok, I don't like GH either, but I find this irrelevant, origin of the source > code is not a problem, the content is the problem. ... and that crazy m4 script had to be noticed. As a diff one would ask: Why was that change necessary? Maybe we can learn a bit from Android's build system here: They unpack the release tarballs into a git repo, so that makes the diff more visible and obvious again for maintainers. That would get the best of both worlds (at a significant resource pricetag, though...) > > > There are even too many problems to reproduce even those supposedly > > automated Github-generated tarballs. Nobody actually checks that. > > FYI we do on the CI > https://github.com/openwrt/actions-shared-workflows/blob/main/.github/workflows/reusable_build.yml#L224 Nice one. Wasn't aware of that. > > > 9bd7d8b, c7c2257, 77368ec, 86994e1, 954142f, 4c5d910, 21f713d, ... > > Probably all of those have trivial causes and there isn't anything > > malicious going on there. > > I agree, I guess, that in some cases it might point to a subtle bug somewhere > in the source code tarball packaging path (host kernel, tools, container?), > maybe another backdoor in the works/testing? :P 0_o > > Anyway, we should perhaps consider treating this situations in supply chain > more seriously, so perhaps in this cases of package hash failures, we need to > document it better, with more details in the commit message and maybe even > better, gather always more evidence in a separate GH issue, so its possible to > reconstruct the complete picture if we really find out 2 years later, that it > was something malicious going on somewhere? Whatever it might be. +1 > > > Always using git checkouts instead of tarballs would also makes it > > much easier for maintainers to at least have a quick look at the > > changes made in an upstream project between versions (a quick scroll > > over 'git diff oldtag..newtag' or even just 'git log
Re: OpenWrt HaLow Driver Job for Hire
Hi Sam, On Sun, Mar 31, 2024 at 03:32:59PM -0700, Sam Petrov wrote: > I have a project for work I'm shopping around: I have access to an > existing SDK from Morse Micro > (https://drive.google.com/drive/folders/18vAzb6E4E33axyx20E9QvXI0NfQVF6S8?usp=sharing). > I'm trying to get AHM26108D > (https://www.alfa.com.tw/products/ahm26108d?variant=39922067898440) to > work with OpenWrt on a NanoPi R5C > (https://www.friendlyelec.com/index.php?route=product/product&product_id=290). > I'm not sure if it requires compiling a full custom OpenWrt image from > scratch or just creating a package that can be installed atop vanilla > OpenWrt. Open to hire immediately for this single project. I had a quick look at the specs of that AHM26108D as well as the schematics of the NanoPi R5C [1] and I'm afraid I've got bad new for you: Despite being a Key-E M.2 slot this card is not compatible with the R5C. The reason is that the R5C only offers PCIe signals on the M.2 slot while the AHM26108D uses SDIO (which is not very common and you will have a hard time finding *any* SBC which offers SDIO signals on an Key-E M.2 slot). The best option would probably be to build a custom adapter in the shape of a microSD card which plugs into the R5C and allows you to use that SDIO bus for the AHM26108D while booting the R5C from eMMC. [1]: https://wiki.friendlyelec.com/wiki/images/4/45/NanoPi_R5C_2209_SCH.PDF page 18 "M.2 Key E 2230" ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Conclusions from CVE-2024-3094 (libxz disaster)
On Sun, Mar 31, 2024 at 12:05:03PM +0200, Thibaut wrote: > > > Le 31 mars 2024 à 01:07, Elliott Mitchell a écrit : > > > >> Normally upstream publishes release tarballs that are different than the > >> automatically generated ones in GitHub. In these modified tarballs, a > >> malicious version of build-to-host.m4 is included to execute a script > >> during the build process. > > > > So the malicious source code was part of all tarballs, but only the > > tarballs with the modified `build-to-host.m4` would trigger the malicious > > payload. > > > > So obtaining GitHub's tarballs which came directly from the Git > > repository *does* avoid the breach. > > https://git.tukaani.org/?p=xz.git;a=commitdiff;h=f9cf4c05edd14dedfe63833f8ccbe41b55823b00 > > Let’s not lure ourselves into thinking that not using upstream-provided > tarballs but upstream-provided repo instead is inherently safer. With > adversarial upstream, *nothing* is safe anyway. Just using git checkouts (or **repoducible** tarballs generated from a repo's git-ref, ie. tag or commit) by itself of course doesn't help much. But for myself, maintaining a medium 2-digit number of packages, using git checkouts (or **reproducible** tarballs generated from git checkouts) would mean that I can at least be sure that the git commits I've been seeing and the diff between version tags **would really correspond to the content of tarball**, without having to put extra work just into that (which imho nobody does). I've never claimed that this alone is the solution, but if we are already used to a) the content of a release tarball not matching the git repo (because of `make dist` autotools nonsense, for example), b) the hash of such tarball being different depending on who generates it with subtle difference such as the folder name, c) people all the time "fix" PKG_MIRROR_HASH without anyone having any option to validate the cause for the "wrong" hash in first place. Then the added security of PKG_HASH and esp. PKG_MIRROR_HASH is very small. Too small, if you ask me. And other than the complex social/economical/political problems which lead to something like the xz backdoor (out of question: those are the bigger problems), that's a technical problem we could quite easily improve **and it would have been sufficient to prevent the attack** in this case. There is a reason the attacker(s) went through great lengths to move the official mirror site of the project, change the PGP key and hide the key piece of the exploit in the tarballs they generated (and signed) instead of in a git commit. This is not by chance. What we need is "Reproducible Source/Release Tarballs", not as a solution to all our problems, but as a **pre-condition** which currently isn't met for obvious reasons. Hence I'm still arguing that the lesser resource use of downloading Github archive/codeload/release tarballs is not worth the loss of integrity and audit-trail of git. Yes, I know SHA-1 is outdated, but in the context of git it's not so easy to add lots of random padding which would be required to generate a hash collission, which has yet to be seen even for contexts with much more freedom than the narrow syntax of a git diff (and commit message). So sure, it's not perfect, but it's better than nothing. And while release tarballs (being *delibertely* different from the content of the source repo at their corresponding tag for things like an added VERSION or ChangeLog file or stuff like that which is information the build process could otherwise learn from .git) have some small arguable value, hard or impossible to reproduce Github-generated tarballs really do NOT have any value. They are an obstacle, and lure people into bad practices such as all those "Fix PKG_MIRROR_HASH" commits which become the norm (and should really not). And regarding the first case (deliberately added VERSION or ChangeLog information and such) we should aim for a **standardized** way to do add them in a **reproducible** way. But that's a longer story, and certainly boring and trivial, but worth debating never the less. On the other hand, what does "maintained" actually mean in the context of an OpenWrt package? I can be anything from 0. I'm not even using this, don't understand the language it is written in. Just somehow ended up maintaining it. 1. I occassionally bump the version to the newest release or merge PRs of other people suggesting that. 2. I actually validate GPG signatures while bumping the release. 3. I follow up on git history of that project between releases. 4. I have at least rough understanding of the code and purpose of each file of that project. 5. I've contributed to that project myself in the past. 6. I at least quickly read git diff of that project between releases. 7. I study each commit at the time it is made. [...] up to X. I'm the author, I've written that code, I know the reason for every line of code to be there. Obviously also (X) is also kinda pr
Conclusions from CVE-2024-3094 (libxz disaster)
Hi everyone! you may all have heard and read about CVE-2024-3094. If not, please do so now [1], [2]. This incident has exposed many long standing issues and should not be seen as a singular event, but rather as the result of several unhealthy patterns. And while OpenWrt was not affected by the resulting vulnerability (because we don't ship OpenSSH by default; and our build of OpenSSH isn't downstream patched for integration with systemd...), this and the fact that the added backdoor was discovered rather fast are both just lucky coincidents. All of that comes in a moment that the NVD [3] has practically stopped working with the public [4], at least temporarily, and that has severely increased the pressure on open source projects to handle such incidents responsibly **by themselves**. (how?) Of course there are many conclusions to draw and discussions to be had when it comes to the libxz bootdoor incidence, many on the purely technical level (why did Debian and RedHat downstream-patch OpenSSH? Why did a dependency-monster like systemd become the de-facto standard on Linux installations? ...), and all of them need to be re-evaluated in the light of this attack imho. In many ways, we are already better off than most Linux distros out there -- not because of deliberate decisions with security in mind, but because of our tendency to minimalism and avoiding bloat due to resource limitations on the target devices, and having a reduced attack surface is just an indirect consequence of that. However, after reading up about the details of this backdoored release tarball, I believe that the current tendency to use tarballs rather than (reproducible!) git checkouts is also problematic to begin with. Stuff like 'make dist' seems like a weird relic nowadays, creates more problems than it could potentially solve, bandwidth is ubiquitous, and we already got our own tarball mirror of git checkouts done by the buildbots (see PKG_MIRROR_HASH). So why not **always** use that instead of potentially shady and hard to verify tarballs? Why do we need to rely one proprietary hacks such as Gibhub codeload just to safe a few megabytes of traffic and a few seconds of build time? There are even too many problems to reproduce even those supposedly automated Github-generated tarballs. Nobody actually checks that. 9bd7d8b, c7c2257, 77368ec, 86994e1, 954142f, 4c5d910, 21f713d, ... Probably all of those have trivial causes and there isn't anything malicious going on there. But it shows the general problem: That while we are quite good with (much more complicated) reproducible builds, nobody seems to care about (actually trivial) reproducible **sources**. It's too trivial and boring to care, I suppose. And then there is the not exactly glorious role of Github in that whole mess, blocking the affected repo (making analysis harder or impossible), blocking the account of the semi-retired old maintainer who is not to blame, ... Hence I believe we should use git checkouts and reference to (ideally signed) git tags when ever we can. Package maintainers should always have a local checkout of the repository of the software they are packaging for OpenWrt, and use 'git fetch origin' or 'git pull' to keep it up-to-date, as to make sure that the repo history remains unchanged. Git has a lot of security built-in, and by using tarballs as a base for our package builds we are basically throwing all that away, for the sake of saving a negligible amount of resources on the build infrastructure. Always using git checkouts instead of tarballs would also makes it much easier for maintainers to at least have a quick look at the changes made in an upstream project between versions (a quick scroll over 'git diff oldtag..newtag' or even just 'git log --stat oldtag..newtag' doesn't take much more time than manually validating a release tarball GPG signature in most cases, if there even is any...). Hiding a malicious change in a commit is infinitely harder than hiding it in a tarball. Those are just my 2 cents, I think this cries for a wider debate and I encourage everyone to participate in it. Of course, the real problem (which is much deeper) is the lack of maintainer resources for critical infrastructure. This message [5] says it all. Cheers Daniel [1]: https://www.openwall.com/lists/oss-security/2024/03/29/4 [2]: https://boehs.org/node/everything-i-know-about-the-xz-backdoor [3]: https://nvd.nist.gov/ [4]: https://www.helpnetsecurity.com/2024/03/19/nvd-vulnerability-management/ [5]: https://www.mail-archive.com/[email protected]/msg00567.html ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Purpose of openwrt-devel?
On Wed, Mar 13, 2024 at 05:50:36PM -0700, Elliott Mitchell wrote: > On Wed, Mar 13, 2024 at 09:43:06AM +0100, Olliver Schinagl wrote: > > On 13-03-2024 08:46, Felix Baumann wrote: > > > Am 13. März 2024 05:11:23 MEZ schrieb Elliott > > > Mitchell: > > >> I must challenge this. If patches via the mailing list were accepted, > > >> then we should see things sent to the mailing list getting into the > > >> repository. Yet many patches get no attention. Some get reviews from > > >> various people, yet then never get into the main repository. > > > It's the same for Github, some stuff doesn't get in and remains there. > > > There might be a difference what kind of PRs are send to the mailing list > > > and you get attention of different committers when sending to mailing > > > list vs sending to Github. Github patches might be accepted more easily > > > when it's just a new device for a well established target. > > > > > > I feel like patches on the mailing list are ignored, when committers > > > don't have time for review or don't feel confident enough to do it well > > > (not their field of expertise). Or if it's written in a language they > > > don't feel confident reviewing. > > > > *PERSONALLY* I think mailing list reviews are on their way out. People > > have found that there are easier and better ways. Granted, some folks > > still _prefer_ mailing list reviews. *I PERSONALLY* do not at all. I > > hate my mailbox being full with threads of stuff I have no attention for > > at that moment, it just adds noise for me. And ignoring it for a while > > just puts huge amounts of e-mails in my mailbox, that become useless > > after a while. Though I much rather would like to see GitLab then GitHub > > use :p but that's more the FOSS spirit, and avoiding anything Microsoft > > where possible :p > > Mailing list reviews do have their moments. Notably I thought some > parts might deserve wider discussion. Also by sending it here I was > trying to engage with the person who originally found the solution. > > I am another person who is concerned about GitHub. The degree of > copyright infringement by AI isn't known to be large, but there are hints > of trouble on the horizon. Good news is Git is very much P2P and moving > things between Git servers is easy. Rest assured that our mailing list archive is certainly also part of training data sets, just like non-Github-hosted git repositories are, no matter what the license says. I've recently asked Autopilot a bunch of questions regarding an open source project which is not hosted on Github and got very elaborate (and more or less correct) answers including pointers to correctly named filenames and structs therein -- of course I didn't ask to quote the repo or whether the specific repo is itself part of the training data set, they are sneaky enough to make sure it won't fall that easily. Anyway. The true dependency on Github is everything they offer besides git: Bug tracker, Pull Requests, comments made on PRs, comments made on commits, ... scraping all that data is much more tricky should we ever desire to move that somewhere else. Imho for people who don't like following submitted patches as emails in their inbox there is patchwork. Having everything in two places -- Github and patchwork -- certainly isn't perfect and I'd also rather want to see all that in a single one-size-fits-them-all interface like sourcehut. However, I also got neither resources nor experience in hosting such as service in the scale we would need. Just my 2 cents. > > > > > Huh. Parts of that look suspicious. Those commit messages look *very* > > > similar to my version 2. I was jumping between documentation sources > > > when writing it. > > > Not sure what is surprising to you, since the mail thread was listed in > > the MR and your perl code was even referenced (not _directly_ I admit). > > Obviously I was using your messaging format as that was discussed on the > > mailing list and I didn't want to deviate from those messages, also they > > made a lot of sense anyway. "Fair Use" if anything :p > > A Court of Law would need to decide Fair Use, but I'm pretty sure this > would fail. Good news is this isn't enough to bother. > > > The actual code of course has nothing to do with the perl script, as you > > right full say 'I know nothing of perl', as does probably most of the > > development community by now. Which is sad for perl, but 'it is what it is'. > > > > In no way was there any ill intent. I just wanted my kernel tree bump > > for the realtek target, and didn't want to install, learn etc perl to > > try things out. Sorry for that on my part. > > The real problem here is you made two critical errors in your handling > of this. > > First, credit the original author for everything. Open source depends > heavily on reputation so letting people know doing this as a script was > my idea has high value to me. I take the above as an apology
Re: procd, possible hotplug issue?
On Wed, Feb 21, 2024 at 10:01:30PM +0100, e9hack wrote: > Am 21.02.2024 um 01:21 schrieb Daniel Golle: > > > > Yep, I didn't think about empty variables when I built this... > > > > Can you test this please: > > https://github.com/openwrt/procd/pull/3 > > > > This does fix the issue. > > If I test a modified executable, I replaced it by a link to a link on a > automatically mounted usb stick. The link on the usb stick points to the > modified executable. e.g.: > > /sbin/dnsmasq is renamed to /sbin/dnsmasq.old > /sbin/dnsmasq -> /mnt/test/dnsmasq/dnsmasq > /mnt/test/dnsmasq/dnsmasq -> /mnt/test/dnsmasq/dnsmasq-test-something > > If the modification bricks the router, I replace the last link on the usb > stick by > > /mnt/test/dnsmasq/dnsmasq -> /sbin/dnsmasq.old > > or > > /mnt/test/dnsmasq/dnsmasq -> /rom/sbin/dnsmasq > > and the router is operational again. > > This doesn't work for procd since procd is needed before the usb stick is > mounted. > > How can I do similar things for procd? There isn't any as convenient option, for the reason you named. When hacking on procd the qemu targets (malta, armvirt, x86) are very handy for testing and debugging. Once things work well there I move on to a "friendly" board (ie. with dualboot/recovery feature, serial console, pstore which is also good for PID 1 crashes, ...). > > Regards, > Hartmut > > > ___ > openwrt-devel mailing list > [email protected] > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: procd, possible hotplug issue?
On Tue, Feb 20, 2024 at 11:47:49PM +0100, e9hack wrote:
> Am 20.02.2024 um 14:14 schrieb Paul D:
> >
> > Could you show an example of this?
> >
>
> I modified /usr/lib/dnsmasq/dhcp-script.sh to see additional variables in the
> syslog:
>
> --- dhcp-script.sh.orig 2024-02-14 16:22:53.0 +0100
> +++ dhcp-script.sh 2024-02-20 22:55:33.0 +0100
> @@ -50,4 +50,7 @@ esac
>
> json_close_array env
>
> -[ -n "$hotplugobj" ] && ubus call hotplug.${hotplugobj} call "$(json_dump)"
> +[ -n "$hotplugobj" ] && {
> + logger -t dhcp-script "ubus call hotplug.${hotplugobj} call
> \"$(json_dump)\""
> + ubus call hotplug.${hotplugobj} call "$(json_dump)"
> +}
>
>
> 'logread -e 192.168.104.82' with HOSTNAME empty shows:
> Tue Feb 20 23:14:33 2024 user.notice dhcp-script: ubus call hotplug.dhcp call
> "{ "env": [ "MACADDR=aa:aa:aa:aa:aa:aa", "IPADDR=192.168.104.82",
> "ACTION=update", "HOSTNAME=" ] }"
> Tue Feb 20 23:14:33 2024 user.notice dhcp-script: ubus call hotplug.dhcp call
> "{ "env": [ "MACADDR=aa:aa:aa:aa:aa:aa", "IPADDR=192.168.104.82",
> "ACTION=update", "HOSTNAME=" ] }"
> Tue Feb 20 23:14:34 2024 user.notice nft-qos-monitor: ACTION=update,
> MACADDR=aa:aa:aa:aa:aa:aa, IPADDR=192.168.104.82, HOSTNAME=WLAN-DSL9
> Tue Feb 20 23:14:34 2024 user.notice dhcp-script: ubus call hotplug.neigh
> call "{ "env": [ "MACADDR=aa:aa:aa:aa:aa:aa", "IPADDR=192.168.104.82",
> "ACTION=add" ] }"
> Tue Feb 20 23:14:34 2024 user.notice nft-qos-dynamic: ACTION=update,
> MACADDR=aa:aa:aa:aa:aa:aa, IPADDR=192.168.104.82, HOSTNAME=WLAN-DSL9
> Tue Feb 20 23:14:35 2024 user.notice dhcp-script: ubus call hotplug.neigh
> call "{ "env": [ "MACADDR=aa:aa:aa:aa:aa:aa", "IPADDR=192.168.104.82",
> "ACTION=add" ] }"
> Tue Feb 20 23:14:35 2024 user.notice nft-qos-monitor: ACTION=update,
> MACADDR=aa:aa:aa:aa:aa:aa, IPADDR=192.168.104.82, HOSTNAME=WLAN-DSL9
> Tue Feb 20 23:14:36 2024 user.notice nft-qos-dynamic: ACTION=update,
> MACADDR=aa:aa:aa:aa:aa:aa, IPADDR=192.168.104.82, HOSTNAME=WLAN-DSL9
>
> 'logread -e 192.168.104.84' with HOSTNAME set shows:
> Tue Feb 20 23:14:34 2024 user.notice dhcp-script: ubus call hotplug.dhcp call
> "{ "env": [ "MACADDR=bb:bb:bb:bb:bb:bb", "IPADDR=192.168.104.84",
> "ACTION=update", "HOSTNAME=raspberrypi2" ] }"
> Tue Feb 20 23:14:34 2024 user.notice dhcp-script: ubus call hotplug.neigh
> call "{ "env": [ "MACADDR=bb:bb:bb:bb:bb:bb", "IPADDR=192.168.104.84",
> "ACTION=add" ] }"
> Tue Feb 20 23:14:35 2024 user.notice dhcp-script: ubus call hotplug.neigh
> call "{ "env": [ "MACADDR=bb:bb:bb:bb:bb:bb", "IPADDR=192.168.104.84",
> "ACTION=add" ] }"
> Tue Feb 20 23:14:36 2024 user.notice nft-qos-monitor: ACTION=update,
> MACADDR=bb:bb:bb:bb:bb:bb, IPADDR=192.168.104.84, HOSTNAME=raspberrypi2
> Tue Feb 20 23:14:36 2024 user.notice nft-qos-dynamic: ACTION=update,
> MACADDR=bb:bb:bb:bb:bb:bb, IPADDR=192.168.104.84, HOSTNAME=raspberrypi2
>
> WLAN-DSL9 is the router name:
> root@WLAN-DSL9:~# echo $HOSTNAME
> WLAN-DSL9
>
> If I replace HOSTNAME by DHCP_HOSTNAME in /usr/lib/dnsmasq/dhcp-script.sh,
> /etc/hotplug.d/dhcp/00-nft-qos-monitor and
> /etc/hotplug.d/dhcp/01-nft-qos-dynamic, I get the following output:
>
> Tue Feb 20 23:44:43 2024 user.notice dhcp-script: ubus call hotplug.dhcp call
> "{ "env": [ "MACADDR=aa:aa:aa:aa:aa:aa", "IPADDR=192.168.104.82",
> "ACTION=update", "DHCP_HOSTNAME=" ] }"
> Tue Feb 20 23:44:43 2024 user.notice dhcp-script: ubus call hotplug.dhcp call
> "{ "env": [ "MACADDR=aa:aa:aa:aa:aa:aa", "IPADDR=192.168.104.82",
> "ACTION=update", "DHCP_HOSTNAME=" ] }"
> Tue Feb 20 23:44:44 2024 user.notice nft-qos-monitor: ACTION=update,
> MACADDR=aa:aa:aa:aa:aa:aa, IPADDR=192.168.104.82, DHCP_HOSTNAME=
> Tue Feb 20 23:44:44 2024 user.notice dhcp-script: ubus call hotplug.neigh
> call "{ "env": [ "MACADDR=aa:aa:aa:aa:aa:aa", "IPADDR=192.168.104.82",
> "ACTION=add" ] }"
> Tue Feb 20 23:44:44 2024 user.notice nft-qos-dynamic: ACTION=update,
> MACADDR=aa:aa:aa:aa:aa:aa, IPADDR=192.168.104.82, DHCP_HOSTNAME=
> Tue Feb 20 23:44:45 2024 user.notice dhcp-script: ubus call hotplug.neigh
> call "{ "env": [ "MACADDR=aa:aa:aa:aa:aa:aa", "IPADDR=192.168.104.82",
> "ACTION=add" ] }"
> Tue Feb 20 23:44:45 2024 user.notice nft-qos-monitor: ACTION=update,
> MACADDR=aa:aa:aa:aa:aa:aa, IPADDR=192.168.104.82, DHCP_HOSTNAME=
> Tue Feb 20 23:44:46 2024 user.notice nft-qos-dynamic: ACTION=update,
> MACADDR=aa:aa:aa:aa:aa:aa, IPADDR=192.168.104.82, DHCP_HOSTNAME=
>
> If procd generates the hotplug call, it filters out empty variables. From
> procd hotplug-dispatch.c line 239:
>
> *tmp = '\0';
> if (validate_envvarname(enve))
> continue;
> *tmp = '=';
>
> if (!strlen(++tmp))
> continue;
Yep, I didn't think about empty variables when I built this...
Can you test this please:
https://github.com/openwrt/procd/pull/3
>
> Regards,
> Hartmut
>
>
>
>
>
Re: ustream-ssl ABI_VERSION usage
On 13 February 2024 17:39:29 UTC, Paul Spooren wrote: >Hi, > >> On Feb 12, 2024, at 14:30, Petr Štetiar wrote: >> >> Jo-Philipp Wich [2024-02-12 14:09:27]: >> >> Hi, >> >>> Ideally all packages specifying an ABI version should ship versioned .so >>> files >>> as well. >> >> I would like to point out, that ustream-ssl is dynamically loaded >> library[1], so we >> would need to pass that ABI information somehow to the clients, so they would >> be able to load correct/compatible version of dynlib, not exactly trivial. >> >> 1. https://lxr.openwrt.org/source/uclient/uclient-fetch.c#L516 > >Thank you both for the clarification. I thought that if opkg just isn’t smart >enough to figure ABI versions I cleanly solve it via apk, however if we really >want to handle parallel installations I’ll teach apk some new tricks. Updates to libubox or other basic libs used by a lot of packages are the prime example. Having the ABIversion appended to the package name like we do for opkg nicely solves the problem, as in that way libubox12 can be installed in parallel with libubox14. Not having that option would make selectively updating a system impossible, and imho thats bad because esp. on remote boxes l may not want to update everything just in order to update, lets say, umdns, which may be built against a newer version of libubox than what I'm running now and hence depends on that. When running on a space constraint box with overlayfs updating everything isn't even an option in practise due to jffs2 being to small to fit everything and things in squashfs rom cannot be replaced. So loosing that (by turning around the provided vs. provider logic as Ariadne was suggesting to not need strippable ABIVersion info added) is really not a good option for OpenWrt I believe. > >Best, >Paul ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH RFC] aquantia-firmware: package MediaTek's Aquantia AQR113C firmware
On Mon, Feb 05, 2024 at 02:23:08PM +0100, Rafał Miłecki wrote: > From: Rafał Miłecki > > Aquantia AQR113C is PHY that needs loading a firmware. Some devices may > have it stored on flash and some need filesystem to provide it. Are you aware of any MediaTek boards which do come with AQR113C but don't bring their own dedicated firmware flash/EEPROM IC connected directly to first PHY? UniFi 6 LR v1/v2 (Aquantia AQR112C) and MT7988RFB (Aquantia AQR113C) both come with a dedidated flash/EEPROM IC for the PHY firmware. However, that firmware (esp. on the UniFi 6 LR) may of course be outdated by now and we may want to load newer firmware from within Linux anyway. > > MediaTek holds its own AQR113C firmware file for its boards. Package it. > > The problem is obtaining that firmware: > 1. Cloning whole repo seems like an overkill for copying a single file > 2. Public git server doesn't support git protocol (and so git archive) > 3. Gitiles UI doesn't allow downloading raw files (nor binaries as text) > > The only option seems to be downloading tar archive of "firmware" > directory. The problem is such archives generated by Gitiles differ on > every download so a checksum can't be specified. > > Due to all above a custom download is implemented in "Build/Prepare". > Then firmware gets simply extracted and packaged. > > Cc: Robert Marko > Cc: Christian Marangi > Cc: Daniel Golle > Signed-off-by: Rafał Miłecki > --- > package/firmware/aquantia-firmware/Makefile | 36 + > 1 file changed, 36 insertions(+) > create mode 100644 package/firmware/aquantia-firmware/Makefile > > diff --git a/package/firmware/aquantia-firmware/Makefile > b/package/firmware/aquantia-firmware/Makefile > new file mode 100644 > index 00..9cf67f41bb > --- /dev/null > +++ b/package/firmware/aquantia-firmware/Makefile > @@ -0,0 +1,36 @@ > +# SPDX-License-Identifier: GPL-2.0-only > + > +include $(TOPDIR)/rules.mk > + > +PKG_NAME:=aquantia-firmware > +PKG_RELEASE:=1 PKG_VERSION ? PKG_LICENSE ? > + > +include $(INCLUDE_DIR)/package.mk > + > +define Package/aquantia-mediatek-aqr113c-firmware > + SECTION:=firmware > + CATEGORY:=Firmware > + TITLE:=MediaTek's firmware for Aquantia AQR113C > +endef > + > +define Build/Prepare > + mkdir -p $(PKG_BUILD_DIR) > + > + # Download for "aquantia-mediatek-aqr113c-firmware" package > + wget \ > + -O > $(DL_DIR)/mtk-openwrt-feeds-refs_heads_master-21.02-files-target-linux-mediatek-mt7988-base-files-lib-firmware.tar.gz > \ > + > "https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+archive/refs/heads/master/21.02/files/target/linux/mediatek/mt7988/base-files/lib/firmware.tar.gz"; > + tar xf > $(DL_DIR)/mtk-openwrt-feeds-refs_heads_master-21.02-files-target-linux-mediatek-mt7988-base-files-lib-firmware.tar.gz > -C $(PKG_BUILD_DIR) > + # TODO: Verify extracted firmware checksum > +endef > + > +define Build/Compile > + > +endef > + > +define Package/aquantia-mediatek-aqr113c-firmware/install > + $(INSTALL_DIR) $(1)/lib/firmware > + $(INSTALL_DATA) > $(PKG_BUILD_DIR)/Rhe-05.06-Candidate9-AQR_Mediatek_23B_P5_ID45824_LCLVER1.cld > $(1)/lib/firmware/ > +endef > + > +$(eval $(call BuildPackage,aquantia-mediatek-aqr113c-firmware)) > -- > 2.35.3 > ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Linux kernel 6.1 or 6.6 for OpenWrt 24.x release?
On Sat, Feb 03, 2024 at 05:42:22PM +0100, Felix Baumann 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. > Date: Sat, 03 Feb 2024 17:42:22 +0100 > From: Felix Baumann > To: [email protected] > Subject: Re: Linux kernel 6.1 or 6.6 for OpenWrt 24.x release? > > Hi, > > from what I imagine the maintainance standpoint to be: > Kernel 6.6 is probably still quick to migrate to. Most targets that already > moved, moved early (due to need and due to great work by the devs). > The targets you listed would take long to switch to the new Kernel regardless > of Kernel 6.6 or 6.1 > > 6.6 probably requires less maintenance for y'all in the long run (like for > the next 3 years atleast due to catching up closer with kernel development) > and has more fixes and features. > The effort for 5.15 stays more or less the same, just a few months longer in > the master branch though some targets with higher velocity will likely drop > it early and switch to 6.6 fully then. > > There could be a blocker: certain features that are required to be > implemented by OpenWrt for certain targets that increase the effort and I > don't know about. > > Sure the branch off will take longer, but 23 is at a good point and there's > still some stuff left to be ironed out/ stabilized. > Maybe this means a release in 2025, but maybe it also comes with support for > new WiFi and more devices then. > > I don't have any say in this but I fully support the choice Kernel 6.6. Drop > 6.1 over the next months and do no release with it. :) I just also thought about this in the past days, and as the amount of backported patched on top of Linux 6.1 is becoming increasingly annoying I would also be in favor of not doing a release based on Linux 6.1 and go straight with Linux 6.6. I'd also volunteer to take care of hardware targets if needed. > > > > What can be done from a community stand-point to accelerate rollout of Kernel > 6.6 for the targets you listed? Mostly testing and reporting issues or it > running fault-free in the corresponding PR? > What makes it harder for these targets? All the subtargets and their > different popularity (like mt7620 and xway/danube)? > Atleast for ramips it felt like the switch to 5.15 in master had taken longer > than it needed to have. > > Regards > Felix Baumann > > Am 3. Februar 2024 13:06:13 MEZ schrieb Hauke Mehrtens : > >Hi, > > > >I track the status of the Linux kernel 6.1 migration in this github issue: > >https://github.com/openwrt/openwrt/issues/14546 > > > >There are still many targets on kernel 5.15 without testing support for > >kernel 6.1 in OpenWrt master. I assume that we need at least 4 months to get > >everything to 6.1 and more or less stable. Kernel 6.1 support is also > >missing for some important targets like lantiq, realtek and ramips. > > > > > >Which kernel should we use for the next major OpenWrt release? > >We have two options and I would like to get some feedback on these: > > > >1. Do the OpenWrt 24.X release with kernel 6.1. Branch off when all or most > >of the targets are on kernel 6.1 by default. > >2. Do the OpenWrt 24.X release with kernel 6.6. Branch off when all or most > >of the targets are on kernel 6.6 by default. Do not do any stable OpenWrt > >release which supports kernel 6.1. > > > >Doing a OpenWrt release with multiple kernels cases too much maintenance > >effort from my point of view based on previews experience. > > > > > >I think with kernel 6.1 we can branch off at around May 2024. With kernel > >6.6 we could probably branch off around September 2024. The final release > >will be out about 2 to 4 months later. > > > >Currently OpenWrt releases are about 1.5 years behind the Linux LTS > >releases. When we use kernel 6.1 for the next release we will continue to > >stay 1.5 years behind. When we switch to kernel 6.6 and do not do any > >release with kernel 6.1 we will probably only stay 10 months behind Linux > >LTS kernels. > > > >There is already a PR requiring kernel 6.6: > >https://github.com/openwrt/openwrt/pull/14357 > > > > > >Currently I would prefer to use kernel 6.6 to get closer to the recent Linux > >LTS releases. > > > >Hauke > > > >___ > >openwrt-devel mailing list > >[email protected] > >https://lists.openwrt.org/mailman/listinfo/openwrt-devel > > ___ > openwrt-devel mailing list > [email protected] > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [VOTE] New member proposal: Robimarko (Robert Marko)
On Tue, Jan 30, 2024 at 07:15:54PM +0100, Christian Marangi (Ansuel) wrote: > Robert is active in OpenWrt since 2017 and with some recent stats, he > has more than 310 commits merged in OpenWrt. > He also have uncounted Reviewed-by tag on various PR and merged commits > and generally helps in everything related to IPQ (ipq806x, ipq40xx and > ipq807x) and some mvebu targets. > > He did the conversion of ipq40xx target to DSA and made possible the > introduction of the ipq807x target by sorting all the QSDK downstream > patch and pushing them upstream. > > With his help, also the ipq60xx is very close on getting merged and > actually used permitting support of even more device for OpenWrt. > > Also he is almost always reachable on IRC openwrt-devel and never had > a problem in coordinating and collaborating with him. > > I think Robert is a good addition to our team and would massively help > me (Ansuel) in maintaining each IPQ target and review all the related > PR on github and patchwork. > I would like to add Robert to the OpenWrt committers team. +1 ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
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 [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Battlemesh x OpenWrt meeting in Cyprus?
Hi Everyone, On Sat, Nov 25, 2023 at 05:14:30PM +0100, Hauke Mehrtens wrote: > Hi Arınç and Paul, > > Thank you Arınç for organizing the Battlemesh in Cyprus. > > I will probably join the Battlemesh again, but I wont have much time to > organize stuff. > > The following dates are currently proposed: > May 15 - 19 > May 22 - 26 > Wednesday - Sunday, 5 days. > > Everyone who wants to join, please take part in the poll: > https://framadate.org/M4I9AYvKYypQTmGB > > It is hard to get people together. I would suggest to plan an OpenWrt track > on the last 2 days of Battlemesh in parallel. > > Who would like to join? I think that a dedicated OpenWrt meeting like in 2019 would be very good, like a mini-summit for OpenWrt devs to present ongoing work and recent achievements, but also just meet and talk in person and possibly even ending up hacking on stuff together. An official invitation to the OpenWrt meeting/mini-summit and endorsement of Battlemesh should happen early via all OpenWrt channels (*-adm mailing list, IRC, Web, Forums). Also, as it's going to be OpenWrt's 20th anniversary in 2024, we should use that opportunity to also reach out to a wider audience, ie. prepare some more layer 8/9 talks about the OpenWrt project or the role of free software in the context of both, protocol research and grassroots networks. I'm ready to be involved in organizational aspects and also take care of reaching out to the wider community once we decided on the date. Cheers Daniel > > Hauke > > On 11/25/23 12:59, Arınç ÜNAL wrote: > > Hello! > > > > I am the head organiser of the next Battlemesh. I will also be involved > > the most on organising the OpenWrt summit. Let me know if you've got any > > questions. My website from my email address includes the channels other > > than email to reach me more easily. > > > > Arınç > > > > On 23 November 2023 23:54:16 EET, Paul Spooren wrote: > > > Hi all, > > > > > > While attending this years Battlemesh in Spain some fellow mesh people > > > asked why there weren’t more OpenWrt people around. I’m guessing it was > > > mostly due to the lack of communication in advance, so I’d like to raise > > > the topic here: Are people from the OpenWrt community, specially members > > > and maintainers interested in collaborating with and attending the > > > Battlemesh next year? > > > > > > They’d do most of the heavy lifting and would offer us to take some > > > slots/space to do our own little OpenWrt meeting (remember the good and > > > productive days in Hamburg anno 2019). Ideally at least one OpenWrt > > > member would join their organizing team, I could do it but would also be > > > happy if someone else jumps in. > > > > > > The general idea is to have a week long Battlemesh event in Cyprus, the > > > OpenWrt part could happen both within the week, before or after, the full > > > length or only a weekend etc. To my knowledge Cyprus offers an easier > > > VISA process so more folks could join, I remember last time people > > > wouldn’t get a VISA in time. > > > > > > If we participate we should raise some donations to offer travel stipends > > > and come up with some (lighting) talks and presentations. > > > > > > I think the timeframe is “somewhen in May 2024”, this will be further > > > discussed on the Battlemesh mailing list. > > > > > > Looking forward to meet you all again! > > > > > > Sunshine, > > > Paul > > ___ > openwrt-devel mailing list > [email protected] > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] mediatek: filogic: add support for GL.iNet GL-MT2500
Hi Enrico,
thank you for advancing with support for this device!
See comments inline, mostly about left-overs from earlier draft
implementations of nvmem-on-MMC.
On Sun, Nov 26, 2023 at 04:11:13PM +0100, Enrico Mioso wrote:
> The GL-MT2500 is a Security Gateway based on MediaTek MT7981. It comes in
> two variants: one with a plastic case, the other with an alluminium one. Both
> variants run the same firmware.
>
> Hardware specifications:
> - SoC: MediaTek MT7981B
> - CPU: 2x 1.3 GHz Cortex-A53
> - Flash: 8GB EMMC
> - RAM: 1 GB
> - Ethernet:
> - 1x 10/100/1000 Mbps built-in PHY (LAN)
> - 1x 10/100/1000/2500 Mbps MaxLinear GPY211 PHY (WAN)
> - USB 3.0 port
> - Buttons: RESET button
> - LEDs: 1x light-blue, 1x warm-white, 1x VPN
> - Serial console: internal 4-pin header, 115200 8n1
> - Power: 5 VDC, 3 A (USB Type-C)
>
> MAC addresses assignment:
> The label on the back of the device reports WAN (eth0) interface MAC address.
> LAN interface (eth1) has WAN MAC address incremented by 1.
>
> Installation:
> -
> Method 1 - via GL.iNet bootloader web failsafe UI
> 1. Connect to the LAN interface of the device (the one that's farther from
> USB-C power supply connector).
> 2. Assign static IP 192.168.1.2/24 to the host.
> 3. Hold the reset button for at least 5 seconds while powering on the device.
> If all went well, the bootloader should be responding to ICMP ping packets
> and listening for web connections at 192.168.1.1. Upload the
> *sysupgrade-squashfs image, then press the Update button. The device should
> restart to OpenWrt.
>
> Method 2 - via UART connection
> 1. Connect to device serial port.
> 2. Interrupt the boot process typing "gl".
> 3. Connect your host to the LAN port of the device and assign it static IP
> 192.168.1.2/24.
> 4. Start a TFTP server in your artifacts folder (e.g.:
> openwrt/bin/targets/mediatek/filogic).
> 5. In the bootloader, issue these commands:
> tftpboot openwrt-mediatek-filogic-glinet_gl-mt2500-initramfs-kernel.bin &&
> bootm
> this should bring you to the OpenWrt prompt where you can transfer a
> sysupgrade image and proceed with the usual sysupgrade process.
>
> Notes
> -
> 1. This port might not work on all hardware samples: in some cases, the unit
> might just hang when probing EMMC.
> 2. The U-Boot environment might not be populated (empty EMMC partition) until
> a "saveenv" command is issued. Do not initialize the environment from within
> OpenWrt as this might cause problems due to the fact fw_printenv's default env
> will not match the vendor's U-Boot one.
>
> Untested features
> -
> Flashing from stock web UI wasn't tested, but is expected to work, being stock
> firmware shipped as a sysupgrade tar image as well.
> Furthermore, going back to stock firmware wasn't tested, but should be
> possible
> via U-Boot failsafe web UI.
>
> CREDITS
> --
> Daniel Golle did the hard part of this port, so thank you!
>
> Signed-off-by: Daniel Golle
> Signed-off-by: Enrico Mioso
> ---
> .../uboot-envtools/files/mediatek_filogic | 1 +
> .../mediatek/dts/mt7981b-glinet-gl-mt2500.dts | 209 ++
> .../filogic/base-files/etc/board.d/02_network | 6 +
> .../base-files/lib/upgrade/platform.sh| 2 +
> target/linux/mediatek/image/filogic.mk| 11 +
> 5 files changed, 229 insertions(+)
> create mode 100644 target/linux/mediatek/dts/mt7981b-glinet-gl-mt2500.dts
>
> diff --git a/package/boot/uboot-envtools/files/mediatek_filogic
> b/package/boot/uboot-envtools/files/mediatek_filogic
> index ae8e1589a0..d678e1fcbd 100644
> --- a/package/boot/uboot-envtools/files/mediatek_filogic
> +++ b/package/boot/uboot-envtools/files/mediatek_filogic
> @@ -77,6 +77,7 @@ xiaomi,redmi-router-ax6000-ubootmod)
> glinet,gl-mt3000)
> ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x8" "0x2"
> ;;
> +glinet,gl-mt2500|\
> glinet,gl-mt6000)
> local envdev=$(find_mmc_part "u-boot-env")
> ubootenv_add_uci_config "$envdev" "0x0" "0x8"
> diff --git a/target/linux/mediatek/dts/mt7981b-glinet-gl-mt2500.dts
> b/target/linux/mediatek/dts/mt7981b-glinet-gl-mt2500.dts
> new file mode 100644
> index 00..58d4200d6c
> --- /dev/null
> +++ b/target/linux/mediatek/dts/mt7981b-glinet-gl-mt2500.dts
> @@ -0,0 +1,209 @@
> +/dts-v1/;
> +#include "mt7981.dtsi"
> +/ {
> + model = "GL.iNet GL-MT2500";
> + compatible = "glinet,gl-mt2500", "mediatek,mt7981";
> +
> + chosen {
Re: [PATCH] mediatek: filogic: add Acelink EW-7886CAX support
Hi Rafal,
looks good in general, please see minor comments in line.
On Mon, Nov 20, 2023 at 12:01:38PM +0100, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> Acelink EW-7886CAX is an MT7986A (AKA Filogic 830) based access point.
> It has 512 MiB of RAM, one 2.5 Gbps PoE (802.3at) Ethernet port and
> on-SoC Wi-Fi.
>
> My unit came with Mediatek's firmware (based on OpenWrt 21.02)
> installed. It was possible to simply upgrade using OpenWrt's sysupgrade
> tool.
>
> Another verified upgrade method is using U-Boot (requires UART). During
> every boot there is "U-Boot Boot Menu". Selecting option "2. Upgrade
> firmware" allows using U-Boot's tftp client to load and flash factory
> image.
>
> Signed-off-by: Rafał Miłecki
> ---
> .../dts/mt7986a-acelink-ew-7886cax.dts| 236 ++
> target/linux/mediatek/image/filogic.mk| 17 ++
> 2 files changed, 253 insertions(+)
> create mode 100644 target/linux/mediatek/dts/mt7986a-acelink-ew-7886cax.dts
>
> diff --git a/target/linux/mediatek/dts/mt7986a-acelink-ew-7886cax.dts
> b/target/linux/mediatek/dts/mt7986a-acelink-ew-7886cax.dts
> new file mode 100644
> index 00..bdbcf1f364
> --- /dev/null
> +++ b/target/linux/mediatek/dts/mt7986a-acelink-ew-7886cax.dts
> @@ -0,0 +1,236 @@
> +// SPDX-License-Identifier: GPL-2.0-only OR MIT
> +
> +/dts-v1/;
> +#include
> +#include
> +#include
> +
> +#include "mt7986a.dtsi"
> +
> +/ {
> + model = "Acelink EW-7886CAX";
> + compatible = "acelink,ew-7886cax", "mediatek,mt7986a";
> +
> + aliases {
> + serial0 = &uart0;
> + led-boot = &led_status_blue;
> + led-running = &led_status_green;
> + led-upgrade = &led_status_red;
> + led-failsafe = &led_status_red;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + memory@4000 {
> + reg = <0 0x4000 0 0x2000>;
> + device_type = "memory";
> + };
> +
> + keys {
> + compatible = "gpio-keys";
> +
> + key-restart {
> + label = "Reset";
> + gpios = <&pio 7 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led_status_red: led-0 {
> + function = LED_FUNCTION_STATUS;
> + color = ;
> + gpios = <&pio 18 GPIO_ACTIVE_HIGH>;
> + };
> +
> + led_status_green: led-1 {
> + function = LED_FUNCTION_STATUS;
> + color = ;
> + gpios = <&pio 19 GPIO_ACTIVE_HIGH>;
> + };
> +
> + led_status_blue: led-2 {
> + function = LED_FUNCTION_STATUS;
> + color = ;
> + gpios = <&pio 20 GPIO_ACTIVE_HIGH>;
> + };
> + };
> +};
> +
> +&watchdog {
> + status = "okay";
> +};
> +
> +&pio {
> + spi_flash_pins: spi-flash-pins-33-to-38 {
> + mux {
> + function = "spi";
> + groups = "spi0", "spi0_wp_hold";
> + };
> + conf-pu {
> + pins = "SPI2_CS", "SPI2_HOLD", "SPI2_WP";
> + drive-strength = <8>;
> + mediatek,pull-up-adv = <0>; /* bias-disable */
> + };
> + conf-pd {
> + pins = "SPI2_CLK", "SPI2_MOSI", "SPI2_MISO";
> + drive-strength = <8>;
> + mediatek,pull-down-adv = <0>; /* bias-disable */
> + };
> + };
> +
> + wf_2g_5g_pins: wf_2g_5g-pins {
> + mux {
> + function = "wifi";
> + groups = "wf_2g", "wf_5g";
> + };
> + conf {
> + pins = "WF0_HB1", "WF0_HB2", "WF0_HB3", "WF0_HB4",
> +"WF0_HB0", "WF0_HB0_B", "WF0_HB5", "WF0_HB6",
> +"WF0_HB7", "WF0_HB8", "WF0_HB9", "WF0_HB10",
> +"WF0_TOP_CLK", "WF0_TOP_DATA", "WF1_HB1",
> +"WF1_HB2", "WF1_HB3", "WF1_HB4", "WF1_HB0",
> +"WF1_HB5", "WF1_HB6", "WF1_HB7", "WF1_HB8",
> +"WF1_TOP_CLK", "WF1_TOP_DATA";
> + drive-strength = <4>;
> + };
> + };
> +
> + wf_dbdc_pins: wf-dbdc-pins {
> + mux {
> + function = "wifi";
> + groups = "wf_dbdc";
> + };
> + conf {
> + pins = "WF0_HB1", "WF0_HB2", "WF0_HB3", "WF0_HB4",
> + "WF0_HB0", "WF0_HB0_B", "WF0_HB5", "WF0_HB6",
> + "WF0_HB7", "WF0_HB8", "WF0_HB9", "WF0_HB10",
> + "WF0_TOP_CLK", "WF0_TOP_DATA", "WF1_HB1",
> +
Re: Adding a new x86 image or related packages to the default x86 image
On Mon, Nov 13, 2023 at 06:26:04PM -0800, Elliott Mitchell wrote: > On Mon, Nov 13, 2023 at 12:48:14PM +0000, Daniel Golle wrote: > > On Mon, Nov 13, 2023 at 01:30:10PM +0100, Paul Spooren wrote: > > > > > > How about we follow the approach of Alpine Linux[1] and offer a standard, > > > an extended and a virtual firmware for the x86/64 target? > > > > > > What packages specifically is another discussion but the approach could > > > be that standard contains all kmods to get network working on all device, > > > extended includes extra LED drivers etc and virtual only contains network > > > drivers for, well, virtual things. > > > > +1 > > I like that much more than adding board-specific images on a platform > > with standardized boot process (such as x86 or armsr). > > Are you stating you're planning to modify OpenWRT's boot process to > match the standard way of dealing with that standardized boot process? > Mainly, using a minimal kernel and then using an initial ramdisk to > load device drivers as appropriate to the hardware. Using squashfs (which is what we are doing) has actually quite a similar effect than using initramfs. Filesystem cache of files which aren't accessed gets freed. What is missing is hotplug-based loading of kmods based on present devices -- right now every module present gets loaded and remains loaded indefinitely even if the hardware isn't present. > > Failing that, I suppose it would be acceptable to have an initial > ramdisk which simply tried to load all modules. Then it would be > possible to remove unneeded modules later. You can already do that and the effect on memory consumption is the same as an initrd (which is literally just uncommitted filesystem cache). The only difference is that the initramfs needs to be decompressed in one piece which takes a lot of time while squashfs can be read and decompressed on-the-fly obviously. And initramfs needs to be explicitely freed (using pivot_root) while in case of squashfs files can always be loaded from flash and stay in the filesystem cache in RAM as long as they are being used and the space isn't needed for anything else. > > > The real issue is VMs are unlikely to see devices typically present on > bare metal computers. Thermal capabilities? Nope. Processor frequency > selection? Nope. Microcode reloading? Nope. Here I agree. We should have a 'slim/vm' image without any 'real' hardware drivers. > > Each hypervisor will have a small set of drivers guaranteed to be > present. These though will be completely different between hypervisors. Do you really think having just the (partially shared) drivers for 3 hypervisors (KVM/virtio, Hyper-V, VMWare) present in one image is too much? Those drivers are very tiny... > > I don't know whether it is possible to omit all types of framebuffer from > a Hyper-V VM. If it isn't possible, then having a framebuffer driver > will be required for Hyper-V, but this consumes somewhere 0.5-1.5MB on > any VM which can omit the framebuffer. Framebuffer support can entirely be built as modules and we can do that instead of having it built-in on x86. Feel free to suggest patches. > > Meanwhile Xen's block device driver isn't even based on SCSI. As a > result it can completely remove the SCSI subsystem, this saves > another 0.5-1.5MB on a Xen VM. Ok, that would really require different kernel builds (as in: subtargets) and not just different images. One for booting from all kinds of physical storage and one for booting from virtualized virtio block or NVMe via IOMMU. > > 10MB might not be much for a 2GB VM. For a 128MB VM, those excess > drivers are a distinct burden. > > > I've got a WIP patch series for making distinct kernel builds rather > less of a burden. The series will need some significant testing. I understand the additional build resources, maintainance and debugging efforts can be justified when having a very high number of identical devices, as it is typically the case only in very large deployments (think: major ISPs and hotspot providers having in-house R&D). However, OpenWrt (the distribution) supports thousands of different devices, and that becomes possible only because all devices within a subtarget share use the exact same kernel build. Not just because of build resources, but also because almost all testing and debugging is covered in the subtarget level and hence we are talking about a somehow manageable workload -- one can nearly reproduce and debug most issues on any of the devices (can be hundreds) on a subtarget using a single or at most 4 different reference devices. OpenWrt (the build-system) could offer such a feature for people wanting to create super-optimizied builds themselves. ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Adding a new x86 image or related packages to the default x86 image
On Mon, Nov 13, 2023 at 07:54:34PM +, Petr Štetiar wrote: > Paul Spooren [2023-11-13 13:30:10]: > > Hi, > > > How about we follow the approach of Alpine Linux[1] and offer a standard, > > an extended and a virtual firmware for the x86/64 target? > > FYI that pull request added 27 firmware ASIC blobs, thus increased x86/64 > image from 10 MiB to 41 MiB, but actually just 1 firmware ASIC blob > mlxsw_spectrum-13.2010.1006.mfa2 (1.6MiB) is needed, so I would instead > recommend to > fix that mlx firmware package and call it a day? Thanks for pointing this out, increasing the default image by 1.6MiB is bearable on x86 and that alone does not justify the introduction of device specific images imho. ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Adding a new x86 image or related packages to the default x86 image
On Mon, Nov 13, 2023 at 01:30:10PM +0100, Paul Spooren wrote:
> Hi all,
>
> How about we follow the approach of Alpine Linux[1] and offer a standard, an
> extended and a virtual firmware for the x86/64 target?
>
> What packages specifically is another discussion but the approach could be
> that standard contains all kmods to get network working on all device,
> extended includes extra LED drivers etc and virtual only contains network
> drivers for, well, virtual things.
+1
I like that much more than adding board-specific images on a platform
with standardized boot process (such as x86 or armsr).
>
> Best,
> Paul
>
> [1]: https://alpinelinux.org/downloads/
>
> > On Nov 13, 2023, at 03:19, Elliott Mitchell wrote:
> >
> >> On Sep 14, 2023, at 5:19 PM, Stefan Lippers-Hollmann wrote:
> >>
> >> On 2023-09-14, Paul Spooren wrote:
> >>>
> >>> I’d like to merge the PR which adds the Mellanox Spectrum SN2100 to
> >>> OpenWrt[1]. In its current state a new x86 image would be added next
> >>> to the generic x86 image. Another approach is to add all related
> >>> packages to the default image. Either way creates a working image.
> >>>
> >>> I remember that people were complaining about a “bloated” x86 image
> >>> which slows down their container/VM needs. So what would be a simple
> >>> way forward here?
> >> [...]
> >>
> >> If at all reasonably possible (assuming the size increase is roughly in
> >> the ball park of 1-2 MB for the total image), I'd suggest to stick to a
> >> single x86_64 image for maintenance and testing reasons alone. The bump
> >> of the x86 targets to kernel v6.1 -while easy- is mostly stalled due to
> >> there being three 32 bit x86 sub-targets and the need to go through the
> >> kernel config rebase three times, which is wearing thin the patience and
> >> motivation of doing so (x86_64 alone would have been ready >2 months
> >> ago). Unless these SN2100 devices suddenly become a cheap commodity and
> >> ubiquitous among OpenWrt developers and -users, I fear that it would
> >> just add to this churn and pretty much rot away in the tree, while at
> >> the same time making progress harder for the other x86{,_64} devices.
> >
> > In that case I would suggest removing the x86/generic target. Since it
> > has CONFIG_MPENTIUM4=y, that is only appropriate for a very small number
> > of computers. The earlier ones are covered by x86/legacy, the later ones
> > are covered by x86/64.
> >
> > I don't know what others are running into, but the bigger issue for VMs
> > (possibly containers as well) is memory is expensive. A small VM
> > machine could have 2GB of memory. OpenWRT's baseline of 128MB is quite
> > nice for sticking a full-featured AP in a VM.
> >
> >
> > On Sun, Nov 12, 2023 at 06:31:29PM -0700, Philip Prindeville wrote:
> >>
> >> Sometime back I tried to add "pcituils" and "usbutils" to the generic
> >> x86_64 image, and was told that they weren't sufficiently "ubiquitous" to
> >> add to the default image.
> >>
> >> I note that they can be removed from the BOM easily by doing:
> >>
> >> DEVICE_PACKAGES += -pciutils -usbutils
> >>
> >> And that would remove them if they were already present in
> >> $(DEVICE_PACKAGES).
> >>
> >> I've never encountered an x86_64 platform that didn't have both USB and
> >> PCI, as they've without question become a "cheap commodity".
> >>
> >> Contrarily, I've yet to own or operate a platform that has a Mellanox
> >> switch. This seems arbitrary.
> >>
> >
> > I've encountered plenty of amd64 devices which lacked USB, PCI, PATA,
> > SATA, SCSI and SAS. They're all VMs, yet they're quite functional (an AP
> > in VM will almost certainly need PCI).
> >
> > I think the various hypervisors could do with targeted builds. Mostly
> > this involves removing nearly all common drivers, then keeping/adding a
> > small number of specialized drivers.
> >
> >
> > --
> > (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/)
> > \BS (| [email protected] PGP 87145445 |) /
> > \_CS\ | _ -O #include O- _ | / _/
> > 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
> >
> >
> >
> > ___
> > openwrt-devel mailing list
> > [email protected]
> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 回复: [PATCH 1/2] mac80211: rework MT7620 PA/LNA RF calibration
On Wed, Jul 26, 2023 at 02:57:08PM +, 杨 世基 wrote:
> Thanks for your review!
>
> on July 26, 2023, 1:49 p.m. UTC, Daniel Golle wrote:
> >Hi!
> >
> >Thank you for your contribution.
> >I (probably) found a minor typo, see below:
> >
> >On Wed, Jul 26, 2023 at 09:22:22PM +0800, Shiji Yang wrote:
> >> From: Shiji Yang
> >>
> >> This patch makes some improvements to the MT7620 RF calibration.
> >>
> >> 1. Move MT7620 PA/LNA calibration code to dedicated functions.
> >> 2. Restore RF and BBP registers before R-Calibration.
> >> 3. Do Rx DCOC calibration again before RXIQ calibration.
> >> 4. Correct MAC_RX_EN mask in rt2800_r_calibration()[1].
> >>
> >> [1] This change may fix the "BBP/RF register access failed" error:
> >> ieee80211 phy0: rt2800_wait_bbp_rf_ready: Error - BBP/RF register access
> >> failed, aborting
> >>
> >> Signed-off-by: Shiji Yang
> >> ---
> >> ...-rework-MT7620-PA-LNA-RF-calibration.patch | 312 ++
> >> 1 file changed, 312 insertions(+)
> >> create mode 100644
> >>package/kernel/mac80211/patches/rt2x00/998-wifi-rt2x00-rework-MT7620-PA-LNA-RF-calibration.patch
> >>
> >> diff --git
> >> a/package/kernel/mac80211/patches/rt2x00/998-wifi-rt2x00-rework-MT7620-PA-LNA-RF-calibration.patch
> >>
> >> b/package/kernel/mac80211/patches/rt2x00/998-wifi-rt2x00-rework-MT7620-PA-LNA-RF-calibration.patch
> >> new file mode 100644
> >> index 00..0cf34f3a6c
> >> +@@ -10688,30 +10637,151 @@ static void rt2800_init_rfcsr_6352(struc
> >> + rt2800_rfcsr_write_dccal(rt2x00dev, 5, 0x00);
> >> + rt2800_rfcsr_write_dccal(rt2x00dev, 17, 0x7C);
> >> + }
> >> ++}
> >> +
> >> +- rt6352_enable_pa_pin(rt2x00dev, 0);
> >> +- rt2800_r_calibration(rt2x00dev);
> >> +- rt2800_rf_self_txdc_cal(rt2x00dev);
> >> +- rt2800_rxdcoc_calibration(rt2x00dev);
> >> +- rt2800_bw_filter_calibration(rt2x00dev, true);
> >> +- rt2800_bw_filter_calibration(rt2x00dev, false);
> >> +- rt2800_loft_iq_calibration(rt2x00dev);
> >> +- rt2800_rxiq_calibration(rt2x00dev);
> >> +- rt6352_enable_pa_pin(rt2x00dev, 1);
> >> ++static void rt6352_inint_ext_palna(struct rt2x00_dev *rt2x00dev)
> >
> >'inint' should probably be 'init' (?)
>
>
> Yes, you are right. It should be 'init'.
>
>
> >> ++/* MT7620 PA/LNA initialization after switching channels */
> >> ++static void rt6352_init_palna_stage2(struct rt2x00_dev *rt2x00dev)
> >> ++{
> >> ++ rt2800_rf_self_txdc_cal(rt2x00dev);
> >> ++ rt2800_rxdcoc_calibration(rt2x00dev);
> >> ++ rt2800_bw_filter_calibration(rt2x00dev, true);
> >> ++ rt2800_bw_filter_calibration(rt2x00dev, false);
> >> ++ rt2800_loft_iq_calibration(rt2x00dev);
> >> ++
> >> ++ /* missing DPD Calibration for devices using internal PA */
> >> ++
> >> ++ rt2800_rxdcoc_calibration(rt2x00dev);
> >> ++ rt2800_rxiq_calibration(rt2x00dev);
> >> ++
> >> ++ if(rt2x00_has_cap_external_pa(rt2x00dev) ||
> >> ++ rt2x00_has_cap_external_lna_bg(rt2x00dev)) {
> >> ++ rt6352_enable_pa_pin(rt2x00dev, 1);
> >> ++ rt6352_inint_ext_palna(rt2x00dev);
>
>
> And same typo error 'inint' here.
>
> Do I need to send a v2 version to fix it? Or maybe you would like to
> manually edit it to avoid too many emails?
The best would be you'd give it a day for further reviews from others,
and then send v2 with all comments up to this point fixed.
To me this looks good, and I hope you will also send this and your
previous patch for rt2x00 to the linux-wireless mailing list to have
it included upstream.
Thank you again for your work!
>
> Best Regards,
> Shiji Yang
___
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/2] mac80211: rework MT7620 PA/LNA RF calibration
Hi!
Thank you for your contribution.
I (probably) found a minor typo, see below:
On Wed, Jul 26, 2023 at 09:22:22PM +0800, Shiji Yang wrote:
> From: Shiji Yang
>
> This patch makes some improvements to the MT7620 RF calibration.
>
> 1. Move MT7620 PA/LNA calibration code to dedicated functions.
> 2. Restore RF and BBP registers before R-Calibration.
> 3. Do Rx DCOC calibration again before RXIQ calibration.
> 4. Correct MAC_RX_EN mask in rt2800_r_calibration()[1].
>
> [1] This change may fix the "BBP/RF register access failed" error:
> ieee80211 phy0: rt2800_wait_bbp_rf_ready: Error - BBP/RF register access
> failed, aborting
>
> Signed-off-by: Shiji Yang
> ---
> ...-rework-MT7620-PA-LNA-RF-calibration.patch | 312 ++
> 1 file changed, 312 insertions(+)
> create mode 100644
> package/kernel/mac80211/patches/rt2x00/998-wifi-rt2x00-rework-MT7620-PA-LNA-RF-calibration.patch
>
> diff --git
> a/package/kernel/mac80211/patches/rt2x00/998-wifi-rt2x00-rework-MT7620-PA-LNA-RF-calibration.patch
>
> b/package/kernel/mac80211/patches/rt2x00/998-wifi-rt2x00-rework-MT7620-PA-LNA-RF-calibration.patch
> new file mode 100644
> index 00..0cf34f3a6c
> --- /dev/null
> +++
> b/package/kernel/mac80211/patches/rt2x00/998-wifi-rt2x00-rework-MT7620-PA-LNA-RF-calibration.patch
> @@ -0,0 +1,312 @@
> +From: Shiji Yang
> +Date: Tue, 25 Jul 2023 20:05:06 +0800
> +Subject: [PATCH] wifi: rt2x00: rework MT7620 PA/LNA RF calibration
> +
> +1. Move MT7620 PA/LNA calibration code to dedicated functions.
> + Calibration stage 1 is executed before configuring channels and
> + stage 2 is executed after configuring channels.
> +2. For external PA/LNA devices, restore RF and BBP registers before
> + R-Calibration.
> +3. Do Rx DCOC calibration again before RXIQ calibration.
> +4. Correct MAC_SYS_CTRL register RX mask to 0x08 in R-Calibration
> + function. For MAC_SYS_CTRL register, Bit[2] controls MAC_TX_EN
> + and Bit[3] controls MAC_RX_EN (Bit index starts from 0).
> +5. Adjust the register operation sequence according to the vendor
> + driver code. This may not be useful, but it can make things
> + clearer when developers try to review it.
> +
> +Signed-off-by: Shiji Yang
> +---
> + .../net/wireless/ralink/rt2x00/rt2800lib.c| 220 --
> + drivers/net/wireless/ralink/rt2x00/rt2x00.h | 6 +
> + 2 files changed, 151 insertions(+), 75 deletions(-)
> +
> +--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> +@@ -62,6 +62,9 @@ MODULE_PARM_DESC(watchdog, "Enable watch
> + rt2800_regbusy_read((__dev), H2M_MAILBOX_CSR, \
> + H2M_MAILBOX_CSR_OWNER, (__reg))
> +
> ++static void rt6352_init_palna_stage1(struct rt2x00_dev *rt2x00dev);
> ++static void rt6352_init_palna_stage2(struct rt2x00_dev *rt2x00dev);
> ++
> + static inline bool rt2800_is_305x_soc(struct rt2x00_dev *rt2x00dev)
> + {
> + /* check for rt2872 on SoC */
> +@@ -4151,6 +4154,9 @@ static void rt2800_config_channel(struct
> + rt2800_txpower_to_dev(rt2x00dev, rf->channel,
> + info->default_power3);
> +
> ++if (rt2x00_rt(rt2x00dev, RT6352))
> ++rt6352_init_palna_stage1(rt2x00dev);
> ++
> + switch (rt2x00dev->chip.rt) {
> + case RT3883:
> + rt3883_bbp_adjust(rt2x00dev, rf);
> +@@ -4482,66 +4488,6 @@ static void rt2800_config_channel(struct
> + rt2800_iq_calibrate(rt2x00dev, rf->channel);
> + }
> +
> +-if (rt2x00_rt(rt2x00dev, RT6352)) {
> +-if (test_bit(CAPABILITY_EXTERNAL_PA_TX0,
> +- &rt2x00dev->cap_flags)) {
> +-reg = rt2800_register_read(rt2x00dev, RF_CONTROL3);
> +-reg |= 0x0101;
> +-rt2800_register_write(rt2x00dev, RF_CONTROL3, reg);
> +-
> +-reg = rt2800_register_read(rt2x00dev, RF_BYPASS3);
> +-reg |= 0x0101;
> +-rt2800_register_write(rt2x00dev, RF_BYPASS3, reg);
> +-
> +-rt2800_rfcsr_write_chanreg(rt2x00dev, 43, 0x73);
> +-rt2800_rfcsr_write_chanreg(rt2x00dev, 44, 0x73);
> +-rt2800_rfcsr_write_chanreg(rt2x00dev, 45, 0x73);
> +-rt2800_rfcsr_write_chanreg(rt2x00dev, 46, 0x27);
> +-rt2800_rfcsr_write_chanreg(rt2x00dev, 47, 0xC8);
> +-rt2800_rfcsr_write_chanreg(rt2x00dev, 48, 0xA4);
> +-rt2800_rfcsr_write_chanreg(rt2x00dev, 49, 0x05);
> +-rt2800_rfcsr_write_chanreg(rt2x00dev, 54, 0x27);
> +-rt2800_rfcsr_write_chanreg(rt2x00dev, 55, 0xC8);
> +-rt2800_rfcsr_write_chanreg(rt2x00dev, 56, 0xA4);
> +-rt2800_rfcsr_write_chanreg(rt2x00dev, 57, 0x05);
> +-rt2800_rfcsr_write_chanreg(rt2x00dev, 58, 0x27);
> +-
Re: [PATCH v2] mac80211: limit MT7620 TX power based on eeprom calibration
On Sun, Jul 23, 2023 at 10:14:54AM +0800, Shiji Yang wrote: > From: Shiji Yang > > This patch adds basic TX power control for the MT7620 and limits its > maximum TX power. This can avoid the link speed decrease caused by > chip overheating. > > Signed-off-by: Shiji Yang > --- > Changes since v1: > * To avoid developers misunderstanding it, rename rt2800_config_alc() to > rt2800_config_alc_rt6352() since it's only used by RT6352(AKA MT7620). Picked to main branch. Thank you! ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] mac80211: limit MT7620 TX power based on eeprom calibration
On Sat, Jul 22, 2023 at 10:52:02PM +0800, Shiji Yang wrote:
> From: Shiji Yang
>
> This patch adds basic TX power control to the MT7620 and limits its
> maximum TX power. This can avoid the link speed decrease caused by
> chip overheating.
Thanks a lot for your patch and analysis of the situation.
As you add code reading values from the EEPROM, we need to make sure
that it doesn't break other chips (Rt5xxx most likely, Rt3xxx could
also be affected). The easiest would be to create a new function
rt2800_config_alc_mt7620 which is called only for MT7620 while keeping
the original codepath for all other rt2800 radios (unless we are 100%
sure that we won't break things).
>
> Signed-off-by: Shiji Yang
> ---
> ...t-MT7620-TX-power-based-on-eeprom-ca.patch | 83 +++
> 1 file changed, 83 insertions(+)
> create mode 100644
> package/kernel/mac80211/patches/rt2x00/997-wifi-rt2x00-limit-MT7620-TX-power-based-on-eeprom-ca.patch
>
> diff --git
> a/package/kernel/mac80211/patches/rt2x00/997-wifi-rt2x00-limit-MT7620-TX-power-based-on-eeprom-ca.patch
>
> b/package/kernel/mac80211/patches/rt2x00/997-wifi-rt2x00-limit-MT7620-TX-power-based-on-eeprom-ca.patch
> new file mode 100644
> index 00..ecb8577752
> --- /dev/null
> +++
> b/package/kernel/mac80211/patches/rt2x00/997-wifi-rt2x00-limit-MT7620-TX-power-based-on-eeprom-ca.patch
> @@ -0,0 +1,83 @@
> +From: Shiji Yang
> +Date: Sat, 22 Jul 2023 21:56:30 +0800
> +Subject: [PATCH] wifi: rt2x00: limit MT7620 TX power based on eeprom
> + calibration
> +
> +In the vendor driver, the current channel power is queried from
> +EEPROM_TXPOWER_BG1 and EEPROM_TXPOWER_BG2. And then the mixed value
> +will be written into the low half-word of the TX_ALC_CFG_0 register.
> +The high half-word of the TX_ALC_CFG_0 is a fixed value 0x2f2f.
> +
> +We can't get the accurate TX power. Based on my tests and the new
> +MediaTek mt76 driver source code, the real TX power is approximately
> +equal to channel_power + (max) rate_power. Usually max rate_power is
> +the gain of the OFDM 6M rate, which can be readed from the offset
> +EEPROM_TXPOWER_BYRATE +1.
> +
> +Based on these eeprom values, this patch adds basic TX power control
> +to the MT7620 and limits its maximum TX power. This can avoid the
> +link speed decrease caused by chip overheating.
> +
> +Signed-off-by: Shiji Yang
> +---
> + .../net/wireless/ralink/rt2x00/rt2800lib.c| 43 +--
> + 1 file changed, 30 insertions(+), 13 deletions(-)
> +
> +--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> +@@ -3894,25 +3894,42 @@ static void rt2800_config_channel_rf7620
> + static void rt2800_config_alc(struct rt2x00_dev *rt2x00dev,
> + struct ieee80211_channel *chan,
> + int power_level) {
> +-u16 eeprom, target_power, max_power;
> ++u16 eeprom, chan_power, rate_power, target_power;
> ++u16 tx_power[2];
> ++s8 *power_group[2];
> + u32 mac_sys_ctrl;
> +-u32 reg;
> ++u32 cnt, reg;
> + u8 bbp;
> +
> +-/* hardware unit is 0.5dBm, limited to 23.5dBm */
> +-power_level *= 2;
> +-if (power_level > 0x2f)
> +-power_level = 0x2f;
> ++/* get per channel power, 2 channels in total, unit is 0.5dBm */
> ++power_level = (power_level - 3) * 2;
> ++/*
> ++ * We can't set the accurate TX power. Based on some tests, the real
> ++ * TX power is approximately equal to channel_power + (max)rate_power.
> ++ * Usually max rate_power is the gain of the OFDM 6M rate.
> ++ */
> ++rate_power = rt2800_eeprom_read_from_array(rt2x00dev,
> ++EEPROM_TXPOWER_BYRATE, 1) & 0x3f;
> ++power_level -= rate_power;
> ++if (power_level < 1)
> ++power_level = 1;
> ++if (power_level > chan->max_power * 2)
> ++power_level = chan->max_power * 2;
> +
> +-max_power = chan->max_power * 2;
> +-if (max_power > 0x2f)
> +-max_power = 0x2f;
> ++power_group[0] = rt2800_eeprom_addr(rt2x00dev, EEPROM_TXPOWER_BG1);
> ++power_group[1] = rt2800_eeprom_addr(rt2x00dev, EEPROM_TXPOWER_BG2);
> ++for (cnt = 0; cnt < 2; cnt++) {
> ++chan_power = power_group[cnt][rt2x00dev->rf_channel - 1];
> ++if (chan_power >= 0x20 || chan_power == 0)
> ++chan_power = 0x10;
> ++tx_power[cnt] = power_level < chan_power ? power_level :
> chan_power;
> ++}
> +
> + reg = rt2800_register_read(rt2x00dev, TX_ALC_CFG_0);
> +-rt2x00_set_field32(®, TX_ALC_CFG_0_CH_INIT_0, power_level);
> +-rt2x00_set_field32(®, TX_ALC_CFG_0_CH_INIT_1, power_level);
> +-rt2x00_set_field32(®, TX_ALC_CFG_0_LIMIT_0, max_power);
> +-rt2x00_set_field32(®, TX_ALC_CFG_0_LIMIT_1, max_power);
> ++rt2x00_set_field32(®, TX_ALC_CFG_0_CH_INIT_0, tx_power[0]);
> ++rt2x00_set_field32(®, TX_ALC_CFG_0_CH_INIT_1, tx_power[1]);
> ++rt2x00_
Re: [PATCH 4/4] gemini: Bump to kernel v6.1
On Sat, Jun 03, 2023 at 11:44:04AM +0300, Arınç ÜNAL wrote: > On 2.06.2023 10:18, Linus Walleij wrote: > > On Thu, Jun 1, 2023 at 11:20 PM Christian Lamparter > > wrote: > > > > > I looked into "how to get the old and new usb-fotg210" into one > > > "define KernelPackage/usb-fotg210". Thing is, you put backported > > > fotg's 6.2 infrastructure into your gemini's patches: > > > 0002-usb-fotg210-Collect-pieces-of-dual-mode-controller.patch > > > (that's a big one!) > > > ... > > > > > > So, your gemini's 6.1 isn't the same as every other target in > > > regard to fotg210 there (that said, gemini is currently the > > > only user due to @TARGET_gemini. phew!). Due to the Makefile > > > and KConfig changes: in OpenWrt's vanilla 6.1 the module is still > > > fotg210-hcd(.ko), whereas gemini's 6.1 its been changed to fotg210(.ko). > > > So, to deal with this at least a little bit, I just moved it to > > > target/linux/gemini/modules.mk . > > > > I checked it, wow these @lt6.1 etc I would never have figured out > > so thanks a lot for stepping in on this! > > > > > That said: This should be worth it? Reason being that since all > > > this extra time spend, should make the target+fotg210 ready for > > > the upcoming, next stable release (v6.6/7?), right? > > > > Apart from tidying up the code, it makes the device mode work on > > the DNS-313 actually, so it's not just cosmetic, I have been able > > to use the USB port for serial, I just need to figure out how to get > > OpenWrt to open a secondary console on it and people can get > > serial access without soldering. > > > > (The original use of the device USB port on that device is USB mass > > storage, but that was an extreme hack on the original device, including > > a plastic cover that shift over the USB port when connected to network > > so you cannot use network and USB at the same time to access the > > same file partition...) > > > > > BTW: Do you have some time to look into realtek's DSA for the > > > RTL8363SB? I'm converting some of the APM821xx Devices > > > to DSA and the rtl8365mb seems promising. I've seen that you did > > > some major work there. But there are some snags that I'm not sure > > > are limited to the RTL8363SB (access through MDIO needs different > > > code. And what's up with the CPU-Port or Extif?) or not. > > > (will post to the appropriate ML for that in the "upcoming months") > > > > I don't have any device with this DSA on it, but certainly I'm available > > for questions and review. But Alvin Šipraga > > and Luiz Angelo Daros de Luca have been very > > helpful with the upstream code for RTL8365MB, and it also "should" > > support RTL8363SC so I would be surprised if RTL8363SB is any > > different. > > > > So best case if you can boot the upstream kernel (or backport all the > > patches to drivers/net/dsa/realtek...) the RTL8365MB driver: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/dsa/realtek/rtl8365mb.c > > just edit rtl8365mb_chip_infos[] to include the magic for RTL8363SB > > and see if it magically works. You probably need a jam table magic > > sequence from the vendor driver if you have that. > > > > The upstream device tree for ASUS RT AC88U has the > > 8365MB courtesy of Arınç ÜNAL : > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/bcm47094-asus-rt-ac88u.dts > > > > If you just copy/paste that +/- some changes it should probe, all > > devices use compatible = "realtek,rtl8365mb"; no matter which > > variant it is. Arınç has also been very helpful with this code, and I > > think we wanna bring in the RTL8365MB patches at least for > > BCM53xx for v6.1 (but I think we should probably put them into > > linux/generic). > > > > I think Arınç already has plans to bring this to OpenWrt for v6.1 > > though, Arınç? > > I prefer to stay away from backporting features to older Linux versions. The > reasons being: > > - OpenWrt will eventually use a kernel version by default which will have > the feature. It doesn't satisfy me to do all that work just for some OpenWrt > devices to use this feature earlier. I would rather just make OpenWrt use > the kernel version that's already got the feature. I already have some > efforts to improve the current way to do this, I had a presentation on > Battlemesh v15 regarding this and more. I agree that in an ideal world this how it should be. However, in the practical world as it is that will result in massive delays and add hardware support at a point in time that the hardware is already EOL in many cases. Let's look at one example: The BananaPi R3 devboard MediaTek had already done a good job and managed to get basic support for the MT7986 SoC landed in v5.17. Note that this is exceptional, most chip vendors do not care at all to have support in mainline Linux ahead of time. First hardware samples of the R3 became available in May 2022, a few months after you could buy the final hardwa
Re: Wifi at the Luci web interface
On Fri, May 19, 2023 at 10:11:39AM +0200, e9hack wrote: > Hi, > > I face a strange behaviour. If I compile hostapd with openssl, the Luci web > interface shows both wifis (2.4G+5G) as active and shows connected stations. > If I compile hostapd with wolfssl, the Luci web interface shows only the 5G > wifi as active and shows connected stations. The 2.4G wifi is shown in gray. > On the network->wireless page, the radio for 2.4G is marked as 'Device is not > active'. The SSID's are marked as 'disabled'. This occurs on a ASUS AX53U and > a TP-Link WDR3600 router. The 2.4G wifi is running and stations are > connected. Hostapd is build with the internal radius server activated. The > setup for 2.4G is 8 wifi's with encryption wpa3, wpa3-mixed, sae and > sae-mixed. > > How does Luci retrieve the wifi information? You are probably missing rpcd-mod-iwinfo ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Any plans to submit realtek target drivers to mainline Linux?
On Sun, May 07, 2023 at 11:56:59AM -0300, Luiz Angelo Daros de Luca wrote: > Em sáb., 6 de mai. de 2023 06:12, Arınç ÜNAL escreveu: > > > > Hi. > > Hi Arinç, > > > I see a lot of development on the network drivers like DSA, PHY, etc. > > Are there any plans to put all these drivers on the realtek target on > > mainline Linux? To fully support these SoCs on mainline Linux? > > > > Arınç > > > > I'm a minor contributor to the DSA driver for the realtek target, but > I have my 2 cents to share. I believe we can start to enlist what > would be needed to get the drivers upstream. We can start the > discussion from there: > > - The DSA driver uses a lot of magic numbers that would not be > accepted by the upstream kernel. They must be converted into macros, > enum, inline functions and friends. > - There are shared functions with internal conditions (if modelA then > ...). Mixed with magic numbers, it is much easier to miss a > peculiarity about a subtarget and introduce bugs. A nice way to avoid > that is to convert them into indirect calls to subtarget functions > (*_ops). > - The driver uses hardcoded addresses and direct memory writes. I > don't know if there is anything incompatible but upstream drivers > normally use regmap. It will also clean up a lot of things and > introduce nice functions. > - The DSA driver uses a generic tag that is converted afterwards by > each (ethernet?) driver into its CPU tag. The DSA taggers were > designed to decouple CPU tag from ethernet driver logic and upstream > maintainters might ask to implement each CPU tagger as a proper DSA > tag. Although it might not make sense to have an ethernet driver > without a tag in this target, it would get closer to how outer drivers > work and make it easier to understand the driver. - The RealTek SoCs can (and must!) offload paged MDIO phy access operations. In order to not use patched PHY drivers which directly use SoC-specific MDIO access functions, we will need to introduce support for offloading paged Clause-22 MDIO to vanilla Linux. I've started with that, but it certainly needs more work and preparation to be less vendor-specific. Practically *all* PHY vendors use register 0x1f for selecting the register page. The RealTek SoCs poll PHY state in hardware and hence require using the offloaded page access methods also when accessing PHY registers from Linux, as that would otherwise interfere with that hardware-driven PHY polling. > > Regards, > > Luiz > > ___ > openwrt-devel mailing list > [email protected] > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Objective of OpenWRT/x86?
like the Intel NUC which are popular as high-performance network appliances come with on-board graphics relying in shared video memory, and many people will want to use HDMI+USB as a console due to the lack of a serial port (I know it's available on some pinheader inside the case, but not even a standard connector...) > > > > > Another item is the goal of trying to self-host. Being able to self-host > > > is a worthy goal, but that has very distinct needs from an embedded > > > networking device. > > > > Imho this is is very much out of scope. Other linux distros aren't going > > to disappear any time soon. > > Quite true. I ran across an article about someone trying to do this, so > I have to admit at least one person has that goal in mind. My concern is > all these goals seem to be getting mixed together when they actually > conflict. > > > > On Sun, Apr 30, 2023 at 10:40:40PM -0600, 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: > > >> > > >>> Problem is instead of the recommended 128MB memory, 16MB of storage > > >>> (https://openwrt.org/supported_devices/432_warning) the virtualization > > >>> examples (https://openwrt.org/docs/guide-user/virtualization/start) are > > >>> suggesting massively more memory. 256MB (small Xen example), 512MB > > >>> (VMware OpenWRT/15.05) or 1GB (Qemu examples). > > >> > > >> Sorry, why is this a "problem"? > > >> > > >> I spent $1100 on a Xeon-D box with 128GB of DRAM, 16 hyper threaded > > >> cores, and 2TB of NVMe. > > > > > > If those numbers are to be believed (which is now suspect), it means a > > > *requirement* to devote that much to network operations. Not being a > > > requirement means one could use the memory for other things. Or I could > > > allow more than that to do extra complicated network things. > > > > Which part is a lie? > > The numbers I meant as being suspect were the estimates for OpenWRT VM > needs, not your numbers. Sorry about the misunderstood statement. > > The 1GB for Qemu was high enough to be obviously ridiculous. The 512MB > for VMware is also rather a bit out there. The 256MB listed for Xen is > in the right range to be plausible as a minimum requirement. Build most > ethernet drivers into the kernel and one could readily require that much. > > > > >>> One issue I've found is the kernel configurations seem ill-suited to > > >>> x86. > > >>> Almost any storage driver used by 10 or more people is built into the > > >>> kernel. As a result the *single* kernel is huge. > > >> > > >> If it's not used as a boot device, we could make it kmod-able... > > >> otherwise we'd need to add initramfs... I don't think anyone wants to > > >> go down that road. Too easy to brick devices. > > >> > > >> I think we should leverage more subtargets and profiles, but that's a > > >> separate discussion. > > > > > > This wraps back to my original issue. x86 has some differences and they > > > haven't been adapted to. > > > > > > x86 is easier to recover, so an initramfs is quite viable, perhaps x86 > > > should be the exception and have one. Alternatively, indeed more > > > targets. > > > > > > Perhaps "x86" and "x86vm"? > > > > There were sound reasons for avoiding initramfs. > > Indeed. I'm suggesting perhaps OpenWRT/x86 should be different in having > one. Otherwise x86 should receive treatment equal to other systems and > have a few more distinct builds. > > > > >>> If one was to go this direction, I suppose there might be "giant" or > > >>> "desktop" build. Each hypervisor could use a target, include "hardware" > > >>> guaranteed to be present. Then build all network drivers as modules (so > > >>> any device can be passed-in). > > >> > > >> The number of interfaces supported by virtualization (at least in KVM) > > >> are quite limited (e1000/igbe, ixgbe, rtl8139, and virtio) so I don't > > >> see this as much of a problem. > > > > > > The number of interface types supported by KVM is quite limited. The > > > number of interface types s
Re: Objective of OpenWRT/x86?
On Mon, May 01, 2023 at 09:01:29AM -0600, Philip Prindeville wrote: > > > > On May 1, 2023, at 8:12 AM, Joseph Mullally wrote: > > > > On Mon, May 1, 2023 at 5:43 AM 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: > > > 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? > > > > I ran the OpenWrt x86/64 image under KVM/libvirtd for years with an > > Intel Wifi card connected through exclusive PCI passthrough, and it > > worked fine. There is enough conjecture already. > > > From one anecdotal episode I'm not going to extrapolate that this is a robust > solution in all cases; I wouldn't get very far as a cyber security engineer > thinking this way. Maybe the fact that PCI passthrough is facilitated by the IOMMU which takes care of resource isolation makes you feel a bit better about it? The host from this point on doesn't deal with that PCIe slot any more, and passtrough is happening entirely in hardware. However, keep in mind that access to PCIe in most cases (such as WiFi adapters) doesn't assume the user could be a bad actor. You will probably still be able to do bad things with it, esp. if you know the hardware well (such as triggering overheat/overcurrent, deliberately creating radio interference with other system parts, ...). ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] base-files: fix nand_upgrade_ubinized()
On Tue, Apr 11, 2023 at 02:31:55PM +0200, Koen Vandeputte wrote:
> On Tue, Apr 11, 2023 at 10:33 AM Koen Vandeputte
> wrote:
> >
> > On Tue, Apr 11, 2023 at 1:36 AM Lanchon wrote:
> > >
> > >
> > >
> > > On 4/10/23 15:38, Daniel Golle wrote:
> > > > On Mon, Apr 10, 2023 at 07:01:35PM +0200, Rafał Miłecki wrote:
> > > >> From: Rafał Miłecki
> > > >>
> > > >> When using "ubiformat" with stdin it requires passing image size using
> > > >> the -S argument. Provide it just like we do for "ubiupdatevol".
> > > >>
> > > >> This fixes:
> > > >> ubiformat: error!: must use '-S' with non-zero value when reading from
> > > >> stdin
> > > >>
> > > >> This change fixes sysupgrade for bcm53xx and bcm4908 NAND devices
> > > >> possibly some other targets too.
> > > >>
> > > >> Cc: Rodrigo Balerdi
> > > >> Cc: Daniel Golle
> > > >> Fixes: 971071212052 ("base-files: accept gzipped nand sysupgrade
> > > >> images")
> > > >> Signed-off-by: Rafał Miłecki
> > > > Acked-by: Daniel Golle
> > > >
> > > > Please apply asap.
> > >
> > > (Dan, do you want me to PR?)
> > >
> > > hi Rafa, thanks!
> > >
> > > i wonder how it is possible that the code as is worked for me; i tested
> > > many times with compressed ubinized image.
> > >
> > >
> > > >
> > > >> ---
> > > >> package/base-files/files/lib/upgrade/nand.sh | 4 +++-
> > > >> 1 file changed, 3 insertions(+), 1 deletion(-)
> > > >>
> > > >> diff --git a/package/base-files/files/lib/upgrade/nand.sh
> > > >> b/package/base-files/files/lib/upgrade/nand.sh
> > > >> index 907945b349..fa29d575a8 100644
> > > >> --- a/package/base-files/files/lib/upgrade/nand.sh
> > > >> +++ b/package/base-files/files/lib/upgrade/nand.sh
> > > >> @@ -261,10 +261,12 @@ nand_upgrade_ubinized() {
> > > >> local ubi_file="$1"
> > > >> local gz="$2"
> > > >>
> > > >> +local ubi_length=$( (${gz}cat "$ubi_file" | wc -c) 2> /dev/null)
> > > >> +
> > > >> nand_detach_ubi "$CI_UBIPART" || return 1
> > > >>
> > > >> local mtdnum="$( find_mtd_index "$CI_UBIPART" )"
> > > >> -${gz}cat "$ubi_file" | ubiformat "/dev/mtd$mtdnum" -y -f - &&
> > > >> ubiattach -m "$mtdnum"
> > > >> +${gz}cat "$ubi_file" | ubiformat "/dev/mtd$mtdnum" -S
> > > >> "$ubi_length" -y -f - && ubiattach -m "$mtdnum"
> > > >> }
> > > >>
> > > >> # Write the UBIFS image to UBI rootfs volume
> > > >> --
> > > >> 2.34.1
> > > >>
> >
> > I wonder if this also fixes the sysupgrade issues I reported on imx6 ..
> > Will test today
>
> Yep .. it also fixes the upgrade issue on imx6 boards.
> Thanks!
>
> Tested-by: Koen Vandeputte
Thank you for testing.
I've now applied the patch.
___
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] base-files: fix nand_upgrade_ubinized()
On Mon, Apr 10, 2023 at 07:01:35PM +0200, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> When using "ubiformat" with stdin it requires passing image size using
> the -S argument. Provide it just like we do for "ubiupdatevol".
>
> This fixes:
> ubiformat: error!: must use '-S' with non-zero value when reading from stdin
>
> This change fixes sysupgrade for bcm53xx and bcm4908 NAND devices
> possibly some other targets too.
>
> Cc: Rodrigo Balerdi
> Cc: Daniel Golle
> Fixes: 971071212052 ("base-files: accept gzipped nand sysupgrade images")
> Signed-off-by: Rafał Miłecki
Acked-by: Daniel Golle
Please apply asap.
> ---
> package/base-files/files/lib/upgrade/nand.sh | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/package/base-files/files/lib/upgrade/nand.sh
> b/package/base-files/files/lib/upgrade/nand.sh
> index 907945b349..fa29d575a8 100644
> --- a/package/base-files/files/lib/upgrade/nand.sh
> +++ b/package/base-files/files/lib/upgrade/nand.sh
> @@ -261,10 +261,12 @@ nand_upgrade_ubinized() {
> local ubi_file="$1"
> local gz="$2"
>
> + local ubi_length=$( (${gz}cat "$ubi_file" | wc -c) 2> /dev/null)
> +
> nand_detach_ubi "$CI_UBIPART" || return 1
>
> local mtdnum="$( find_mtd_index "$CI_UBIPART" )"
> - ${gz}cat "$ubi_file" | ubiformat "/dev/mtd$mtdnum" -y -f - && ubiattach
> -m "$mtdnum"
> + ${gz}cat "$ubi_file" | ubiformat "/dev/mtd$mtdnum" -S "$ubi_length" -y
> -f - && ubiattach -m "$mtdnum"
> }
>
> # Write the UBIFS image to UBI rootfs volume
> --
> 2.34.1
>
___
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt Next Generation Ideas
On Fri, Mar 31, 2023 at 01:34:03PM -0700, Elliott Mitchell wrote: > On Fri, Mar 31, 2023 at 02:47:23PM +0100, Daniel Golle wrote: > > > > Another example is selection of the rootfs. Kernel folks argue that > > we should use an initramfs for that, however, we try to avoid the > > overhead of using an initramfs with it's own userland just for that. > > There are two options here. First, 10 mildly different images can be > built for each of the 10 variants of hardware. Second, 1 image can be > built which loads appropriate drivers during boot. > > Issue is OpenWRT aims for the first option for ARM/MIPS/RISC-V. For x86 > though there are 2 candidate images to cover all configurations, which > for the first approach should have 7-12 images. > > x86 has the "generic" image and the "64" image. For the first approach > there should be a different build for: > > 1> Running on raw hardware. > > 2> Running on HyperV. > > 3> Running on KVM. > > 4> Running on QEMU. > > 5> Running on Xen. > > So should OpenWRT's x86 builds be distinct from ARM/MIPS/RISC-V in using > an initramfs in order to combine these? x86 is generally not as space constraint as other platforms and most importantly uses a boot method (IBM PC bootsector or UEFI) which is available on 99.9% of x86 hardware. The reason why we have individual images for every ARM/MIPS/RISC-V device is simply because a generic boot method is not (yet) implemented on those devices. We **have to** provide per-devices images for OpenWrt to be able to boot using the vendor-provided device firmware. Using an initramfs would **not** solve that. Sidenote: some ARM64 devices do support UEFI and there are other vendor-specific "generic" methods such as ONIE -- however, that's a very small minority of high-end devices and literally NO off-the-shelf consumer hardware supports any of that as of today. > Should OpenWRT have 12 distinct x86 images? Why would that be needed? The whole point of x86 is to be compatible, and usually has plenty of RAM and storage, so shipping all drivers needed is also not a problem. > > Both approaches are nominally viable, problem is *one* approach needs to > be chosen for x86 on modern hardware. > > > On Fri, Mar 31, 2023 at 03:52:47PM +0300, Arınç ÜNAL wrote: > > On 31.03.2023 14:33, Daniel Golle wrote: > > > > > > On Fri, Mar 31, 2023 at 12:44:12PM +0300, Arınç ÜNAL wrote: > > >> > > >> Some Modest Virtualization Observations > > > > > > How is this related? Virtualization (with OpenWrt being the guest) > > > matters on x86 which is usually not that space-constraint. > > > And maybe armvirt. If space is a problem for older x86 boards, let's > > > disable guest support in x86/legacy. > > > > It was a broad example without any explanation. What caught my attention > > there is the configuration of the kernel that causes problems, if I > > understand correctly. > > The real issue is everything I've looked at makes it seem x86 hasn't > received the attention it needs. Looks like it is purely a development > tool, not really providing the functionality it could. Just like any other platform the level of support depends on voluntary contributions by developers and users. If you see a job, it's yours :) > > Notable kernel options: > # CONFIG_XEN_BACKEND is not set > Most Xen backend drivers aren't well suited for OpenWRT, but the > ethernet backend is. Please send a patch or open a pull-request adding the needed kernel options to support Xen networking to target/linux/x64/64/config-5.15. > > # CONFIG_CFG80211 is not set > # CONFIG_LIB80211 is not set > If 802.11 devices could be fully passed into a VM you could have a > proper access point in a VM. Wireless drivers are supported -- just like on any other platform -- via backported drivers. See package/kernel/mac80211. We generally do not use cfg80211 and lib80211 at the version level of the kernel, but use more recent backported drivers instead. So this is intentional and will provide you with **more recent drivers**. > > Then we have the architectures chosen. "64" => x86_64-linux-musl, > "generic" => i386-linux-musl/Pentium4 > > Could be CONFIG_MPENTIUM4 merely uses options ideal for a P4 and could be > reasonable for most of AMD's 64-bit processors, but otherwise that is > about as non-generic as possible. The point here is not optimization, but finding a good compromise to not having to compile **all** packages for **all** CPU architectures. The same is btw also true for MIPS and ARM targets. We pick a good compromise in terms of optimization. Example: *
Re: OpenWrt Next Generation Ideas
On Fri, Mar 31, 2023 at 04:18:53PM +, psv sridhar wrote: > idiots, email looks like offcial and you are sending to un-known people. > Thanks and Regards Thank you for the kind advise. This is a deliberate public debate and you are welcome to participate in any meaningful way. > Sridhar PSVPhone 571 244-5862 > > On Friday, March 31, 2023 at 11:07:50 AM CDT, Felix Fietkau > wrote: > > On 31.03.23 14:52, Arınç ÜNAL wrote: > > On 31.03.2023 14:33, Daniel Golle wrote: > >> Hi! > >> > >> On Fri, Mar 31, 2023 at 12:44:12PM +0300, Arınç ÜNAL wrote: > >>> Hi all, > >>> > >>> These are the ideas I've been thinking about for the future of OpenWrt > >>> for a > >>> while. It looks complete enough to share it with all of you. > >>> > >>> I'm willing to put a great deal of effort to get as much out-of-tree > >>> patches > >>> on mainline Linux as possible. > >>> > >>> You can make a comment on Notion or discuss it here, I'm wondering if the > >>> ideas are feasible and how well it would benefit the people maintaining > >>> OpenWrt. > >>> > >>> https://arinc9.notion.site/OpenWrt-next-gen-ideas-6db745e7584b4823950291c96f2326bb > >> > >> I will comment here, I don't have an account on Notion and it seems > >> to be required to be able to comment there. > >> > >>> defconfig for each device instead of config for each (sub)target. > >> > >> Given that we support thousands of devices this will not only increase > >> the time needed to build a release or snapshot by several magnitudes, > >> but also make debugging **much** harder. As of now, all devices of a > >> subtarget are using the same kernel, hence e.g. symbol offsets in a > >> kernel stack dump match for all of them. To reproduce or investigate > >> a problem it's hence enough to have similar hardware, not necessarily > >> the exact same board. As we are already lacking testers and maintainers > >> for the relatively small amount of targets/subtargets, have a build for > >> each board would make things much worse... > >> > >> Per-device builds would also be an invitation to downstream users to > >> introduce device-specific (kernel-)hacks. If you want that, better go > >> for OpenEmbedded. > >> > >> We can modularize things more or even have more sub-targets if it's > >> really needed to save space. > >> > >> The disadvantages outweight the advantages imho when it comes to having > >> a complete kernel build for each device. > > > > Hmm, what about we enable the bare minimum of kernel options for a > > target, which is already how it is, then select the rest as kernel > > modules (like on the makefile of a target for each device) on the > > defconfig for each device? So, in the end, it wouldn't be any different > > than selecting a kernel module package from the OpenWrt SDK which, I > > believe, does not change the symbol offsets in the kernel stack. > > > > My reason for pushing for the use defconfigs is that anyone can build > > the Linux kernel for their device, without needing OpenWrt. So the work > > for adding support for a device would benefit far more people. > There are a lot of options in the OpenWrt menuconfig (including kmod > package selections) which *do* affect the kernel compilation in a major > way. They can change struct sizes, enabled features, affect compiled-in > code inside functions, etc. > > For maintenance, I strongly believe that switching from the current > system to maintaining full kernel config files is a huge step backwards, > because maintaining individual config files makes them so much easier to > accidentally go out of sync with each other. > > If you want to make it easier to build per-device kernels outside of > OpenWrt, I'd recommend adding a build system feature to export target > defconfig files. > > >>> Either submit all out-of-tree patches on OpenWrt to Linux or get rid > >>> of them and find a better solution for what the unacceptable patch > >>> does. > >> > >> This would of course be great, but especially for legacy devices it may > >> not be possible in many cases. Think of all the devices stuck on > >> swconfig, just to name one example... Think of all the completely > >> broken vendor bootloaders which require hacks (mangeling kernel cmdline > >> and such) and cannot easily be replace
Re: OpenWrt Next Generation Ideas
On Fri, Mar 31, 2023 at 05:35:22PM +0300, Arınç ÜNAL wrote: > On 31.03.2023 16:47, Daniel Golle wrote: > > On Fri, Mar 31, 2023 at 03:52:47PM +0300, Arınç ÜNAL wrote: > > > On 31.03.2023 14:33, Daniel Golle wrote: > > > > Hi! > > > > > > > > On Fri, Mar 31, 2023 at 12:44:12PM +0300, Arınç ÜNAL wrote: > > > > > Hi all, > > > > > > > > > > These are the ideas I've been thinking about for the future of > > > > > OpenWrt for a > > > > > while. It looks complete enough to share it with all of you. > > > > > > > > > > I'm willing to put a great deal of effort to get as much out-of-tree > > > > > patches > > > > > on mainline Linux as possible. > > > > > > > > > > You can make a comment on Notion or discuss it here, I'm wondering if > > > > > the > > > > > ideas are feasible and how well it would benefit the people > > > > > maintaining > > > > > OpenWrt. > > > > > > > > > > https://arinc9.notion.site/OpenWrt-next-gen-ideas-6db745e7584b4823950291c96f2326bb > > > > > > > > I will comment here, I don't have an account on Notion and it seems > > > > to be required to be able to comment there. > > > > > > > > > defconfig for each device instead of config for each (sub)target. > > > > > > > > Given that we support thousands of devices this will not only increase > > > > the time needed to build a release or snapshot by several magnitudes, > > > > but also make debugging **much** harder. As of now, all devices of a > > > > subtarget are using the same kernel, hence e.g. symbol offsets in a > > > > kernel stack dump match for all of them. To reproduce or investigate > > > > a problem it's hence enough to have similar hardware, not necessarily > > > > the exact same board. As we are already lacking testers and maintainers > > > > for the relatively small amount of targets/subtargets, have a build for > > > > each board would make things much worse... > > > > > > > > Per-device builds would also be an invitation to downstream users to > > > > introduce device-specific (kernel-)hacks. If you want that, better go > > > > for OpenEmbedded. > > > > > > > > We can modularize things more or even have more sub-targets if it's > > > > really needed to save space. > > > > > > > > The disadvantages outweight the advantages imho when it comes to having > > > > a complete kernel build for each device. > > > > > > Hmm, what about we enable the bare minimum of kernel options for a target, > > > which is already how it is, then select the rest as kernel modules (like > > > on > > > the makefile of a target for each device) on the defconfig for each > > > device? > > > So, in the end, it wouldn't be any different than selecting a kernel > > > module > > > package from the OpenWrt SDK which, I believe, does not change the symbol > > > offsets in the kernel stack. > > > > > > My reason for pushing for the use defconfigs is that anyone can build the > > > Linux kernel for their device, without needing OpenWrt. So the work for > > > adding support for a device would benefit far more people. > > > > This is pretty much what we are currently doing. > > The exception are network drivers to allow for failsafe mode to work > > and provide SSH access **before** any modules are loaded. > > Got it, network drivers should also be built into the kernel on the > defconfigs then. > > > > > > > > > > > > > > > Some Modest Virtualization Observations > > > > > > > > How is this related? Virtualization (with OpenWrt being the guest) > > > > matters on x86 which is usually not that space-constraint. > > > > And maybe armvirt. If space is a problem for older x86 boards, let's > > > > disable guest support in x86/legacy. > > > > > > It was a broad example without any explanation. What caught my attention > > > there is the configuration of the kernel that causes problems, if I > > > understand correctly. > > > > > > > > > > > > Contribute defconfigs and all the devicetrees on OpenWrt to Linux. > > > > > > > > For devicetrees this would
Re: OpenWrt Next Generation Ideas
On Fri, Mar 31, 2023 at 03:52:47PM +0300, Arınç ÜNAL wrote: > On 31.03.2023 14:33, Daniel Golle wrote: > > Hi! > > > > On Fri, Mar 31, 2023 at 12:44:12PM +0300, Arınç ÜNAL wrote: > > > Hi all, > > > > > > These are the ideas I've been thinking about for the future of OpenWrt > > > for a > > > while. It looks complete enough to share it with all of you. > > > > > > I'm willing to put a great deal of effort to get as much out-of-tree > > > patches > > > on mainline Linux as possible. > > > > > > You can make a comment on Notion or discuss it here, I'm wondering if the > > > ideas are feasible and how well it would benefit the people maintaining > > > OpenWrt. > > > > > > https://arinc9.notion.site/OpenWrt-next-gen-ideas-6db745e7584b4823950291c96f2326bb > > > > I will comment here, I don't have an account on Notion and it seems > > to be required to be able to comment there. > > > > > defconfig for each device instead of config for each (sub)target. > > > > Given that we support thousands of devices this will not only increase > > the time needed to build a release or snapshot by several magnitudes, > > but also make debugging **much** harder. As of now, all devices of a > > subtarget are using the same kernel, hence e.g. symbol offsets in a > > kernel stack dump match for all of them. To reproduce or investigate > > a problem it's hence enough to have similar hardware, not necessarily > > the exact same board. As we are already lacking testers and maintainers > > for the relatively small amount of targets/subtargets, have a build for > > each board would make things much worse... > > > > Per-device builds would also be an invitation to downstream users to > > introduce device-specific (kernel-)hacks. If you want that, better go > > for OpenEmbedded. > > > > We can modularize things more or even have more sub-targets if it's > > really needed to save space. > > > > The disadvantages outweight the advantages imho when it comes to having > > a complete kernel build for each device. > > Hmm, what about we enable the bare minimum of kernel options for a target, > which is already how it is, then select the rest as kernel modules (like on > the makefile of a target for each device) on the defconfig for each device? > So, in the end, it wouldn't be any different than selecting a kernel module > package from the OpenWrt SDK which, I believe, does not change the symbol > offsets in the kernel stack. > > My reason for pushing for the use defconfigs is that anyone can build the > Linux kernel for their device, without needing OpenWrt. So the work for > adding support for a device would benefit far more people. This is pretty much what we are currently doing. The exception are network drivers to allow for failsafe mode to work and provide SSH access **before** any modules are loaded. > > > > > > Some Modest Virtualization Observations > > > > How is this related? Virtualization (with OpenWrt being the guest) > > matters on x86 which is usually not that space-constraint. > > And maybe armvirt. If space is a problem for older x86 boards, let's > > disable guest support in x86/legacy. > > It was a broad example without any explanation. What caught my attention > there is the configuration of the kernel that causes problems, if I > understand correctly. > > > > > > Contribute defconfigs and all the devicetrees on OpenWrt to Linux. > > > > For devicetrees this would of course be desirable, but also implies a > > lot of work and discussions. If you are up to get it started (ie. setup > > a tree to collect cleaned-up and ready to submit dts), I think it would > > be worth the effort, at least for more recent targets/SoCs. > > I've been meaning to do this for the mt7621 SoC devices for months. The main > roadblock is that some drivers are out-of-tree, like the NAND flash so it > makes no sense to have them defined on the devicetree. Getting the > out-of-tree patches on mainline Linux is another step so it'll happen > eventually. Hm, I thought that Weijie had sent the mt7621-nand driver also upstream, but I haven't been following the process... > > I'll get this started with my Linux fork on GitHub. Very nice, I will join in there. > > > > > Regarding defconfigs I don't think we need an individual defconfig for > > each board. The problem here is also that OpenWrt currently has a layered > > approach (generic->target->subtarget) a
Re: OpenWrt Next Generation Ideas
Hi! On Fri, Mar 31, 2023 at 12:44:12PM +0300, Arınç ÜNAL wrote: > Hi all, > > These are the ideas I've been thinking about for the future of OpenWrt for a > while. It looks complete enough to share it with all of you. > > I'm willing to put a great deal of effort to get as much out-of-tree patches > on mainline Linux as possible. > > You can make a comment on Notion or discuss it here, I'm wondering if the > ideas are feasible and how well it would benefit the people maintaining > OpenWrt. > > https://arinc9.notion.site/OpenWrt-next-gen-ideas-6db745e7584b4823950291c96f2326bb I will comment here, I don't have an account on Notion and it seems to be required to be able to comment there. > defconfig for each device instead of config for each (sub)target. Given that we support thousands of devices this will not only increase the time needed to build a release or snapshot by several magnitudes, but also make debugging **much** harder. As of now, all devices of a subtarget are using the same kernel, hence e.g. symbol offsets in a kernel stack dump match for all of them. To reproduce or investigate a problem it's hence enough to have similar hardware, not necessarily the exact same board. As we are already lacking testers and maintainers for the relatively small amount of targets/subtargets, have a build for each board would make things much worse... Per-device builds would also be an invitation to downstream users to introduce device-specific (kernel-)hacks. If you want that, better go for OpenEmbedded. We can modularize things more or even have more sub-targets if it's really needed to save space. The disadvantages outweight the advantages imho when it comes to having a complete kernel build for each device. > Some Modest Virtualization Observations How is this related? Virtualization (with OpenWrt being the guest) matters on x86 which is usually not that space-constraint. And maybe armvirt. If space is a problem for older x86 boards, let's disable guest support in x86/legacy. > Contribute defconfigs and all the devicetrees on OpenWrt to Linux. For devicetrees this would of course be desirable, but also implies a lot of work and discussions. If you are up to get it started (ie. setup a tree to collect cleaned-up and ready to submit dts), I think it would be worth the effort, at least for more recent targets/SoCs. Regarding defconfigs I don't think we need an individual defconfig for each board. The problem here is also that OpenWrt currently has a layered approach (generic->target->subtarget) approach while Linux itself has a flat approach, and using that would result in a lot of duplication, which would in turn make keeping all those defconfigs up-to-date quite a lot of work... > Either submit all out-of-tree patches on OpenWrt to Linux or get rid > of them and find a better solution for what the unacceptable patch > does. This would of course be great, but especially for legacy devices it may not be possible in many cases. Think of all the devices stuck on swconfig, just to name one example... Think of all the completely broken vendor bootloaders which require hacks (mangeling kernel cmdline and such) and cannot easily be replaced... > Bugfix backporting should happen only after it's accepted to Linux. > The patch must be identical to the commit on Linux. The wording here might be a bit too strict to support our existing mess, but I generally agree. So I'd say 'should' instead of 'must', but otherwise agree. > Feature backporting should be done only if it's thoroughly tested. ... and testing often happens in the OpenWrt tree. So it's a bit of a chicken-egg problem, as often developers don't even have all the different hardware needed for testing. But generally I agree. A way to ease testing *before* pushing to openwrt.git or posting to upstream mailing lists would be to have snapshot builds also for developers' staging trees. > Kernel Solution > Make a mode menu. > Filesystem only. So which kernel headers should be used to build e.g. libc and netlink users? In a way it is also currently possible to build generic images for most architectures using the armvirt, malta and x86 targets. Of course, also in this case a kernel is being built. > Make a kernel selection menu where the user can choose to feed the > kernel directory of their own or use the longterm one defined on the > OpenWrt SDK. Add this as a suboption to the full image mode. What about CONFIG_EXTERNAL_KERNEL_TREE and friends...? ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [iwinfo PATCH] devices: add support for declaring compatible matched devices
On Mon, Jan 09, 2023 at 07:44:34PM +0100, Andre Heider wrote: > On 09/01/2023 18:28, Christian Marangi wrote: > > From: Jo-Philipp Wich > > > > Some device have embedded wifi card that are not connected with usb or > > internall with pci. Such device have fake device_id and only the > > vendor_id actually reflect something real but internally they don't have > > any id and are just matched by the node compatible binding in DT. > > Nice cleanup! But those fake entries in devices.txt can then be removed, > right? (Assuming all of those _are_ fake and not mapped to actual pci ids) Yes, they are all fake and actual PCI hardware with these IDs doesn't exist. Hence they should be removed. ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] iwinfo: devices: add Qualcomm Atheros QCN6024/9024/9074 cards
On Fri, Jan 06, 2023 at 05:32:48PM +0100, Robert Marko wrote: > On Fri, 6 Jan 2023 at 17:31, Christian Marangi wrote: > > > > On Fri, Jan 06, 2023 at 05:14:37PM +0100, Robert Marko wrote: > > > Add Qualcomm Atheros QCN6024/9024/9074 PCI ID, they all are compatible and > > > use the same ID. > > > > > > Signed-off-by: Robert Marko > > > > Hi, > > can you send a v2 with the iwinfo from the title dropped? > > > > Something like [iwinfo PATCH] devices: ... > > > > Just notice the different naming convention. > > Sure, but its a bit weird to send iwinfo patches to OpenWrt mailing > list without a prefix > of subproject? better to have that subproject name it in brackets, as in that way it doesn't end up as a prefix in the git commit (where it is useless -- all commits in iwinfo repo are related to iwinfo, obviously...) and yet allows us to use `git am` to merge it without having to edit. > > Regards, > Robert > > > > > --- > > > devices.txt | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/devices.txt b/devices.txt > > > index bc0257c..d76bbca 100644 > > > --- a/devices.txt > > > +++ b/devices.txt > > > @@ -173,6 +173,7 @@ > > > 0x168c 0x0046 0x168c 0xcafe0 0 "Qualcomm Atheros" "QCA9984" > > > 0x168c 0x0050 0x 0x0 0 "Qualcomm Atheros" "QCA9887" > > > 0x168c 0x0056 0x 0x0 0 "Qualcomm Atheros" "QCA9886" > > > +0x17cb 0x1104 0x17cb 0x11040 0 "Qualcomm Atheros" > > > "QCN6024/9024/9074" > > > 0x1814 0x3050 0x1814 0x00050 0 "Ralink" "Rt3050" > > > 0x1814 0x3051 0x1814 0x00070 0 "Ralink" "Rt3051" > > > 0x1814 0x3052 0x1814 0x00080 0 "Ralink" "Rt3052" > > > -- > > > 2.39.0 > > > > > > > > > ___ > > > openwrt-devel mailing list > > > [email protected] > > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > > > > -- > > Ansuel > > ___ > openwrt-devel mailing list > [email protected] > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: question to block mount/umount
On Wed, Dec 14, 2022 at 07:00:40PM -0800, B wrote: > On 12/14/22 05:45, e9hack wrote: > > Hi, > > > > I'm build OpenWrt with additional sub directories in /mnt. > > /etc/config/fstab contains an entry, to mount an usb drive to /mnt/1. If > > I execute 'block umount', the usb drive will be unmount and the > > subdirectory 1 in /mnt will be removed. Removing of the sub directory, > > is this the expected behaviour? > > This is not the way the mount command typically works on most unix-like > systems. In that respect, it's unexpected. You are not wrong to be perturbed > here. If that's what you want to do, OpenWrt will act just like any other UNIX-like system out there. Just use the 'mount' and 'umount' commands then, you may also use /etc/fstab, of course. OP was asking about the 'block umount' command, which is anyway specific to OpenWrt, and used for specific use-cases such as automatically creating mountpoints, automatically mounting devices on insertion, unmounting them on removal, ... It is configured in /etc/config/fstab (and *not* /etc/fstab). > Why OpenWRT needs to be different is for someone else to explain, because I > don't know. Also with regard to top-posting OpenWrt is not that different from most other UNIX-related communities. Just don't do it ;) ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Upstreaming mac80211 patches?
On Wed, Dec 14, 2022 at 06:04:40PM +0100, Nick wrote: > Lately, I had to look at some mac80211 patches and I did not understand why > some patches are still present or not upstreamed. What about upstreaming > some of the mac80211 patches or removing some? > For example "120-cfg80211_allow_perm_addr_change.patch" from 2014 I did not > find it on typical mailinglist > (https://github.com/openwrt/openwrt/blob/master/package/kernel/mac80211/patches/subsys/120-cfg80211_allow_perm_addr_change.patch)? > For ath9k we have 28 patches. Some of them are only for changing "channel > bandwidth to 5/10" (so not 20 or 40 bw included). I guess that is legacy? > https://github.com/openwrt/openwrt/commit/9f38d4402bede0c35bb8f4814e577dc0b0a2f184 IEEE 802.11 standard originally intended also operating on 5 MHz and 10 MHz wide channels. However, in Linux mac80211 doesn't handle those more narrow channels. As ath5k and ath9k hardware does support this, we have patches to allow using 5 MHz and 10 MHz channels in a non-standard way. While this is most likely not acceptable for upstream, it is still very useful as the possible link distance is (naturally) improved quite a lot when using 10 MHz or even 5 MHz channel bandwidth. Hence this is popular among amateur radio hams, for example. > And some were rejected upstream > (https://github.com/openwrt/openwrt/blob/master/package/kernel/mac80211/patches/ath9k/354-ath9k-force-rx_clear-when-disabling-rx.patch): > https://patchwork.kernel.org/project/linux-wireless/patch/[email protected]/ > > These are just some examples. However, I think it would be beneficial to get > closer to upstream mac80211 again? Help with cleaning and (re-)submitting patches upstream is for sure always welcome ;) Now that nvmem framework is ready and afaik we got rid of all pre-DTS platform_data users, many of the MTD EEPROM and MAC address hacks could be re-implemented using nvmem cells (and then get closer to being acceptable upstream). ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: question to block mount/umount
On Wed, Dec 14, 2022 at 02:45:02PM +0100, e9hack wrote: > Hi, > > I'm build OpenWrt with additional sub directories in /mnt. /etc/config/fstab > contains an entry, to mount an usb drive to /mnt/1. If I execute 'block > umount', the usb drive will be unmount and the subdirectory 1 in /mnt will be > removed. Removing of the sub directory, is this the expected behaviour? If the directoty is empty, then yes, this is the expected behavior. See https://git.openwrt.org/?p=project/fstools.git;a=blob;f=block.c;h=4b45200ad3812f5b79bda5d53c72a13ca5e92636;hb=HEAD#l1225 In case you'd like to keep it, simply have a 0 byte file in the directory (ie. `touch /mnt/1/.keep`), this will prevent rmdir() from succeeding and will result in the directory being kept after 'block umount'. ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Ethernet switch with linux/openwrt and DSA
On Tue, Dec 13, 2022 at 11:17:49AM +0100, Janusz Dziedzic wrote: > Hello, > > Do you know any/some ethernet switch project (best 18+ gbps ports) > that using linux/openwrt and DSA architecture? Some switches with high port density currently supported by OpenWrt: * TP-Link SG2452P * ZyXEL GS1900-48 * Panasonic Switch-M48eG PN28480K All of the above are using RealTek RTL839x platform. Cheers Daniel ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] px5g-mbedtls error check
Hi Peter,
thank you for pointing this out and submitting a patch.
On Mon, Dec 05, 2022 at 02:03:48PM -0500, Peter Naulls wrote:
>
>
> In 22.03, px5-mbedtls isn't bothering to check if the output was opened:
You patch lacks a Signed-off-by: line in the end of the patch
description.
>
> --- a/package/utils/px5g-mbedtls/px5g-mbedtls.c
> +++ b/package/utils/px5g-mbedtls/px5g-mbedtls.c
> @@ -29,6 +29,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -70,6 +71,11 @@ static void write_file(const char *path, int len, bool pem)
> if (path)
> f = fopen(path, "w");
>
> +if (!f) {
> + fprintf(stderr, "Failed to open output '%s': %s\n", path,
> strerror(errno));
> + exit(1);
> +}
> +
> fwrite(buf_start, 1, len, f);
> fclose(f);
> }
Unfortunately your mail user agent has mangled the tabs into 4 spaces
which results in the patch no longer applying:
warning: Patch sent with format=flowed; space at the end of lines might be lost.
Applying: px5g-mbedtls error check
error: patch failed: package/utils/px5g-mbedtls/px5g-mbedtls.c:70
error: package/utils/px5g-mbedtls/px5g-mbedtls.c: patch does not apply
Patch failed at 0001 px5g-mbedtls error check
hint: Use 'git am --show-current-patch=diff' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
...
To avoid problems like that, please use 'git send-email' or at least
'git format-patch' to submit the patch. If using a specific graphical
or web mail user agent cannot be avoided at all, as a last resort it is
also ok to send patches generated using 'git format-patch' as an
attachment.
To be consistent in style it would also be better to change the patch
subject to "px5g-mbedtls: add error check" or something like that.
Cheers
Daniel
___
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] linux: add in labels for block2mtd
On Tue, Nov 29, 2022 at 12:05:51PM -0500, Peter Naulls wrote: > On 11/29/22 11:50, Daniel Golle wrote: > > > > > There is nothing wrong with that use-case, and it can even be > > interesting for other downstream users. Encrypted rootfs_data is > > generally a good idea, especially when rootfs_data is used to store > > private key material (think: VPN keys) or other kind of credentials. > > > > I was more wondering why you are using JFFS2 on a block device, instead > > of e.g. using F2FS or EXT4 which are intended for block devices. > > Our flash is NOR. We will probably move to NAND in the next iteration of > hardware, but this is what we have for now. > > I'm open to other ways to make it work, but this is the arrangement that > I was able to make work in my research and testing, and that a colleague > used successfully on a non-OpenWrt system. Ok, that makes sense then. So basically you are basically using mtd->mtdblock->cryptsetup/luks->block2mtd->jffs2 I thought you are on a device with actual block storage. For your case I also can't come up with anything better which works out-of-the-box for NOR flash. Supporting fscrypt in JFFS2 would be more elegant, but that's a bit more demanding than just using what is already there and works... ___ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
