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 openwrt-devel@lists.openwrt.org 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 openwrt-devel@lists.openwrt.org 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 openwrt-devel@lists.openwrt.org 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/s in 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 openwrt-devel@lists.openwrt.org 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 >openwrt-devel@lists.openwrt.org >https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 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.
> >>
> >> I'm willing to do the legwork, and I can
[PATCH] Fix has_better_load evaluation
Fixes two bugs:
1) if condition in is_better_candidate previously always evaluated to false.
2) below_load_threshold actually implemented above_load_threshold
Signed-off-by: Daniel Albers
---
policy.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/policy.c b/policy.c
index 8c5d244..632cd47 100644
--- a/policy.c
+++ b/policy.c
@@ -55,7 +55,7 @@ better_signal_strength(int signal_cur, int signal_new)
}
static bool
-below_load_threshold(struct usteer_node *node)
+above_load_threshold(struct usteer_node *node)
{
return node->n_assoc >= config.load_kick_min_clients &&
node->load > config.load_kick_threshold;
@@ -64,7 +64,7 @@ below_load_threshold(struct usteer_node *node)
static bool
has_better_load(struct usteer_node *node_cur, struct usteer_node *node_new)
{
- return !below_load_threshold(node_cur) &&
below_load_threshold(node_new);
+ return above_load_threshold(node_cur) &&
!above_load_threshold(node_new);
}
bool
@@ -107,8 +107,7 @@ is_better_candidate(struct sta_info *si_cur, struct
sta_info *si_new)
if (better_signal_strength(current_signal, new_signal))
reasons |= (1 << UEV_SELECT_REASON_SIGNAL);
- if (has_better_load(current_node, new_node) &&
- !has_better_load(current_node, new_node))
+ if (has_better_load(current_node, new_node))
reasons |= (1 << UEV_SELECT_REASON_LOAD);
return reasons;
--
2.39.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[usteer] Fix has_better_load evaluation
Fixes two bugs:
1) if condition in is_better_candidate previously always evaluated to false.
2) below_load_threshold actually implemented above_load_threshold
Fixes #5
---
policy.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/policy.c b/policy.c
index 8c5d244..632cd47 100644
--- a/policy.c
+++ b/policy.c
@@ -55,7 +55,7 @@ better_signal_strength(int signal_cur, int signal_new)
}
static bool
-below_load_threshold(struct usteer_node *node)
+above_load_threshold(struct usteer_node *node)
{
return node->n_assoc >= config.load_kick_min_clients &&
node->load > config.load_kick_threshold;
@@ -64,7 +64,7 @@ below_load_threshold(struct usteer_node *node)
static bool
has_better_load(struct usteer_node *node_cur, struct usteer_node *node_new)
{
- return !below_load_threshold(node_cur) &&
below_load_threshold(node_new);
+ return above_load_threshold(node_cur) &&
!above_load_threshold(node_new);
}
bool
@@ -107,8 +107,7 @@ is_better_candidate(struct sta_info *si_cur, struct
sta_info *si_new)
if (better_signal_strength(current_signal, new_signal))
reasons |= (1 << UEV_SELECT_REASON_SIGNAL);
- if (has_better_load(current_node, new_node) &&
- !has_better_load(current_node, new_node))
+ if (has_better_load(current_node, new_node))
reasons |= (1 << UEV_SELECT_REASON_LOAD);
return reasons;
--
2.45.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
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 platforms. Just my 2 cents... ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org 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
openwrt-devel@lists.openwrt.org
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, st...@linux-ipv6.be 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
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One / 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 > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One / 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 [ > ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails > [ > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One / 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
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
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 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 --stat > > oldtag..newtag' doesn't take much more time than
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_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 openwrt-devel@lists.openwrt.org 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
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/xz-devel@tukaani.org/msg00567.html ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org 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
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 > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 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 openwrt-devel@lists.openwrt.org 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 openwrt-devel@lists.openwrt.org 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: openwrt-devel@lists.openwrt.org > 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 > >openwrt-devel@lists.openwrt.org > >https://lists.openwrt.org/mailman/listinfo/openwrt-devel > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org 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 openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: makefile debugging
On 1/18/24 12:01, Tim Harvey wrote: Greetings, I seem to recall a way to ask OpenWrt's build system to output a list of all variable values used in the build but can't find it documented or in my notes. Does anyone know how to do that? Also, is there a way to output a post-processed Makefile after all the define foo gets done? I find it pretty difficult to work through the build system, especially when working with images. Best Regards, Tim This is what I use for variables. I don't know if there's a way to get a post-processed Makefile -- that could be helpful, but also sounds like a bear to parse. $(foreach v, \ $(shell echo "$(filter-out .VARIABLES,$(.VARIABLES))" | tr ' ' '\n' | sort), \ $(info /tmp/make_vars,$(shell printf "%-20s" "$(v)")= $(value $(v))) \ ) Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
On 1/18/24 10:37, Chuanhong Guo wrote: MT7981 is such a chip with NAT offload capability, and the flow-offload driver mentioned in other threads is actually a driver for this hardware block. Since it's a cost-down MT7986 I would imagine this particular feature is the same between them: HW NAT − Etherent/WiFi − Wired speed − IPv4 routing, NAT, NAPT − IPv6 routing, DS-Lite, 6RD I can't find an MT7981 / Filogic 820 datasheet anywhere, but apparently MediaTek was nice enough to put out a public release for the MT7986 / Filogic 820 for the Banana Pi R3. Anybody know what the differences are? Could it just be quad vs dual core? I'm also wondering if MediaTek could be convinced to make a public release of the MT7981B for this project. To work on any MediaTek SoCs, if feels like you have to be an expert in all of them to know what microcode they're reusing for each component (peripheral interfaces, etc.) from one chip to the next, and thus the registers and behavior that had been previously published in a some other programmer's manual. It's a strange world to me. Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
On 1/16/24 00:36, John Crispin wrote: And in the interest of running *my* own mouth, I'm stoked as hell -- LOVE that it will have mikroBUS! Thanks to John and everyone working on this! My only request is that any unused gpios that don't make it to mikroBUS find their way to a (possibly unpopulated) header some where for the sake of hackability. 1mm pitch is fine. I've had more than one occasion where I wanted to add something and didn't have the bus or I/O lines and then discovered that the MCU did, but they were all N/C. Hackability is what makes the FOSS / open hardware world so awesome.\! Daniel yeah we will add all remaining GPIO togehter with GND and 3,3V on a 2.54mm header. HELL YES! Even better! Even though it's on mikroBUS, maybe export the reset line on header as well? Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
On Wed, Jan 17, 2024 at 05:47:26PM +0100, John Crispin wrote: > > On 17.01.24 17:46, Janusz Dziedzic wrote: > > Do you think I can use m.2 A->M converter here and use wifi mt7916 A+E > > (6GHz) instead of NVMe? > > Eg.https://kamami.pl/akcesoria-do-raspberry-pi/587051-m2-m-key-to-m2-a-key-adapter-m2-m-key-do-m2-a-key.html > > Will that work? > > so the theory but we wont know until we try. I've tried that on BPi-R3 with MT7921K module, and that worked fine. I don't see a reason why it wouldn't work on a very similar MediaTek SoC -- we just need to make sure the power budget of the M.2 slot is enough for even WiFi modules more power hungry than MT7921K (I assume MT7916E wants quite a bit more juice). ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
On 1/15/24 06:56, Paul D wrote: A kickstarter is a good way to forecast demand. You've captured the imagination of the geek community. Not aware of peripheral issues or complexities in doing a kickstarter, though I agree with forecasting demand. "Geeks" are good at commenting on stuff, and intellectualizing a new board: let's see how many put their money where their mouth is. And in the interest of running *my* own mouth, I'm stoked as hell -- LOVE that it will have mikroBUS! Thanks to John and everyone working on this! My only request is that any unused gpios that don't make it to mikroBUS find their way to a (possibly unpopulated) header some where for the sake of hackability. 1mm pitch is fine. I've had more than one occasion where I wanted to add something and didn't have the bus or I/O lines and then discovered that the MCU did, but they were all N/C. Hackability is what makes the FOSS / open hardware world so awesome.\! Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
On 1/10/24 08:18, Forest Crossman wrote: On Tue, Jan 9, 2024 at 4:52 AM John Crispin wrote: ---SNIP--- * Why is there no USB 3.x host port on the device? - the USB 3.x and PCIe buses are shared in the selected SoC silicon, hence only a single High-Speed USB port is available Perhaps you've already considered this, but it may be possible to route the shared PCIe/USB 3 traces to both an M.2 slot and a USB 3 host port using a high-speed dual-channel differential 1:2/2:1 switch/mux. It wouldn't enable both interfaces to be used at the same time, but it would make it possible to select which interface is enabled using a GPIO pin. Then U-boot could either automatically enable one port or the other depending on what devices it detects (e.g., enable PCIe and disable USB 3 if a PCIe device is connected, otherwise enable USB 3 and disable PCIe), or it could be statically configurable via a U-boot environment variable. From some quick searching, the switches/muxes that would enable this cost less than $1 each in qty. 1000. For a <$100 product I understand that may be too much of an increase to the BoM cost and PCB complexity, but I think users would really appreciate being able to choose between being able to add an M.2 SSD, WiFi card, or SATA controller and being able to plug in a USB 3.x 2.5 GbE adapter, SSD/flash drive, WiFi dongle, or 5G modem. All the best, Forest I'm always a fan of a single PCB design that *can* be built in different configurations. So would suggest a design where differential mux can be left unpopulated to create a product w/o USB 3 support. But of course, this doesn't overcome EMI concerns Daniel Golle mentioned. Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
Hi! On Wed, Jan 10, 2024 at 11:47:08AM +0100, Bjørn Mork wrote: > John Crispin writes: > > > At the beginning we focused on the most powerful (and > > expensive) configurations possible but finally ended up with something > > rather simple and above all,feasible. > > That's a very wise choice. And most of the compromises make sense to > me. Except the > > > * Storage: M.2 2042 for NVMe SSD (PCIe gen 2 x1) > > This seems like a strange priority for an OpenWrt device. It's not > useful to most OpenWrt users or applications. Having two different boot > devices is more than enough. > > > * What will the M.2 slot be used for? > > - we will use M.2 with M-key for NVMe storage. There is a > > work-in-progress patch to make PCIe work inside the U-Boot > > bootloader. This will allow booting other Linux distributions such > > as Debian and Alpine directly from NVMe > > And you even make a point of it being more suitable for other Linux > distros. That should not be an OpenWrt priority. > > > * Why is there no USB 3.x host port on the device? > > - the USB 3.x and PCIe buses are shared in the selected SoC silicon, > > hence only a single High-Speed USB port is available > > And here's the biggest problem with that choice. USB3 would have > allowed storage expansion as well as more OpenWrt applicable use cases > like additional ethernet adapters or modems. And with a limited > connector and board space cost compared to an m.2 slot. The USB A > port is already there. Regarding all of the above: exposing the PCIe lane gives you the biggest possible flexibility. If you want USB 3 you can use an adapter like this: https://www.delock.com/produkt/63174/merkmale.html Including USB 3 will significantly increase the cost of the design not because of connectors, but because of the interference problems we will have to deal with and somehow mitigate (and the smaller the board the harder that will get). I've seen too many devices with such problems and only very few manage to have well-working 2.4 GHz Wi-Fi next to a USB 3 host. > > > * What is the purpose of the console USB-C port? > > - Holtek UART to USB bridge with CDC-ACM support on USB-C makes the > > device ultra easy to communicate with. No extra hardware or drivers > > will be required. Android for example has CDC-ACM support enabled by > > default > > This is nice. But how about making it a real advantage over the > traditional 4 pin header? You could have used a UART bridge with some > additional GPIO pins, and connected them to useful SoC IOs. Possibly > via some mux. I'd love to see reset and bootsel controlled by the USB > UART bridge. Good point. That would also make it more accessible and easy automated testing a lot. > > Ideally we would have a more advanced USB bridge with open source > firmware and more than one USB function. But I guess that adds a lot of > complexity to the project. Reusing/abusing RS232 control signals is an > alternative. > > Finally, I'd prefer a much more compact board than the BPi-R4 size. > > Along with a well designed minimalistic case with sufficient passive > cooling and optional integrated antennas. Thinking something along the > Flirc RPi4 cases, using the case itself as a cooler. With half the case > radio transparent and a choice between antenna pigtails and integrated > antennas. I realize that such a case will be relatively expensive. But > without it all you have is yet another midrange dev board. This is your > chance to make a device which shouts "OpenWrt!!!" whenever someone sees > it. Just like the original WRT did. Not that that design was something > to brag about beauty wise :-) I also think we should should have a pre-assembled-with-case-and-antennas option in addition to just offering the plain board. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
On Tue, Jan 09, 2024 at 06:49:04PM +0100, Janusz Dziedzic wrote: > wt., 9 sty 2024 o 18:02 Robert Marko napisał(a): > > > > On Tue, 9 Jan 2024 at 17:53, Rafał Miłecki wrote: > > > > > > On 9.01.2024 13:29, John Crispin wrote: > > > > On 09.01.24 12:56, Robert Marko wrote: > > > >> ---SNIP--- > > > >> > > > >>> Why not 6GHz? > > > >> 6GHz requires an external card, and I doubt you can fit that in the > > > >> target price. > > > >> > > > >> Regards, > > > >> Robert > > > > > > > > correct. as mentioned in the email, we wanted to start out small. also > > > > upstream mac80211 is still missing a bunch of 11be related features. > > > > > > 6 GHz doesn't imply 802.11be, does it? I'm really not sure. > > > > > > Does MediaTek have any 802.11ax solutions that cover both: 5 GHz and > > > 6 GHz? Maybe it'd be worth checking if that's an option and then use > > > voting to see if people care? > > > > You can use 6GHz as part of 802.11ax as well, but you need an external card > > or > > you need to sacrifice the built-in 5GHz for 6GHz and that isn't really > > a good idea > > in my opinion. > > > Even will be 150$ it is still good price for router with 2.4/5/6GHz > (MTK base ACER predator W6 is about 200$). > Or at least add extra m2 AE Key slot - then we can put there mt7916 > card, as possible extension (eg. > https://asiarf.com/product/wi-fi-6e-m-2-ae-key-module-mt7916-aw7916-aed/). > What will be price in case of this extra m2 AE Key slot? You can use M.2 key adapters for that https://www.delock.com/produkt/63343/merkmale.html An additional slot is *not* an option as we got only a single PCIe lane. Hopefully there are also going to be single-band (6 GHz only) 4T4R or even 4T5R modules based on MT7916E available at some point... ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
On Tue, Jan 09, 2024 at 05:52:57PM +0100, Rafał Miłecki wrote: > On 9.01.2024 13:29, John Crispin wrote: > > On 09.01.24 12:56, Robert Marko wrote: > > > ---SNIP--- > > > > > > > Why not 6GHz? > > > 6GHz requires an external card, and I doubt you can fit that in the > > > target price. > > > > > > Regards, > > > Robert > > > > correct. as mentioned in the email, we wanted to start out small. also > > upstream mac80211 is still missing a bunch of 11be related features. > > 6 GHz doesn't imply 802.11be, does it? I'm really not sure. You are right, 6 GHz does *not* imply 802.11be. 802.11ax with HE rates is sufficient. However, as one is not supposed to send beacons or do actice scanning on the 6 GHz band (simply because there are too many channels...) you would need MBO features to inform clients about 6 GHz AP being available, and that doesn't yet work very well (due to missing mac80211, cfg80211 and hostapd features afaik). > > Does MediaTek have any 802.11ax solutions that cover both: 5 GHz and > 6 GHz? Maybe it'd be worth checking if that's an option and then use > voting to see if people care? Afaik the only reasonable way to implement tri-band 2.4G + 5G + 6G using MTK SoCs is to use the in-SoC WiFi MAC to connect an MT7976A frontend and use that for 2.4 GHz and 6 GHz, and then put an additional MT7915E connected via PCIe for the 5 GHz band. The only tri-band device I know is Adtran's SmartRG SDG-8632. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
On Tue, Jan 09, 2024 at 12:56:55PM +0100, Robert Marko wrote: > ---SNIP--- > > > Why not 6GHz? > > 6GHz requires an external card, and I doubt you can fit that in the > target price. Afaik we could use MT7976A as DBDC front-end supporting 2.4 GHz + 5/6 GHz instead of MT7976C which only supports 2.4 GHz + 5 GHz. However, that would still cover only two bands and most people will want 6 GHz *in addition* to the 5 GHz band and not instead. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 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 > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [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 {
> + stdout-path = "seria
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 =
> + led-boot = _status_blue;
> + led-running = _status_green;
> + led-upgrade = _status_red;
> + led-failsafe = _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 = < 7 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led_status_red: led-0 {
> + function = LED_FUNCTION_STATUS;
> + color = ;
> + gpios = < 18 GPIO_ACTIVE_HIGH>;
> + };
> +
> + led_status_green: led-1 {
> + function = LED_FUNCTION_STATUS;
> + color = ;
> + gpios = < 19 GPIO_ACTIVE_HIGH>;
> + };
> +
> + led_status_blue: led-2 {
> + function = LED_FUNCTION_STATUS;
> + color = ;
> + gpios = < 20 GPIO_ACTIVE_HIGH>;
> + };
> + };
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + 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",
> + "WF1_HB2", "WF1_HB3",
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). 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 openwrt-devel@lists.openwrt.org 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 openwrt-devel@lists.openwrt.org 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 (| ehem+sig...@m5p.com PGP 87145445 |) /
> > \_CS\ | _ -O #include O- _ | / _/
> > 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
> >
> >
> >
> > ___
> > openwrt-devel mailing list
> > openwrt-devel@lists.openwrt.org
> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] mt76: Add firmware package for MT7922
Adds the 2 required firmware files for MT7922 chips. Signed-off-by: Daniel Danzberger --- package/kernel/mt76/Makefile | 14 ++ 1 file changed, 14 insertions(+) diff --git a/package/kernel/mt76/Makefile b/package/kernel/mt76/Makefile index cc8221d7ce..dd75390ee7 100644 --- a/package/kernel/mt76/Makefile +++ b/package/kernel/mt76/Makefile @@ -262,6 +262,11 @@ define KernelPackage/mt7921-firmware TITLE:=MediaTek MT7921 firmware endef +define KernelPackage/mt7922-firmware + $(KernelPackage/mt76-default) + TITLE:=MediaTek MT7922 firmware +endef + define KernelPackage/mt792x-common $(KernelPackage/mt76-default) TITLE:=MediaTek MT792x wireless driver common code @@ -597,6 +602,14 @@ define KernelPackage/mt7921-firmware/install $(1)/lib/firmware/mediatek endef +define KernelPackage/mt7922-firmware/install + $(INSTALL_DIR) $(1)/lib/firmware/mediatek + cp \ + $(PKG_BUILD_DIR)/firmware/WIFI_MT7922_patch_mcu_1_1_hdr.bin \ + $(PKG_BUILD_DIR)/firmware/WIFI_RAM_CODE_MT7922_1.bin \ + $(1)/lib/firmware/mediatek +endef + define Package/mt76-test/install mkdir -p $(1)/usr/sbin $(INSTALL_BIN) $(PKG_BUILD_DIR)/tools/mt76-test $(1)/usr/sbin @@ -630,6 +643,7 @@ $(eval $(call KernelPackage,mt7916-firmware)) $(eval $(call KernelPackage,mt7981-firmware)) $(eval $(call KernelPackage,mt7986-firmware)) $(eval $(call KernelPackage,mt7921-firmware)) +$(eval $(call KernelPackage,mt7922-firmware)) $(eval $(call KernelPackage,mt792x-common)) $(eval $(call KernelPackage,mt792x-usb)) $(eval $(call KernelPackage,mt7921-common)) -- 2.42.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org 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
openwrt-devel@lists.openwrt.org
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,
> +- >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 openwrt-devel@lists.openwrt.org 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]);
> ++
[PATCH] umbim: Add mbim message timeout option, -T
Some modems, depending on their state and connection quality can take
longer than 15 seconds to answer mbim message requests.
This commit adds the -T option, allowing the user to specifiy a custom
message timeout in seconds.
Default is still 15.
Signed-off-by: Daniel Danzberger
---
cli.c | 9 +++--
mbim-dev.c | 2 +-
mbim.h | 1 +
3 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/cli.c b/cli.c
index 3a845d4..6026a67 100644
--- a/cli.c
+++ b/cli.c
@@ -35,6 +35,7 @@
int return_code = -1;
int verbose;
+int msg_timeout_ms = 15 * 1000;
struct mbim_handler *current_handler;
static uint8_t uuid_context_type_internet[16] = { 0x7E, 0x5E, 0x2A, 0x7E,
0x4E, 0x6F, 0x72, 0x72, 0x73, 0x6B, 0x65, 0x6E, 0x7E, 0x5E, 0x2A, 0x7E };
@@ -533,7 +534,8 @@ usage(void)
#endif
"-d the device (/dev/cdc-wdmX)\n"
"-tthe transaction id\n"
- "-n no close\n\n"
+ "-n no close\n"
+ "-TMBIM message timeout in seconds
[15]\n\n"
"-v verbose\n\n");
return 1;
}
@@ -548,7 +550,7 @@ main(int argc, char **argv)
int proxy = 0;
#endif
- while ((ch = getopt(argc, argv, "pnvd:t:")) != -1) {
+ while ((ch = getopt(argc, argv, "pnvd:t:T:")) != -1) {
switch (ch) {
case 'v':
verbose = 1;
@@ -563,6 +565,9 @@ main(int argc, char **argv)
no_open = 1;
transaction_id = atoi(optarg);
break;
+ case 'T':
+ msg_timeout_ms = atoi(optarg) * 1000;
+ break;
#ifdef LIBQMI_MBIM_PROXY
case 'p':
proxy = 1;
diff --git a/mbim-dev.c b/mbim-dev.c
index 2a94d49..12d1189 100644
--- a/mbim-dev.c
+++ b/mbim-dev.c
@@ -78,7 +78,7 @@ mbim_send(void)
perror("writing data failed: ");
} else {
expected = le32toh(hdr->type) | 0x8000;
- uloop_timeout_set(, 15000);
+ uloop_timeout_set(, msg_timeout_ms);
}
return ret;
}
diff --git a/mbim.h b/mbim.h
index 746257e..28999b5 100644
--- a/mbim.h
+++ b/mbim.h
@@ -20,6 +20,7 @@
extern int return_code;
extern int verbose;
+extern int msg_timeout_ms;
#include "mbim-type.h"
#include "mbim-enum.h"
--
2.40.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] umbim: Add mbim message timeout option, -T
On Wed, 2023-07-05 at 15:03 +, Eric wrote:
> On Wednesday, July 5th, 2023 at 06:08, Daniel Danzberger
> wrote:
> > Some modems, depending on their state and connection quality can take
> > longer than 15 seconds to answer mbim message requests.
> >
> > This commit adds the -T option, allowing the user to specifiy a custom
> > message timeout in seconds.
> >
> > Default is still 15.
> >
> > Signed-off-by: Daniel Danzberger dan...@dd-wrt.com
> >
> > ---
> > cli.c | 9 +++--
> > mbim-dev.c | 2 +-
> > mbim.h | 1 +
> > 3 files changed, 9 insertions(+), 3 deletions(-)
> >
> > diff --git a/cli.c b/cli.c
> > index 3a845d4..b23fc6d 100644
> > --- a/cli.c
> > +++ b/cli.c
> > @@ -35,6 +35,7 @@
> >
> > int return_code = -1;
> > int verbose;
> > +int msg_timeout_ms = 15 * 1000;
> >
> > struct mbim_handler *current_handler;
> > static uint8_t uuid_context_type_internet[16] = { 0x7E, 0x5E, 0x2A, 0x7E,
> > 0x4E, 0x6F, 0x72, 0x72, 0x73, 0x6B, 0x65, 0x6E, 0x7E, 0x5E, 0x2A, 0x7E
> > };
> > @@ -533,7 +534,8 @@ usage(void)
> > #endif
> > " -d the device (/dev/cdc-wdmX)\n"
> >
> > " -t the transaction id\n"
> >
> > - " -n no close\n\n"
> > + " -n no close\n"
> > + " -T MBIM message timeout in seconds [15]\n\n"
>
> Shouldn't the usage indicate explicitly that it takes a parameter, as do -d
> and -t?
>
> " -T MBIM message timeout...
Yes, makes sense.
>
> > " -v verbose\n\n");
> > return 1;
> > }
> > @@ -548,7 +550,7 @@ main(int argc, char **argv)
> > int proxy = 0;
> > #endif
> >
> > - while ((ch = getopt(argc, argv, "pnvd:t:")) != -1) {
> > + while ((ch = getopt(argc, argv, "pnvd:t:T:")) != -1) {
> > switch (ch) {
> > case 'v':
> > verbose = 1;
> > @@ -563,6 +565,9 @@ main(int argc, char **argv)
> > no_open = 1;
> > transaction_id = atoi(optarg);
> > break;
> > + case 'T':
> > + msg_timeout_ms = atoi(optarg) * 1000;
> > + break;
> > #ifdef LIBQMI_MBIM_PROXY
> > case 'p':
> > proxy = 1;
> > diff --git a/mbim-dev.c b/mbim-dev.c
> > index 2a94d49..12d1189 100644
> > --- a/mbim-dev.c
> > +++ b/mbim-dev.c
> > @@ -78,7 +78,7 @@ mbim_send(void)
> > perror("writing data failed: ");
> > } else {
> > expected = le32toh(hdr->type) | 0x8000;
> >
> > - uloop_timeout_set(, 15000);
> > + uloop_timeout_set(, msg_timeout_ms);
> > }
> > return ret;
> > }
> > diff --git a/mbim.h b/mbim.h
> > index 746257e..28999b5 100644
> > --- a/mbim.h
> > +++ b/mbim.h
> > @@ -20,6 +20,7 @@
> >
> > extern int return_code;
> > extern int verbose;
> > +extern int msg_timeout_ms;
> >
> > #include "mbim-type.h"
> > #include "mbim-enum.h"
> > --
> > 2.40.1
>
>
--
Regards
Daniel Danzberger
embeDD GmbH, Alter Postplatz 2, CH-6370 Stans
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] umbim: Add mbim message timeout option, -T
Some modems, depending on their state and connection quality can take
longer than 15 seconds to answer mbim message requests.
This commit adds the -T option, allowing the user to specifiy a custom
message timeout in seconds.
Default is still 15.
Signed-off-by: Daniel Danzberger
---
cli.c | 9 +++--
mbim-dev.c | 2 +-
mbim.h | 1 +
3 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/cli.c b/cli.c
index 3a845d4..b23fc6d 100644
--- a/cli.c
+++ b/cli.c
@@ -35,6 +35,7 @@
int return_code = -1;
int verbose;
+int msg_timeout_ms = 15 * 1000;
struct mbim_handler *current_handler;
static uint8_t uuid_context_type_internet[16] = { 0x7E, 0x5E, 0x2A, 0x7E,
0x4E, 0x6F, 0x72, 0x72, 0x73, 0x6B, 0x65, 0x6E, 0x7E, 0x5E, 0x2A, 0x7E };
@@ -533,7 +534,8 @@ usage(void)
#endif
"-d the device (/dev/cdc-wdmX)\n"
"-tthe transaction id\n"
- "-n no close\n\n"
+ "-n no close\n"
+ "-T MBIM message timeout in seconds
[15]\n\n"
"-v verbose\n\n");
return 1;
}
@@ -548,7 +550,7 @@ main(int argc, char **argv)
int proxy = 0;
#endif
- while ((ch = getopt(argc, argv, "pnvd:t:")) != -1) {
+ while ((ch = getopt(argc, argv, "pnvd:t:T:")) != -1) {
switch (ch) {
case 'v':
verbose = 1;
@@ -563,6 +565,9 @@ main(int argc, char **argv)
no_open = 1;
transaction_id = atoi(optarg);
break;
+ case 'T':
+ msg_timeout_ms = atoi(optarg) * 1000;
+ break;
#ifdef LIBQMI_MBIM_PROXY
case 'p':
proxy = 1;
diff --git a/mbim-dev.c b/mbim-dev.c
index 2a94d49..12d1189 100644
--- a/mbim-dev.c
+++ b/mbim-dev.c
@@ -78,7 +78,7 @@ mbim_send(void)
perror("writing data failed: ");
} else {
expected = le32toh(hdr->type) | 0x8000;
- uloop_timeout_set(, 15000);
+ uloop_timeout_set(, msg_timeout_ms);
}
return ret;
}
diff --git a/mbim.h b/mbim.h
index 746257e..28999b5 100644
--- a/mbim.h
+++ b/mbim.h
@@ -20,6 +20,7 @@
extern int return_code;
extern int verbose;
+extern int msg_timeout_ms;
#include "mbim-type.h"
#include "mbim-enum.h"
--
2.40.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
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
[PATCH] ramips: fix lzma-loader for ASIARF boards
This fixes a well known "LZMA ERROR 1" error, reported previously on numerous of similar devices. Signed-off-by: Daniel Danzberger --- target/linux/ramips/image/mt7621.mk | 2 ++ 1 file changed, 2 insertions(+) diff --git a/target/linux/ramips/image/mt7621.mk b/target/linux/ramips/image/mt7621.mk index 28f6fef681..d399787ffe 100644 --- a/target/linux/ramips/image/mt7621.mk +++ b/target/linux/ramips/image/mt7621.mk @@ -214,6 +214,7 @@ TARGET_DEVICES += arcadyan_we420223-99 define Device/asiarf_ap7621-001 $(Device/dsa-migration) + $(Device/uimage-lzma-loader) IMAGE_SIZE := 16000k DEVICE_VENDOR := AsiaRF DEVICE_MODEL := AP7621-001 @@ -223,6 +224,7 @@ TARGET_DEVICES += asiarf_ap7621-001 define Device/asiarf_ap7621-nv1 $(Device/dsa-migration) + $(Device/uimage-lzma-loader) IMAGE_SIZE := 16000k DEVICE_VENDOR := AsiaRF DEVICE_MODEL := AP7621-NV1 -- 2.39.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
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 openwrt-devel@lists.openwrt.org 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 > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Objective of OpenWRT/x86?
emory, 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 supported by Xen is quite limited. I suspect > > > the list for Hyper-V and VMware are similarly limited. > > > > > > Yet, each of these sets is disjoin
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 openwrt-devel@lists.openwrt.org 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
openwrt-devel@lists.openwrt.org
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
openwrt-devel@lists.openwrt.org
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: * All MIPS32 targets use either mips4k or mips2
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 replaced... > > > > Those can stay
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 of course be desirable, but also imp
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) approach while Linux itself has > > a flat approach, and usi
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 openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] ath79: Add support for Ubiquiti NanoBeam AC Gen2 XC
The Ubiquiti NanoBeam AC Gen2 XC (NBE-5AC-Gen2) is an outdoor 802.11ac CPE
with a waterproof casing (ultrasonically welded) and bulb shaped.
It's the same board as Gen1 but with a small antenna routed out of the SoC
and calibration data for this management radio in the "art" partition.
Hardware:
SoC:Qualcomm Atheros QCA9558
CPU:MIPS 74Kc V5.0 720 MHz, 1 core
RAM:128 MB DDR2
Flash: 16 MB SPI-NOR, MX25L12805D
Ethernet: 1x GbE
WiFi 5 GHz: Qualcomm Atheros QCA988X
WiFi 2.4 GHz: SoC (management radio)
Internal antenna 1: 19 dBi planar (5 GHz)
Internal antenna 2: 2 dBi PCB, connected via UFL (SoC)
Buttons:1x reset
LEDs: 1x power, 1x Ethernet, 4x RSSI, all blue
PSU:24 Vdc passive PoE
Installation from stock airOS firmware:
- Follow instructions for XC-type Ubiquiti devices on OpenWrt wiki at
https://openwrt.org/toh/ubiquiti/common
Back to stock firmware:
- Follow instructions for Ubiquiti recovery via TFTP at OpenWrt wiki.
Signed-off-by: Daniel González Cabanelas
---
.../dts/qca9558_ubnt_nanobeam-ac-gen2-xc.dts | 17 +++
.../ath79/dts/qca9558_ubnt_nanobeam-ac-xc.dts | 105 +
.../dts/qca9558_ubnt_nanobeam-ac-xc.dtsi | 107 ++
.../generic/base-files/etc/board.d/01_leds| 1 +
.../generic/base-files/etc/board.d/02_network | 2 +
.../etc/hotplug.d/firmware/11-ath10k-caldata | 1 +
target/linux/ath79/image/generic-ubnt.mk | 10 ++
7 files changed, 141 insertions(+), 102 deletions(-)
create mode 100644 target/linux/ath79/dts/qca9558_ubnt_nanobeam-ac-gen2-xc.dts
create mode 100644 target/linux/ath79/dts/qca9558_ubnt_nanobeam-ac-xc.dtsi
diff --git a/target/linux/ath79/dts/qca9558_ubnt_nanobeam-ac-gen2-xc.dts
b/target/linux/ath79/dts/qca9558_ubnt_nanobeam-ac-gen2-xc.dts
new file mode 100644
index 00..629b5bfe0a
--- /dev/null
+++ b/target/linux/ath79/dts/qca9558_ubnt_nanobeam-ac-gen2-xc.dts
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Device Tree file for Ubiquiti Nanobeam NBE-5AC-Gen2 (XC)
+ */
+
+#include "qca9558_ubnt_nanobeam-ac-xc.dtsi"
+
+/ {
+ compatible = "ubnt,nanobeam-ac-gen2-xc", "ubnt,xc", "qca,qca9558";
+ model = "Ubiquiti NanoBeam AC Gen2 (XC)";
+};
+
+ {
+ status = "okay";
+
+ mtd-cal-data = < 0x1000>;
+};
diff --git a/target/linux/ath79/dts/qca9558_ubnt_nanobeam-ac-xc.dts
b/target/linux/ath79/dts/qca9558_ubnt_nanobeam-ac-xc.dts
index 91675ff615..898c249154 100644
--- a/target/linux/ath79/dts/qca9558_ubnt_nanobeam-ac-xc.dts
+++ b/target/linux/ath79/dts/qca9558_ubnt_nanobeam-ac-xc.dts
@@ -1,110 +1,11 @@
-// SPDX-License-Identifier: GPL-2.0-only
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
/*
* Device Tree file for Ubiquiti Nanobeam NBE-5AC-19 (XC)
- *
- * Copyright (C) 2022 Daniel González Cabanelas
- * based on device tree from qca9558_ubnt_powerbeam-5ac-500.dts
*/
-
-#include "qca955x_ubnt_xc.dtsi"
+
+#include "qca9558_ubnt_nanobeam-ac-xc.dtsi"
/ {
compatible = "ubnt,nanobeam-ac-xc", "ubnt,xc", "qca,qca9558";
model = "Ubiquiti NanoBeam AC Gen1 (XC)";
-
- aliases {
- led-boot = _power;
- led-failsafe = _power;
- led-running = _power;
- led-upgrade = _power;
- };
-
- keys {
- compatible = "gpio-keys";
-
- reset {
- label = "Reset button";
- linux,code = ;
- gpios = < 19 GPIO_ACTIVE_LOW>;
- debounce-interval = <60>;
- };
- };
-
- led_spi {
- compatible = "spi-gpio";
- #address-cells = <1>;
- #size-cells = <0>;
-
- sck-gpios = < 0 GPIO_ACTIVE_HIGH>;
- mosi-gpios = < 1 GPIO_ACTIVE_HIGH>;
- cs-gpios = < 3 GPIO_ACTIVE_HIGH>;
- num-chipselects = <1>;
-
- led_gpio: led_gpio@0 {
- compatible = "fairchild,74hc595";
- reg = <0>;
- gpio-controller;
- #gpio-cells = <2>;
- registers-number = <1>;
- spi-max-frequency = <1000>;
- enable-gpios = < 18 GPIO_ACTIVE_LOW>;
- };
- };
-
- leds {
- compatible = "gpio-leds";
-
- rssi0 {
- label = "blue:rssi0";
- gpios = <_gpio 0 GPIO_ACTIVE_LOW>;
- };
- rssi1 {
-
[PATCH] mvebu: add support for Buffalo LinkStation LS220DE
The Buffalo LinkStation LS220DE is a dual bay NAS, based on Marvell
Armada 370
Hardware:
SoC: Marvell Armada 88F6707
CPU: Cortex-A9 800 MHz, 1 core
Flash 1: SPI-NOR 1 MiB (U-Boot)
Flash 2: NAND 512 MiB (OS)
RAM: DDR3 256 MiB
Ethernet:1x 1GbE
USB: 1x 2.0
SATA:2x 3Gb/s
LEDs/Input: 5x / 2x (1x button, 1x slide-switch)
Fan: 1x casing
Flash instructions, from hard drive:
1. Get access to the "boot" partition at the hard drive where the stock
firmware is installed. It can be done with acp-commander or by
plugging the hard drive to a computer.
2. Backup the stock uImage:
mv /boot/uImage.buffalo /boot/uImage.buffalo.bak
3. Move and rename the Openwrt initramfs image to the boot partition:
mv openwrt-initramfs-kernel.bin /boot/uImage.buffalo
4. Power on the Linkstation with the hardrive inside. Now Openwrt will
boot, but still not installed.
5. Connect via ssh to OpenWrt:
ssh root@192.168.1.1
6. Rename boot files inside boot partition
mount -t ext3 /dev/sda1 /mnt
mv /mnt/uImage.buffalo /mnt/uImage.buffalo.openwrt.bak
mv /mnt/initrd.buffalo /mnt/initrd.buffalo.bak
7. Format ubi partitions at the NAND flash ("kernel_ubi" and "ubi"):
ubiformat /dev/mtd0 -y
ubidetach -p /dev/mtd1
ubiformat /dev/mtd1 -y
8. Flash the sysupgrade image:
sysupgrade -n openwrt-squashfs-sysupgrade.bin
9. Wait until it finish, the device will reboot with OpenWrt installed
on the NAND flash.
Restore the stock firmware:
1. Take the hard drive used for the installation and restore boot backup
files to their original names:
mount -t ext3 /dev/sda1 /mnt
mv /mnt/uImage.buffalo.bak /mnt/uImage.buffalo
mv /mnt/initrd.buffalo.bak /mnt/initrd.buffalo
2. Boot from the hard drive and perform a stock firmware update using
the Buffalo utility. The NAND will be restored to the original
state.
Signed-off-by: Daniel González Cabanelas
---
package/boot/uboot-envtools/files/mvebu | 1 +
.../base-files/etc/board.d/02_network | 1 +
.../base-files/lib/upgrade/platform.sh| 7 +
.../boot/dts/armada-370-buffalo-ls220de.dts | 380 ++
target/linux/mvebu/image/Makefile | 10 +
target/linux/mvebu/image/cortexa9.mk | 15 +
...set-linkstation-poweroff-add-ls220de.patch | 19 +
7 files changed, 433 insertions(+)
create mode 100644
target/linux/mvebu/files/arch/arm/boot/dts/armada-370-buffalo-ls220de.dts
create mode 100644
target/linux/mvebu/patches-5.15/105-power-reset-linkstation-poweroff-add-ls220de.patch
diff --git a/package/boot/uboot-envtools/files/mvebu
b/package/boot/uboot-envtools/files/mvebu
index cc1c648f24..63b5132608 100644
--- a/package/boot/uboot-envtools/files/mvebu
+++ b/package/boot/uboot-envtools/files/mvebu
@@ -13,6 +13,7 @@ touch /etc/config/ubootenv
board=$(board_name)
case "$board" in
+buffalo,ls220de|\
buffalo,ls421de)
ubootenv_add_uci_config "/dev/mtd3" "0x0" "0x1"
;;
diff --git a/target/linux/mvebu/cortexa9/base-files/etc/board.d/02_network
b/target/linux/mvebu/cortexa9/base-files/etc/board.d/02_network
index c613a3cd60..d2229fe6bf 100644
--- a/target/linux/mvebu/cortexa9/base-files/etc/board.d/02_network
+++ b/target/linux/mvebu/cortexa9/base-files/etc/board.d/02_network
@@ -61,6 +61,7 @@ mvebu_setup_macs()
local label_mac=""
case "$board" in
+ buffalo,ls220de|\
buffalo,ls421de)
lan_mac=$(mtd_get_mac_ascii u-boot-env eth1addr)
;;
diff --git a/target/linux/mvebu/cortexa9/base-files/lib/upgrade/platform.sh
b/target/linux/mvebu/cortexa9/base-files/lib/upgrade/platform.sh
index 18b978d437..9019c1aeff 100755
--- a/target/linux/mvebu/cortexa9/base-files/lib/upgrade/platform.sh
+++ b/target/linux/mvebu/cortexa9/base-files/lib/upgrade/platform.sh
@@ -25,6 +25,13 @@ platform_check_image() {
platform_do_upgrade() {
case "$(board_name)" in
+ buffalo,ls220de)
+ # Kernel UBI volume name must be "boot"
+ CI_KERNPART=boot
+ CI_KERN_UBIPART=ubi_kernel
+ CI_ROOT_UBIPART=ubi
+ nand_do_upgrade "$1"
+ ;;
buffalo,ls421de)
nand_do_upgrade "$1"
;;
diff --git
a/target/linux/mvebu/files/arch/arm/boot/dts/armada-370-buffalo-ls220de.dts
b/target/linux/mvebu/files/arch/arm/boot/dts/armada-370-buffalo-ls220de.dts
new file mode 100644
index 00..3de9ac5473
--- /dev/null
+++ b/target/linux/mvebu/files/arch/arm/boot/dts/armada-370-buffalo-ls220de.dts
@@ -0,0 +1,380 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR MIT)
+/*
+ * Device Tree file for Buffalo LinkStat
Re: mt7621 GPIO mapping mystery
On 1/22/23 12:24, Arınç ÜNAL wrote: On 22.01.2023 20:44, Daniel Santos wrote: On 1/22/23 00:23, Arınç ÜNAL wrote: On 22 January 2023 02:02:04 GMT+03:00, Daniel Santos wrote: On 1/21/23 15:19, Arınç ÜNAL wrote: On 21.01.2023 21:32, Daniel Santos wrote: ... You can use this to see what the valid values are for each group, because until this all goes yaml, there's nothing to tell you if you've used an invalid value. Speaking of which: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-next=4e5410668af5475681793df2bb8c7d8dc6f9c327 https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-next=0c9a567651c3b5d433429da2c7d8e8406ddf1076 https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-next=b4ac84395820eaa0b99ec56816e53c9386ca8b38 https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-next=d648fd64e10d9d1609146d0c4e47b0f5988e2a2b https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-next=844bca60927f3aae6baafafb1edd218b624254a1 Arınç OH FUCK YES!!! Arınç, you and I are friends now!! :D Haha hello there! Arınç I don't want to spam the group with this, but you have no idea how much bullshit I've been through that turned out to be a mistake in my device tree file for which there was no warning about. I almost re-wrote the ramips arch code over it, but I had to pull myself back when it was clear that it was unnecessary for my project and hard to justify billing for it. I have that ADHD thing, so I have to stay on track. Glad to read this helps you tremendously. By the way, you didn't CC anyone else so the list didn't receive it ;). Anyway, I'm really pleased to see this and it reminds me that I have a lot of kernel patches I need to submit both to OpenWRT and upstream, including fixing a command line bug for ramips. Speaking of fixing stuff, if you take a look at the yaml for mt7620 and rt305x, some functions got multiple lists for groups. Like refclk on mt7620. Because mt7620 and mt7628/mt7688 SoCs use the same compatible string, it's impossible to differentiate on the binding which SoC your DT is actually for. Therefore, the binding will allow all groups listed for that function. For example if your SoC is mt7620, you can only use the refclk function for the mdio group. If you were to put "spi cs1" as the function there, you wouldn't get a warning. I want to fix this by actually separating mt7628/mt7688 from mt7620 on the pinctrl driver, then split the dt-binding, but I don't know C good enough to do this myself. I have a lot of things I can actually do right now on my task list which could take more than a year (if nothing new is added on top) to complete, so I'm very slowly learning it. It's also the first programming language I ever attempt to learn so understanding the logic of programming is another challenge I've got to deal with. I'd appreciate it greatly if you could help me out on this as you seem to know C. However, I have to send a mail to pinctrl mailing list, see if I can justify breaking the ABI with the maintainers since we would be changing the compatible string for certain SoCs. I've done it once. Arınç I'm not at a place where I can take a new project on as I'm going through a health problem, but let me know when your ready and I'll see if I can help. I'll have to study the code again, as I was mostly concerned with fixing my problem before and didn't look much at other SoCs. There's a lot of reused code between SoCs and that's not bad in-and-of its self, but I'll need to fully analyze them to understand where code sharing follows genuine abstractions of the family of hardware it represents and which parts are are an improper fusion. On the flip side, this would spur me to get all of my platform patches polished off and sent where they need to go as well! One thing you'll see a lot in this platform and driver code is code for one SoC and a lot of that is because the same internal hardware components are reused from one chip to another, and by "internal hardware components," I mean devices like a GPIO banks, SPI bus controllers, ethernet switches, etc. These are circuits that they can essentially copy and paste from one SoC design into another one. Some manufacturers will name and version these internal components and have separate documentation for them that applies to all of their products that contain them, but MediaTek doesn't, so we end up referring back to the code for the first SoC where that piece of hardware was used. Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: mt7621 GPIO mapping mystery
On 1/21/23 15:19, Arınç ÜNAL wrote: On 21.01.2023 21:32, Daniel Santos wrote: ... You can use this to see what the valid values are for each group, because until this all goes yaml, there's nothing to tell you if you've used an invalid value. Speaking of which: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-next=4e5410668af5475681793df2bb8c7d8dc6f9c327 https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-next=0c9a567651c3b5d433429da2c7d8e8406ddf1076 https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-next=b4ac84395820eaa0b99ec56816e53c9386ca8b38 https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-next=d648fd64e10d9d1609146d0c4e47b0f5988e2a2b https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-next=844bca60927f3aae6baafafb1edd218b624254a1 Arınç OH FUCK YES!!! Arınç, you and I are friends now!! :D Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: mt7621 GPIO mapping mystery
e kernel doc about this here: [1] Or introduce a new pinmux operation that can do this? I think you should send an email to kernel gpio / pinctrl kernel mail list to get feedback from Bart and Linus as gpio and pin control maintainers to properly understand the way to go but I don't really understand what is the problem requesting the group as gpio in the device tree like any other single platform is doing and seems to be the correct way to go. Maybe I am missing something :) From what I understand, a gpio is requested by exporting a gpio by either from devicetree or `echo 203 > /sys/class/gpio/export`. /sys/class/gpio is marked as deprecated [0] since kernel version 4.8, please, avoid using it. Use libgpiod instead. Now, the pinctrl driver must somehow know that the pin which translates to the GPIO number needs to function as gpio. Doing this manually on DT bindings is an option but it's not very viable. I believe this is why the gpio_request_enable operation was made for pinctrl drivers to implement. Now a pin can be made to function as GPIO from userspace dynamically instead of hardcoding it on the devicetree. Yes, 'gpio_request_enable()' is thought to request gpio on the desired pin. Boards with pinouts, like Raspberrypi, Bananapi, etc. benefit this the most. Because it'd be extremely hard to hardcode every pin with pinouts on the devicetree for each different device. For example, my Unielec U7621 board uses the rgmii2 pins for ethernet but at the same time it's got pinouts for them. If the pinmux operation worked, I could just export the gpio number and the pin would function as gpio. When I'm done, I could just unexport and the pin group would go back to function as an rgmii bus. I believe this is already the case with pinctrl drivers that can control pins individually. There's no state-default node on DT where some pins are hardcoded to function as gpio. MediaTek Moore Pinctrl driver which can control pins individually implements gpio_request_enable. https://github.com/torvalds/linux/blob/master/drivers/pinctrl/mediatek/pinctrl-moore.c#L77 gpio_request_enable is also there on the Ralink Pinctrl driver but I don't think it does anything. https://github.com/torvalds/linux/blob/master/drivers/pinctrl/ralink/pinctrl-ralink.c#L161 AFAICS, the Ralink driver sets gpio mode for a group of pins using set_mux operation [1] so when the gpio_request_enable() operation is called a check for that pin is set as gpio is performed. Nothing else. Maybe John Crispin who is the writer of this driver can explain a bit more about this. [0]: https://www.kernel.org/doc/Documentation/gpio/sysfs.txt [1]: https://github.com/torvalds/linux/blob/master/drivers/pinctrl/ralink/pinctrl-ralink.c#L117 Best regards, Sergio Paracuellos To the best of my (limited) knowledge we can only change the pin group mode upon boot via device tree and I have not found a mechanism to query the pin sharing scheme dynamically -- I don't think there is one. I would LOVE to have one! But IIUC, to change them dynamically is problematic because you have device drivers that have probed based upon the pin sharing scheme set up in the device tree and changing them out from underneath those respective drivers can resulted in undefined behavior -- I think any such mechanism would have to remove devices that depend upon it first -- and I'm willing to guess that not all of our device drivers are properly coded to "go away." Again, John Crispin will know more about this. Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org 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 openwrt-devel@lists.openwrt.org 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 > > > openwrt-devel@lists.openwrt.org > > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > > > > -- > > Ansuel > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/2] bcm63xx: kernel: fix up bcm63268 roboswitch gpio registers
Some BCM63268 bootloaders may leave gpio registers, related to the
roboswitch, disabled before loading the OpenWrt firmware. As result of
this the switch won't work.
These registers, if not enabled, probably avoid forwarding packets.
Fix it.
Signed-off-by: Daniel González Cabanelas
---
...IPS-BCM63XX-add-support-for-BCM63268.patch | 51 +++
...MIPS-BCM63XX-add-support-for-BCM6318.patch | 10 ++--
...BCM63XX-add-PCIe-support-for-BCM6318.patch | 10 ++--
...-MIPS-BCM63XX-USB-ENETSW-6318-clocks.patch | 4 +-
.../347-MIPS-BCM6318-USB-support.patch| 4 +-
...-MIPS-BCM63XX-fix-BCM63268-USB-clock.patch | 6 +--
...IPS-BCM63XX-add-BCM63268-USB-support.patch | 2 +-
...X-add-clkdev-lookups-for-device-tree.patch | 20
...enable-rgmii-clock-on-external-ports.patch | 2 +-
...CM63XX-Register-SPI-flash-if-present.patch | 2 +-
.../430-MIPS-BCM63XX-add-nand-clocks.patch| 8 +--
.../431-MIPS-BCM63XX-add-nand-rset.patch | 2 +-
...IPS-BCM63XX-add-support-for-BCM63268.patch | 51 +++
...MIPS-BCM63XX-add-support-for-BCM6318.patch | 10 ++--
...BCM63XX-add-PCIe-support-for-BCM6318.patch | 10 ++--
...-MIPS-BCM63XX-USB-ENETSW-6318-clocks.patch | 4 +-
.../347-MIPS-BCM6318-USB-support.patch| 4 +-
...-MIPS-BCM63XX-fix-BCM63268-USB-clock.patch | 6 +--
...IPS-BCM63XX-add-BCM63268-USB-support.patch | 2 +-
...X-add-clkdev-lookups-for-device-tree.patch | 20
...enable-rgmii-clock-on-external-ports.patch | 2 +-
...CM63XX-Register-SPI-flash-if-present.patch | 2 +-
.../430-MIPS-BCM63XX-add-nand-clocks.patch| 8 +--
.../431-MIPS-BCM63XX-add-nand-rset.patch | 2 +-
24 files changed, 154 insertions(+), 88 deletions(-)
diff --git
a/target/linux/bcm63xx/patches-5.10/339-MIPS-BCM63XX-add-support-for-BCM63268.patch
b/target/linux/bcm63xx/patches-5.10/339-MIPS-BCM63XX-add-support-for-BCM63268.patch
index 84209d6e3b..0f59d57f1e 100644
---
a/target/linux/bcm63xx/patches-5.10/339-MIPS-BCM63XX-add-support-for-BCM63268.patch
+++
b/target/linux/bcm63xx/patches-5.10/339-MIPS-BCM63XX-add-support-for-BCM63268.patch
@@ -46,16 +46,37 @@ Signed-off-by: Jonas Gorski
val = bcm_mpi_readl(MPI_CSBASE_REG(0));
--- a/arch/mips/bcm63xx/clk.c
+++ b/arch/mips/bcm63xx/clk.c
-@@ -169,6 +169,8 @@ static void enetsw_set(struct clk *clk,
+@@ -52,6 +52,18 @@ static void bcm_hwclock_set(u32 mask, in
+ bcm_perf_writel(reg, PERF_CKCTL_REG);
+ }
+
++static void bcm_gpiorobosw_set(u32 mask, int enable)
++{
++ u32 reg;
++
++ reg = bcm_gpio_readl(GPIO_ROBOSW_SW_CTRL_REG);
++ if (enable)
++ reg |= mask;
++ else
++ reg &= ~mask;
++ bcm_gpio_writel(reg, GPIO_ROBOSW_SW_CTRL_REG);
++}
++
+ /*
+ * Ethernet MAC "misc" clock: dma clocks and main clock on 6348
+ */
+@@ -169,6 +181,10 @@ static void enetsw_set(struct clk *clk,
clk_disable_unlocked(_swpkt_sar);
}
bcm_hwclock_set(CKCTL_6368_ROBOSW_EN, enable);
+ } else if (BCMCPU_IS_63268()) {
++ bcm_gpiorobosw_set(GPIO_ROBOSW_MII_DUMB_FWDG_EN |
++ GPIO_ROBOSW_HW_FWDG_EN, enable);
+ bcm_hwclock_set(CKCTL_63268_ROBOSW_EN, enable);
} else {
return;
}
-@@ -214,6 +216,8 @@ static void usbh_set(struct clk *clk, in
+@@ -214,6 +230,8 @@ static void usbh_set(struct clk *clk, in
bcm_hwclock_set(CKCTL_6362_USBH_EN, enable);
else if (BCMCPU_IS_6368())
bcm_hwclock_set(CKCTL_6368_USBH_EN, enable);
@@ -64,7 +85,7 @@ Signed-off-by: Jonas Gorski
else
return;
-@@ -236,6 +240,8 @@ static void usbd_set(struct clk *clk, in
+@@ -236,6 +254,8 @@ static void usbd_set(struct clk *clk, in
bcm_hwclock_set(CKCTL_6362_USBD_EN, enable);
else if (BCMCPU_IS_6368())
bcm_hwclock_set(CKCTL_6368_USBD_EN, enable);
@@ -73,7 +94,7 @@ Signed-off-by: Jonas Gorski
else
return;
-@@ -262,9 +268,13 @@ static void spi_set(struct clk *clk, int
+@@ -262,9 +282,13 @@ static void spi_set(struct clk *clk, int
mask = CKCTL_6358_SPI_EN;
else if (BCMCPU_IS_6362())
mask = CKCTL_6362_SPI_EN;
@@ -89,7 +110,7 @@ Signed-off-by: Jonas Gorski
bcm_hwclock_set(mask, enable);
}
-@@ -283,6 +293,8 @@ static void hsspi_set(struct clk *clk, i
+@@ -283,6 +307,8 @@ static void hsspi_set(struct clk *clk, i
mask = CKCTL_6328_HSSPI_EN;
else if (BCMCPU_IS_6362())
mask = CKCTL_6362_HSSPI_EN;
@@ -98,7 +119,7 @@ Signed-off-by: Jonas Gorski
else
return;
-@@ -352,6 +364,8 @@ static void pcie_set(struct clk *clk, in
+@@ -352,6 +378,8 @@ static void pcie_set(struct clk *clk, in
bcm_hwclock_set(CKCTL_6328_PCIE_EN, enable);
else if (BCMCPU_IS_6362())
bcm_hwclock_set(CKCT
[PATCH 2/2] bcm63xx: kernel: power cycle the bcm6358 USB PLL
Some BCM6358 based boards may detect USB2.0 high speed devices as USB1.1
full speed. This is an old well known bug, but nobody cared about it. It
is quite random and hard to track.
With the latest versions of Openwrt, one user confirmed that the bug is
still there (tested router: HG556a).
Power cycle the USB PLL to fix it.
Signed-off-by: Daniel González Cabanelas
---
.../393-bcm6358-power-cycle-usb-pll.patch | 47 +++
...CM63XX-Register-SPI-flash-if-present.patch | 2 +-
.../430-MIPS-BCM63XX-add-nand-clocks.patch| 8 ++--
.../431-MIPS-BCM63XX-add-nand-rset.patch | 2 +-
.../393-bcm6358-power-cycle-usb-pll.patch | 47 +++
...CM63XX-Register-SPI-flash-if-present.patch | 2 +-
.../430-MIPS-BCM63XX-add-nand-clocks.patch| 8 ++--
.../431-MIPS-BCM63XX-add-nand-rset.patch | 2 +-
8 files changed, 106 insertions(+), 12 deletions(-)
create mode 100644
target/linux/bcm63xx/patches-5.10/393-bcm6358-power-cycle-usb-pll.patch
create mode 100644
target/linux/bcm63xx/patches-5.15/393-bcm6358-power-cycle-usb-pll.patch
diff --git
a/target/linux/bcm63xx/patches-5.10/393-bcm6358-power-cycle-usb-pll.patch
b/target/linux/bcm63xx/patches-5.10/393-bcm6358-power-cycle-usb-pll.patch
new file mode 100644
index 00..43b82bca32
--- /dev/null
+++ b/target/linux/bcm63xx/patches-5.10/393-bcm6358-power-cycle-usb-pll.patch
@@ -0,0 +1,47 @@
+--- a/arch/mips/bcm63xx/clk.c
b/arch/mips/bcm63xx/clk.c
+@@ -258,6 +258,8 @@ static struct clk clk_pcm = {
+ */
+ static void usbh_set(struct clk *clk, int enable)
+ {
++ u32 reg;
++
+ if (BCMCPU_IS_6318()) {
+ bcm_hwclock_set(CKCTL_6318_USB_EN, enable);
+ bcm_ub_hwclock_set(UB_CKCTL_6318_USB_EN, enable);
+@@ -265,13 +267,19 @@ static void usbh_set(struct clk *clk, in
+ bcm_hwclock_set(CKCTL_6328_USBH_EN, enable);
+ } else if (BCMCPU_IS_6348()) {
+ bcm_hwclock_set(CKCTL_6348_USBH_EN, enable);
++ } else if (BCMCPU_IS_6358()) {
++ /* power cycle the USB PLL */
++ reg = bcm_rset_readl(RSET_USBH_PRIV,
USBH_PRIV_PLL_CTRL_6358_REG);
++ reg &= ~USBH_PRIV_PLL_CTRL_6358_EN;
++ bcm_rset_writel(RSET_USBH_PRIV, reg,
USBH_PRIV_PLL_CTRL_6358_REG);
++ mdelay(1);
++ reg |= USBH_PRIV_PLL_CTRL_6358_EN;
++ bcm_rset_writel(RSET_USBH_PRIV, reg,
USBH_PRIV_PLL_CTRL_6358_REG);
+ } else if (BCMCPU_IS_6362()) {
+ bcm_hwclock_set(CKCTL_6362_USBH_EN, enable);
+ } else if (BCMCPU_IS_6368()) {
+ bcm_hwclock_set(CKCTL_6368_USBH_EN, enable);
+ } else if (BCMCPU_IS_63268()) {
+- u32 reg;
+-
+ bcm_hwclock_set(CKCTL_63268_USBH_EN, enable);
+ bcm_misc_iddq_set(IDDQ_CTRL_63268_USBH, enable);
+ bcm63xx_core_set_reset(BCM63XX_RESET_USBH, !enable);
+--- a/arch/mips/include/asm/mach-bcm63xx/bcm63xx_regs.h
b/arch/mips/include/asm/mach-bcm63xx/bcm63xx_regs.h
+@@ -1043,9 +1043,11 @@
+ #define USBH_PRIV_SETUP_IPP_MASK (1 << USBH_PRIV_SETUP_IPP_SHIFT)
+
+ #define USBH_PRIV_SETUP_6318_REG 0x00
++#define USBH_PRIV_PLL_CTRL_6358_REG 0x0c
+ #define USBH_PRIV_PLL_CTRL1_6368_REG 0x18
+ #define USBH_PRIV_PLL_CTRL1_6318_REG 0x04
+
++#define USBH_PRIV_PLL_CTRL_6358_EN(1 << 25)
+ #define USBH_PRIV_PLL_CTRL1_6318_SUSP_EN (1 << 27)
+ #define USBH_PRIV_PLL_CTRL1_6318_IDDQ_PWRDN (1 << 31)
+ #define USBH_PRIV_PLL_CTRL1_63268_IDDQ_PWRDN (1 << 9)
diff --git
a/target/linux/bcm63xx/patches-5.10/411-MIPS-BCM63XX-Register-SPI-flash-if-present.patch
b/target/linux/bcm63xx/patches-5.10/411-MIPS-BCM63XX-Register-SPI-flash-if-present.patch
index c2738c15e5..364e700533 100644
---
a/target/linux/bcm63xx/patches-5.10/411-MIPS-BCM63XX-Register-SPI-flash-if-present.patch
+++
b/target/linux/bcm63xx/patches-5.10/411-MIPS-BCM63XX-Register-SPI-flash-if-present.patch
@@ -146,7 +146,7 @@ Signed-off-by: Jonas Gorski
#define STRAPBUS_6368_BOOT_SEL_MASK 0x3
#define STRAPBUS_6368_BOOT_SEL_NAND 0
#define STRAPBUS_6368_BOOT_SEL_SERIAL 1
-@@ -1570,6 +1571,7 @@
+@@ -1572,6 +1573,7 @@
#define IDDQ_CTRL_63268_USBH (1 << 4)
#define MISC_STRAPBUS_6328_REG0x240
diff --git
a/target/linux/bcm63xx/patches-5.10/430-MIPS-BCM63XX-add-nand-clocks.patch
b/target/linux/bcm63xx/patches-5.10/430-MIPS-BCM63XX-add-nand-clocks.patch
index 731dae1ad3..877953ac65 100644
--- a/target/linux/bcm63xx/patches-5.10/430-MIPS-BCM63XX-add-nand-clocks.patch
+++ b/target/linux/bcm63xx/patches-5.10/430-MIPS-BCM63XX-add-nand-clocks.patch
@@ -1,6 +1,6 @@
--- a/arch/mips/bcm63xx/clk.c
+++ b/arch/mips/bcm63xx/clk.c
-@@ -444,6 +444,23 @@ static struct clk clk_pcie = {
+@@ -452,6 +452,23 @@ static struct clk clk_pcie = {
};
/*
@@ -24,7 +24,7 @@
* Internal peripheral clock
*/
static struct clk clk_periph = {
-@@ -638,6 +655,7
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 openwrt-devel@lists.openwrt.org 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/20180723160300.58024-3-...@nbd.name/ > > 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 openwrt-devel@lists.openwrt.org 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 openwrt-devel@lists.openwrt.org 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 openwrt-devel@lists.openwrt.org 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
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v4 3/3] bcm63xx: add support for Tp-Link Archer VR400 v1
The Archer VR400 v1 is an EOL xDSL router with 802.11bgn/802.11ac wifi.
Hardware:
- SoC: Broadcom BCM63167
- CPU: dual core BMIPS4350 V8.0 @400MHz
- RAM: 128 MB DDR2
- Flash: 16 MB SPI NOR
- Ethernet LAN: 3x 100Mbit
- Ethernet WAN: 1x GbE
- Wifi 2.4 GHz: SoC integrated BCM435F 802.11b/g/n
- WiFi 5 GHz: onboard BCM4352 802.11ac
- USB: 1x 2.0
- Buttons: 3x, 1 reset
- LEDs: 10x, all green
Installation via UART serial console and TFTP:
- Configure a static IP on the computer e.g: 192.168.1.7
- Put the openwrt-factory.bin in a TFTP server in the computer
- Power on the router with the serial console connected
- While initializing the bootloader press any key to reach the CLI
- At the CFE command line, execute the command:
f 192.168.1.7:openwrt-factory.bin image
- Wait until it finish.
Back to OEM firmware:
- Stop the bootloader with the serial console
- Flash the OEM firmware using the CFE web UI: http://192.168.1.1
Unsupported:
- xDSL
- Wifi 2.4 GHz
- WiFi 5 GHz, BCM4352, might eventually get basic support.
Signed-off-by: Daniel González Cabanelas
Signed-off-by: Artemii Karavashkin
---
Changes in v2:
- added USB packages.
Changes in v3:
- no changes
Changes in v4:
- fixed linux node name partition in dts to match the offset
.../bcm63xx/base-files/etc/board.d/01_leds| 4 +
.../bcm63xx/base-files/etc/board.d/02_network | 4 +
.../dts/bcm63167-tplink-archer-vr400-v1.dts | 177 ++
target/linux/bcm63xx/image/bcm63xx.mk | 14 ++
.../patches-5.10/519-board_bcm63268.patch | 52 -
...31-board_bcm6348-bt-voyager-2500v-bb.patch | 2 +-
.../patches-5.15/519-board_bcm63268.patch | 52 -
...31-board_bcm6348-bt-voyager-2500v-bb.patch | 2 +-
8 files changed, 299 insertions(+), 8 deletions(-)
create mode 100644 target/linux/bcm63xx/dts/bcm63167-tplink-archer-vr400-v1.dts
diff --git a/target/linux/bcm63xx/base-files/etc/board.d/01_leds
b/target/linux/bcm63xx/base-files/etc/board.d/01_leds
index 75e8afef9d..92fb1bc408 100644
--- a/target/linux/bcm63xx/base-files/etc/board.d/01_leds
+++ b/target/linux/bcm63xx/base-files/etc/board.d/01_leds
@@ -94,6 +94,10 @@ sercomm,h500-s-vfes)
telsey,cpva502plus)
ucidef_set_led_netdev "lan" "LAN" "amber:link" "eth0"
;;
+tplink,archer-vr400-v1)
+ ucidef_set_led_netdev "wan" "WAN" "green:wan" "eth0.2"
+ ucidef_set_led_usbdev "usb" "USB" "green:usb" "1-1"
+ ;;
esac
board_config_flush
diff --git a/target/linux/bcm63xx/base-files/etc/board.d/02_network
b/target/linux/bcm63xx/base-files/etc/board.d/02_network
index b48aa57d2e..32547bf448 100644
--- a/target/linux/bcm63xx/base-files/etc/board.d/02_network
+++ b/target/linux/bcm63xx/base-files/etc/board.d/02_network
@@ -159,6 +159,10 @@ sky,sr102)
ucidef_add_switch "switch0" \
"0:lan" "1:lan" "2:lan" "3:wan" "8t@eth0"
;;
+tplink,archer-vr400-v1)
+ ucidef_add_switch "switch0" \
+ "0:lan:3" "1:lan:2" "2:lan:1" "3:wan" "8t@eth0"
+ ;;
*)
ucidef_set_interfaces_lan_wan "eth1" "eth0"
;;
diff --git a/target/linux/bcm63xx/dts/bcm63167-tplink-archer-vr400-v1.dts
b/target/linux/bcm63xx/dts/bcm63167-tplink-archer-vr400-v1.dts
new file mode 100644
index 00..a3dbca7d78
--- /dev/null
+++ b/target/linux/bcm63xx/dts/bcm63167-tplink-archer-vr400-v1.dts
@@ -0,0 +1,177 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Device Tree file for TP-Link Archer VR400 v1
+ *
+ * Copyright (C) 2022 Daniel González Cabanelas
+ * Copyright (C) 2022 Artemii Karavashkin
+ */
+
+#include "bcm63268.dtsi"
+
+#include
+#include
+
+/ {
+ model = "TP-Link Archer VR400 v1";
+ compatible = "tplink,archer-vr400-v1", "brcm,bcm63167", "brcm,bcm63268";
+
+ aliases {
+ led-boot = _power_green;
+ led-failsafe = _power_green;
+ led-running = _power_green;
+ led-upgrade = _power_green;
+ };
+
+ chosen {
+ bootargs = "rootfstype=squashfs,jffs2 noinitrd
console=ttyS0,115200";
+ stdout-path = "serial0:115200n8";
+ };
+
+ keys {
+ compatible = "gpio-keys";
+
+ reset {
+ label = "reset";
+ gpios = < 32 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ debounce-interval = <60>;
+ };
+
+ wps {
+ label = "wps";
+ gpios = < 33 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ debo
[PATCH v4 1/3] bcm63xx: kernel: enable the tplink image parser
Enable the tplink mtd firmware splitter to allow booting images with tplink headers. Since known devices with these headers are dual core, only enable this driver in the SMP subtarget. Signed-off-by: Daniel González Cabanelas --- Changes in v2: no changes Changes in v3: cosmetic Changes in v4: no changes target/linux/bcm63xx/smp/config-default | 1 + 1 file changed, 1 insertion(+) diff --git a/target/linux/bcm63xx/smp/config-default b/target/linux/bcm63xx/smp/config-default index a6eae6e41d..15135f01a6 100644 --- a/target/linux/bcm63xx/smp/config-default +++ b/target/linux/bcm63xx/smp/config-default @@ -19,6 +19,7 @@ CONFIG_MTD_NAND_CORE=y CONFIG_MTD_NAND_ECC_SW_HAMMING=y CONFIG_MTD_RAW_NAND=y CONFIG_MTD_SPLIT_BCM_WFI_FW=y +CONFIG_MTD_SPLIT_TPLINK_FW=y CONFIG_MTD_UBI=y CONFIG_MTD_UBI_BEB_LIMIT=20 CONFIG_MTD_UBI_BLOCK=y -- 2.38.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v4 2/3] bcm63xx: build tplink images
Add macros and a python script to build images compatible with tplink
CFE bootloaders.
Signed-off-by: Daniel González Cabanelas
---
Changes in v2:
- factory image fixed. (cfe-tplink-crcfix.py doesn't work if CFE
already prepended)
Changes in v3:
- fixed name in temp files for prepending CFE to be safer.
Changes in v4:
- no changes
scripts/cfe-tplink-crcfix.py | 48 +++
target/linux/bcm63xx/image/Makefile | 23 +
target/linux/bcm63xx/image/bcm63xx.mk | 19 +++
3 files changed, 90 insertions(+)
create mode 100755 scripts/cfe-tplink-crcfix.py
diff --git a/scripts/cfe-tplink-crcfix.py b/scripts/cfe-tplink-crcfix.py
new file mode 100755
index 00..2db6d6cce9
--- /dev/null
+++ b/scripts/cfe-tplink-crcfix.py
@@ -0,0 +1,48 @@
+#!/usr/bin/python3
+# SPDX-License-Identifier: GPL-2.0-or-later
+#
+# Copyright (C) 2022 OpenWrt.org, based on cameo-tag.py
+#
+# this tool fixes the CRC32 (kernel+rootfs) found in CFE headers from
+# Tp-Link bcm63xx devices. It doesn't recalculate header checksums
+# since CFE doesn't make any header integrity verification to boot OpenWrt.
+
+import argparse
+import os
+import struct
+import zlib
+
+READ_UNTIL_EOF = -1
+CFE_HEADER_SIZE = 512
+
+def read_buffer(offset, count):
+args.cfeimage_file.seek(offset)
+return bytearray(args.cfeimage_file.read(count))
+
+def write_buffer(whence, buf):
+args.cfeimage_file.seek(0, whence)
+args.cfeimage_file.write(buf)
+
+def invertcrc(buf):
+return (zlib.crc32(buf) ^ 0x).to_bytes(4, 'big')
+
+def checksum_header(buf):
+BINCRC32 = args.crc_offset
+ROOTFSADDRESS = buf[124:128]
+ROOTFSLEN = buf[128:132]
+IMLEN = struct.unpack('>i', ROOTFSADDRESS)[0] + struct.unpack('>i',
ROOTFSLEN)[0] + CFE_HEADER_SIZE
+buf[BINCRC32:BINCRC32+4] = invertcrc(buf[CFE_HEADER_SIZE:IMLEN])
+return buf
+
+parser = argparse.ArgumentParser(description='Insert CRC in tplink CFE
firmware tags.')
+parser.add_argument('cfeimage_file', type=argparse.FileType('r+b'))
+# crc_offset should be 148 or 152
+parser.add_argument('crc_offset', type=int)
+args = parser.parse_args()
+
+args.cfeimage_file.seek(0, os.SEEK_END)
+if args.cfeimage_file.tell() <= CFE_HEADER_SIZE:
+raise ValueError(f"CFE image must be larger than {CFE_HEADER_SIZE} bytes")
+
+buf = checksum_header(read_buffer(0, READ_UNTIL_EOF))
+write_buffer(os.SEEK_SET, buf)
diff --git a/target/linux/bcm63xx/image/Makefile
b/target/linux/bcm63xx/image/Makefile
index f35358173c..019596e004 100644
--- a/target/linux/bcm63xx/image/Makefile
+++ b/target/linux/bcm63xx/image/Makefile
@@ -143,6 +143,15 @@ define Build/cfe-jffs2-cferam
rm -f $@.kernel
endef
+define Build/cfe-kernel-header
+ $(TOPDIR)/scripts/cfe-bin-header.py \
+ --input-file $@ \
+ --output-file $@-tmp \
+ --load-addr $(if
$(DEVICE_LOADADDR),$(DEVICE_LOADADDR),$(LOADER_ENTRY)) \
+ --entry-addr $(if
$(DEVICE_LOADADDR),$(DEVICE_LOADADDR),$(LOADER_ENTRY))
+ mv $@-tmp $@
+endef
+
define Build/cfe-jffs2-kernel
rm -rf $@-kernel
mkdir -p $@-kernel
@@ -274,6 +283,20 @@ define Build/zyxel-bin
mv $@.zyxel $@
endef
+define Build/tplink-prepend-cfe
+ dd if=$(KDIR)/bcm63xx-cfe/$(CFE_BIN_FILE) bs=128k conv=sync
of=$@.cfeprepend
+ dd if=$@ >> $@.cfeprepend
+ mv $@.cfeprepend $@
+endef
+
+define Build/tplink-sysupgrade
+ # append 512 bytes to avoid computing CRC for data beyond jffs2 EOF mark
+ dd if=/dev/null bs=512 count=1 >> $(IMAGE_ROOTFS)
+ $(call Build/tplink-v2-image, -v 0.9.1 -s)
+ # insert ~CRC32 (rootfs+kernel) to allow CFE booting Openwrt
+ $(TOPDIR)/scripts/cfe-tplink-crcfix.py $@ $(TPLINK_CRC_OFFSET)
+endef
+
define Build/redboot-bin
# Prepare kernel and rootfs
dd if=$(IMAGE_KERNEL) of=$(BIN_DIR)/$(REDBOOT_PREFIX)-vmlinux.gz
bs=65536 conv=sync
diff --git a/target/linux/bcm63xx/image/bcm63xx.mk
b/target/linux/bcm63xx/image/bcm63xx.mk
index 97959d7819..bbf4da6505 100644
--- a/target/linux/bcm63xx/image/bcm63xx.mk
+++ b/target/linux/bcm63xx/image/bcm63xx.mk
@@ -5,9 +5,12 @@
DEVICE_VARS += HCS_MAGIC_BYTES HCS_REV_MIN HCS_REV_MAJ
DEVICE_VARS += BLOCK_SIZE FLASH_MB IMAGE_OFFSET
+DEVICE_VARS += CFE_BIN_FILE
DEVICE_VARS += CFE_BOARD_ID CFE_EXTRAS
DEVICE_VARS += NETGEAR_BOARD_ID NETGEAR_REGION
DEVICE_VARS += REDBOOT_PREFIX
+DEVICE_VARS += TPLINK_HWID TPLINK_HWREV TPLINK_FLASHLAYOUT
+DEVICE_VARS += TPLINK_HWREVADD TPLINK_HVERSION TPLINK_CRC_OFFSET
define Device/bcm33xx
KERNEL_INITRAMFS := kernel-bin | append-dtb | lzma | loader-lzma bin |
hcs-initramfs
@@ -59,6 +62,22 @@ define Device/bcm63xx_redboot
REDBOOT_PREFIX := $$(DEVICE_IMG_PREFIX)
endef
+define Device/bcm63xx_tplink
+ FILESYSTEMS := squashfs
+ DEVICE_VENDOR := TP-Link
+ TPLINK_HWID := 0x0
+ TPLINK_HWREV := 0x1
+ TPLINK_HWREVADD := 0x0
+ TPLINK_HVER
[PATCH v3 3/3] bcm63xx: add support for Tp-Link Archer VR400 v1
The Archer VR400 v1 is an EOL xDSL router with 802.11bgn/802.11ac wifi.
Hardware:
- SoC: Broadcom BCM63167
- CPU: dual core BMIPS4350 V8.0 @400MHz
- RAM: 128 MB DDR2
- Flash: 16 MB SPI NOR
- Ethernet LAN: 3x 100Mbit
- Ethernet WAN: 1x GbE
- Wifi 2.4 GHz: SoC integrated BCM435F 802.11b/g/n
- WiFi 5 GHz: onboard BCM4352 802.11ac
- USB: 1x 2.0
- Buttons: 3x, 1 reset
- LEDs: 10x, all green
Installation via UART serial console and TFTP:
- Configure a static IP on the computer e.g: 192.168.1.7
- Put the openwrt-factory.bin in a TFTP server in the computer
- Power on the router with the serial console connected
- While initializing the bootloader press any key to reach the CLI
- At the CFE command line, execute the command:
f 192.168.1.7:openwrt-factory.bin image
- Wait until it finish.
Back to OEM firmware:
- Stop the bootloader with the serial console
- Flash the OEM firmware using the CFE web UI: http://192.168.1.1
Unsupported:
- xDSL
- Wifi 2.4 GHz
- WiFi 5 GHz, BCM4352, might eventually get basic support.
Signed-off-by: Daniel González Cabanelas
Signed-off-by: Artemii Karavashkin
---
Changes in v2:
- added USB packages.
Changes in v3:
- no changes
.../bcm63xx/base-files/etc/board.d/01_leds| 4 +
.../bcm63xx/base-files/etc/board.d/02_network | 4 +
.../dts/bcm63167-tplink-archer-vr400-v1.dts | 177 ++
target/linux/bcm63xx/image/bcm63xx.mk | 14 ++
.../patches-5.10/519-board_bcm63268.patch | 52 -
...31-board_bcm6348-bt-voyager-2500v-bb.patch | 2 +-
.../patches-5.15/519-board_bcm63268.patch | 52 -
...31-board_bcm6348-bt-voyager-2500v-bb.patch | 2 +-
8 files changed, 299 insertions(+), 8 deletions(-)
create mode 100644 target/linux/bcm63xx/dts/bcm63167-tplink-archer-vr400-v1.dts
diff --git a/target/linux/bcm63xx/base-files/etc/board.d/01_leds
b/target/linux/bcm63xx/base-files/etc/board.d/01_leds
index 75e8afef9d..92fb1bc408 100644
--- a/target/linux/bcm63xx/base-files/etc/board.d/01_leds
+++ b/target/linux/bcm63xx/base-files/etc/board.d/01_leds
@@ -94,6 +94,10 @@ sercomm,h500-s-vfes)
telsey,cpva502plus)
ucidef_set_led_netdev "lan" "LAN" "amber:link" "eth0"
;;
+tplink,archer-vr400-v1)
+ ucidef_set_led_netdev "wan" "WAN" "green:wan" "eth0.2"
+ ucidef_set_led_usbdev "usb" "USB" "green:usb" "1-1"
+ ;;
esac
board_config_flush
diff --git a/target/linux/bcm63xx/base-files/etc/board.d/02_network
b/target/linux/bcm63xx/base-files/etc/board.d/02_network
index b48aa57d2e..32547bf448 100644
--- a/target/linux/bcm63xx/base-files/etc/board.d/02_network
+++ b/target/linux/bcm63xx/base-files/etc/board.d/02_network
@@ -159,6 +159,10 @@ sky,sr102)
ucidef_add_switch "switch0" \
"0:lan" "1:lan" "2:lan" "3:wan" "8t@eth0"
;;
+tplink,archer-vr400-v1)
+ ucidef_add_switch "switch0" \
+ "0:lan:3" "1:lan:2" "2:lan:1" "3:wan" "8t@eth0"
+ ;;
*)
ucidef_set_interfaces_lan_wan "eth1" "eth0"
;;
diff --git a/target/linux/bcm63xx/dts/bcm63167-tplink-archer-vr400-v1.dts
b/target/linux/bcm63xx/dts/bcm63167-tplink-archer-vr400-v1.dts
new file mode 100644
index 00..a3dbca7d78
--- /dev/null
+++ b/target/linux/bcm63xx/dts/bcm63167-tplink-archer-vr400-v1.dts
@@ -0,0 +1,177 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Device Tree file for TP-Link Archer VR400 v1
+ *
+ * Copyright (C) 2022 Daniel González Cabanelas
+ * Copyright (C) 2022 Artemii Karavashkin
+ */
+
+#include "bcm63268.dtsi"
+
+#include
+#include
+
+/ {
+ model = "TP-Link Archer VR400 v1";
+ compatible = "tplink,archer-vr400-v1", "brcm,bcm63167", "brcm,bcm63268";
+
+ aliases {
+ led-boot = _power_green;
+ led-failsafe = _power_green;
+ led-running = _power_green;
+ led-upgrade = _power_green;
+ };
+
+ chosen {
+ bootargs = "rootfstype=squashfs,jffs2 noinitrd
console=ttyS0,115200";
+ stdout-path = "serial0:115200n8";
+ };
+
+ keys {
+ compatible = "gpio-keys";
+
+ reset {
+ label = "reset";
+ gpios = < 32 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ debounce-interval = <60>;
+ };
+
+ wps {
+ label = "wps";
+ gpios = < 33 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ debounce-interval = <60>;
+ };
+
[PATCH v3 2/3] bcm63xx: build tplink images
Add macros and a python script to build images compatible with tplink
CFE bootloaders.
Signed-off-by: Daniel González Cabanelas
---
Changes in v2:
- factory image fixed. (cfe-tplink-crcfix.py doesn't work if CFE
already prepended)
Changes in v3:
- name in temp files for prepending CFE fixed to be safer.
scripts/cfe-tplink-crcfix.py | 48 +++
target/linux/bcm63xx/image/Makefile | 23 +
target/linux/bcm63xx/image/bcm63xx.mk | 19 +++
3 files changed, 90 insertions(+)
create mode 100755 scripts/cfe-tplink-crcfix.py
diff --git a/scripts/cfe-tplink-crcfix.py b/scripts/cfe-tplink-crcfix.py
new file mode 100755
index 00..2db6d6cce9
--- /dev/null
+++ b/scripts/cfe-tplink-crcfix.py
@@ -0,0 +1,48 @@
+#!/usr/bin/python3
+# SPDX-License-Identifier: GPL-2.0-or-later
+#
+# Copyright (C) 2022 OpenWrt.org, based on cameo-tag.py
+#
+# this tool fixes the CRC32 (kernel+rootfs) found in CFE headers from
+# Tp-Link bcm63xx devices. It doesn't recalculate header checksums
+# since CFE doesn't make any header integrity verification to boot OpenWrt.
+
+import argparse
+import os
+import struct
+import zlib
+
+READ_UNTIL_EOF = -1
+CFE_HEADER_SIZE = 512
+
+def read_buffer(offset, count):
+args.cfeimage_file.seek(offset)
+return bytearray(args.cfeimage_file.read(count))
+
+def write_buffer(whence, buf):
+args.cfeimage_file.seek(0, whence)
+args.cfeimage_file.write(buf)
+
+def invertcrc(buf):
+return (zlib.crc32(buf) ^ 0x).to_bytes(4, 'big')
+
+def checksum_header(buf):
+BINCRC32 = args.crc_offset
+ROOTFSADDRESS = buf[124:128]
+ROOTFSLEN = buf[128:132]
+IMLEN = struct.unpack('>i', ROOTFSADDRESS)[0] + struct.unpack('>i',
ROOTFSLEN)[0] + CFE_HEADER_SIZE
+buf[BINCRC32:BINCRC32+4] = invertcrc(buf[CFE_HEADER_SIZE:IMLEN])
+return buf
+
+parser = argparse.ArgumentParser(description='Insert CRC in tplink CFE
firmware tags.')
+parser.add_argument('cfeimage_file', type=argparse.FileType('r+b'))
+# crc_offset should be 148 or 152
+parser.add_argument('crc_offset', type=int)
+args = parser.parse_args()
+
+args.cfeimage_file.seek(0, os.SEEK_END)
+if args.cfeimage_file.tell() <= CFE_HEADER_SIZE:
+raise ValueError(f"CFE image must be larger than {CFE_HEADER_SIZE} bytes")
+
+buf = checksum_header(read_buffer(0, READ_UNTIL_EOF))
+write_buffer(os.SEEK_SET, buf)
diff --git a/target/linux/bcm63xx/image/Makefile
b/target/linux/bcm63xx/image/Makefile
index f35358173c..019596e004 100644
--- a/target/linux/bcm63xx/image/Makefile
+++ b/target/linux/bcm63xx/image/Makefile
@@ -143,6 +143,15 @@ define Build/cfe-jffs2-cferam
rm -f $@.kernel
endef
+define Build/cfe-kernel-header
+ $(TOPDIR)/scripts/cfe-bin-header.py \
+ --input-file $@ \
+ --output-file $@-tmp \
+ --load-addr $(if
$(DEVICE_LOADADDR),$(DEVICE_LOADADDR),$(LOADER_ENTRY)) \
+ --entry-addr $(if
$(DEVICE_LOADADDR),$(DEVICE_LOADADDR),$(LOADER_ENTRY))
+ mv $@-tmp $@
+endef
+
define Build/cfe-jffs2-kernel
rm -rf $@-kernel
mkdir -p $@-kernel
@@ -274,6 +283,20 @@ define Build/zyxel-bin
mv $@.zyxel $@
endef
+define Build/tplink-prepend-cfe
+ dd if=$(KDIR)/bcm63xx-cfe/$(CFE_BIN_FILE) bs=128k conv=sync
of=$@.cfeprepend
+ dd if=$@ >> $@.cfeprepend
+ mv $@.cfeprepend $@
+endef
+
+define Build/tplink-sysupgrade
+ # append 512 bytes to avoid computing CRC for data beyond jffs2 EOF mark
+ dd if=/dev/null bs=512 count=1 >> $(IMAGE_ROOTFS)
+ $(call Build/tplink-v2-image, -v 0.9.1 -s)
+ # insert ~CRC32 (rootfs+kernel) to allow CFE booting Openwrt
+ $(TOPDIR)/scripts/cfe-tplink-crcfix.py $@ $(TPLINK_CRC_OFFSET)
+endef
+
define Build/redboot-bin
# Prepare kernel and rootfs
dd if=$(IMAGE_KERNEL) of=$(BIN_DIR)/$(REDBOOT_PREFIX)-vmlinux.gz
bs=65536 conv=sync
diff --git a/target/linux/bcm63xx/image/bcm63xx.mk
b/target/linux/bcm63xx/image/bcm63xx.mk
index 97959d7819..bbf4da6505 100644
--- a/target/linux/bcm63xx/image/bcm63xx.mk
+++ b/target/linux/bcm63xx/image/bcm63xx.mk
@@ -5,9 +5,12 @@
DEVICE_VARS += HCS_MAGIC_BYTES HCS_REV_MIN HCS_REV_MAJ
DEVICE_VARS += BLOCK_SIZE FLASH_MB IMAGE_OFFSET
+DEVICE_VARS += CFE_BIN_FILE
DEVICE_VARS += CFE_BOARD_ID CFE_EXTRAS
DEVICE_VARS += NETGEAR_BOARD_ID NETGEAR_REGION
DEVICE_VARS += REDBOOT_PREFIX
+DEVICE_VARS += TPLINK_HWID TPLINK_HWREV TPLINK_FLASHLAYOUT
+DEVICE_VARS += TPLINK_HWREVADD TPLINK_HVERSION TPLINK_CRC_OFFSET
define Device/bcm33xx
KERNEL_INITRAMFS := kernel-bin | append-dtb | lzma | loader-lzma bin |
hcs-initramfs
@@ -59,6 +62,22 @@ define Device/bcm63xx_redboot
REDBOOT_PREFIX := $$(DEVICE_IMG_PREFIX)
endef
+define Device/bcm63xx_tplink
+ FILESYSTEMS := squashfs
+ DEVICE_VENDOR := TP-Link
+ TPLINK_HWID := 0x0
+ TPLINK_HWREV := 0x1
+ TPLINK_HWREVADD := 0x0
+ TPLINK_HVERSION := 3
+ TPLINK_FLASHLAYOUT :=
+ TPLINK_CR
[PATCH v3 1/3] bcm63xx: kernel: enable the tplink image parser
Enable the tplink mtd firmware splitter to allow booting images with tplink headers. Since known devices with these headers are dual core, only enable this driver in the SMP subtarget. Signed-off-by: Daniel González Cabanelas --- Changes in v2: no changes Changes in v3: cosmetic target/linux/bcm63xx/smp/config-default | 1 + 1 file changed, 1 insertion(+) diff --git a/target/linux/bcm63xx/smp/config-default b/target/linux/bcm63xx/smp/config-default index a6eae6e41d..15135f01a6 100644 --- a/target/linux/bcm63xx/smp/config-default +++ b/target/linux/bcm63xx/smp/config-default @@ -19,6 +19,7 @@ CONFIG_MTD_NAND_CORE=y CONFIG_MTD_NAND_ECC_SW_HAMMING=y CONFIG_MTD_RAW_NAND=y CONFIG_MTD_SPLIT_BCM_WFI_FW=y +CONFIG_MTD_SPLIT_TPLINK_FW=y CONFIG_MTD_UBI=y CONFIG_MTD_UBI_BEB_LIMIT=20 CONFIG_MTD_UBI_BLOCK=y -- 2.38.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org 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 openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] linux: add in labels for block2mtd
On Tue, Nov 29, 2022 at 11:28:29AM -0500, Peter Naulls wrote: > On 11/29/22 10:32, Daniel Golle wrote: > > On Tue, Nov 29, 2022 at 10:23:48AM -0500, Peter Naulls wrote: > > > > > > This backports the upstream label feature in block2mtd to the 5.10.x > > > kernel > > > in 22.03: > > > > > > https://github.com/torvalds/linux/blob/master/drivers/mtd/devices/block2mtd.c > > > > Where are we using block2mtd and why? > > > > I should have added more context. I don't think there's really a "we" here, > this is something I needed, and it's more for discussion than anything. I > don't > think it has a general use in OpenWrt at present, and given the release status > of 22.03 you could even argue it shouldn't go in. > > My application is for encrypting the rootfs_data partition to meet security > audit requirements (rootfs too, but that's a different step). I know there > hasn't been much appetite for this in the past, and I'm painfully aware of the > OSS nature here vs encryption, but here we are. This is a requirement for > our product, whether I get pushback or not. > > In any case, block2mtd allows me to present devices from cryptsetup to jffs2. > I'm working on some additional patches to make this all work with 'mount_root' > and sysupgrade, so we'll see - it will be experimental in nature for sure, and > may not ultimately be the best way to do things. That's OK. 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. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] linux: add in labels for block2mtd
On Tue, Nov 29, 2022 at 10:23:48AM -0500, Peter Naulls wrote:
>
> This backports the upstream label feature in block2mtd to the 5.10.x kernel
> in 22.03:
>
> https://github.com/torvalds/linux/blob/master/drivers/mtd/devices/block2mtd.c
Where are we using block2mtd and why?
I'm not against backporting this, but I don't understand why it is
needed or where we are even using block2mtd.
> --- a/drivers/mtd/devices/block2mtd.c 2022-11-29 07:35:32.382695321 -0500
> +++ b/drivers/mtd/devices/block2mtd.c 2022-11-29 08:04:27.406754981 -0500
> @@ -31,6 +31,9 @@
> #include
> #include
>
> +/* Maximum number of comma-separated items in the 'block2mtd=' parameter */
> +#define BLOCK2MTD_PARAM_MAX_COUNT 3
> +
> /* Info for the block device */
> struct block2mtd_dev {
> struct list_head list;
> @@ -214,7 +217,7 @@
>
>
> static struct block2mtd_dev *add_device(char *devname, int erase_size,
> - int timeout)
> + char *label, int timeout)
> {
> #ifndef MODULE
> int i;
> @@ -278,7 +281,10 @@
>
> /* Setup the MTD structure */
> /* make the name contain the block device in */
> - name = kasprintf(GFP_KERNEL, "block2mtd: %s", devname);
> + if (!label)
> + name = kasprintf(GFP_KERNEL, "block2mtd: %s", devname);
> + else
> + name = kstrdup(label, GFP_KERNEL);
> if (!name)
> goto err_destroy_mutex;
>
> @@ -305,7 +311,7 @@
> list_add(>list, _device_list);
> pr_info("mtd%d: [%s] erase_size = %dKiB [%d]\n",
> dev->mtd.index,
> - dev->mtd.name + strlen("block2mtd: "),
> + label ? label : dev->mtd.name + strlen("block2mtd: "),
> dev->mtd.erasesize >> 10, dev->mtd.erasesize);
> return dev;
>
> @@ -381,8 +387,9 @@
> /* 80 for device, 12 for erase size, 80 for name, 8 for timeout */
> char buf[80 + 12 + 80 + 8];
> char *str = buf;
> - char *token[2];
> + char *token[BLOCK2MTD_PARAM_MAX_COUNT];
> char *name;
> + char *label = NULL;
> size_t erase_size = PAGE_SIZE;
> unsigned long timeout = MTD_DEFAULT_TIMEOUT;
> int i, ret;
> @@ -395,7 +402,7 @@
> strcpy(str, val);
> kill_final_newline(str);
>
> - for (i = 0; i < 2; i++)
> + for (i = 0; i < BLOCK2MTD_PARAM_MAX_COUNT; i++)
> token[i] = strsep(, ",");
>
> if (str) {
> @@ -414,7 +421,8 @@
> return 0;
> }
>
> - if (token[1]) {
> + /* Optional argument when custom label is used */
> + if (token[1] && strlen(token[1])) {
> ret = parse_num(_size, token[1]);
> if (ret) {
> pr_err("illegal erase size\n");
> @@ -422,7 +430,12 @@
> }
> }
>
> - add_device(name, erase_size, timeout);
> + if (token[2]) {
> + label = token[2];
> + pr_info("Using custom MTD label '%s' for dev %s\n", label,
> name);
> + }
> +
> + add_device(name, erase_size, label, timeout);
>
> return 0;
> }
> @@ -448,7 +461,7 @@
> the device (even kmalloc() fails). Deter that work to
> block2mtd_setup2(). */
>
> - strlcpy(block2mtd_paramline, val, sizeof(block2mtd_paramline));
> + strscpy(block2mtd_paramline, val, sizeof(block2mtd_paramline));
>
> return 0;
> #endif
> @@ -456,7 +469,7 @@
>
>
> module_param_call(block2mtd, block2mtd_setup, NULL, NULL, 0200);
> -MODULE_PARM_DESC(block2mtd, "Device to use.
> \"block2mtd=[,]\"");
> +MODULE_PARM_DESC(block2mtd, "Device to use.
> \"block2mtd=[,[][,]]\"");
>
> static int __init block2mtd_init(void)
> {
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ramips: use ARTIFACTS for initramfs-factory of I-O DATA WN-AX1167GR
On Tue, Nov 29, 2022 at 11:10:22PM +0900, INAGAKI Hiroshi wrote: > [...] > This seems to be caused by "image" directory in > staging_dir/target-mipsel_24kc_musl/ not existing, and when I created that > folder manually the build succeeded. > > --- > user@hostmachine:/openwrt/user/git/musashino-build/openwrt$ mkdir > staging_dir/target-mipsel_24kc_musl/image > user@hostmachine:/openwrt/user/git/musashino-build/openwrt$ make -j8 V=s > ... > (completed without errors) > --- > > Should I add a patch to create "image" directory before copying? I've sent out a patch adding this to include/image-commands.mk. Can you check if that fixes the issue for you? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] build: make sure that $(STAGING_DIR_IMAGE) exists
Call 'mkdir -p $(STAGING_DIR_IMAGE)' before trying to store files in this potentially non-existing folder. Signed-off-by: Daniel Golle --- include/image-commands.mk | 1 + 1 file changed, 1 insertion(+) diff --git a/include/image-commands.mk b/include/image-commands.mk index 1f6ba1c15a..41e1c96948 100644 --- a/include/image-commands.mk +++ b/include/image-commands.mk @@ -53,6 +53,7 @@ define Build/append-image-stage cp "$(BIN_DIR)/$(DEVICE_IMG_PREFIX)-$(1)" "$@.stripmeta" fwtool -s /dev/null -t "$@.stripmeta" || : fwtool -i /dev/null -t "$@.stripmeta" || : + mkdir -p "$(STAGING_DIR_IMAGE)" dd if="$@.stripmeta" of="$(STAGING_DIR_IMAGE)/$(BOARD)$(if $(SUBTARGET),-$(SUBTARGET))-$(DEVICE_NAME)-$(1)" dd if="$@.stripmeta" >> "$@" rm "$@.stripmeta" -- 2.38.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ramips: use ARTIFACTS for initramfs-factory of I-O DATA WN-AX1167GR
On Tue, Nov 29, 2022 at 09:30:25PM +0900, INAGAKI Hiroshi wrote: > Hi Daniel, > > thank you for your review. > > On 2022/11/29 11:07, Daniel Golle wrote: > > On Wed, Nov 23, 2022 at 12:24:09PM +0900, INAGAKI Hiroshi wrote: > ... > > > @@ -972,10 +955,13 @@ define Device/iodata_wn-ax1167gr > > > $(Device/dsa-migration) > > > $(Device/uimage-lzma-loader) > > > IMAGE_SIZE := 15552k > > > - KERNEL_INITRAMFS := $$(KERNEL) | \ > > > - iodata-factory 7864320 4 0x1055 > > > $(KDIR)/tmp/$$(KERNEL_INITRAMFS_PREFIX)-factory.bin > > > DEVICE_VENDOR := I-O DATA > > > DEVICE_MODEL := WN-AX1167GR > > > +ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),) > > > + ARTIFACTS := initramfs-factory.bin > > > + ARTIFACT/initramfs-factory.bin := append-image initramfs-kernel.bin | \ > > Please use 'append-image-stage' so this will work also with the > > ImageBuilder where initramfs is not being generated/present. > > Oh, I didn't know it. Then, should I remove ifneq-endif switch for IB? Yes, you should also drop the ifneq-endif for IB. > > > > > > + check-size 7680k | senao-header -r 0x30a -p 0x1055 -t 4 > > > +endif > > > DEVICE_PACKAGES := kmod-mt7603 kmod-mt76x2 > > > endef > > > TARGET_DEVICES += iodata_wn-ax1167gr > > > -- > > > 2.36.1.windows.1 > > > > > > > > > ___ > > > openwrt-devel mailing list > > > openwrt-devel@lists.openwrt.org > > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ramips: use ARTIFACTS for initramfs-factory of I-O DATA WN-AX1167GR
On Wed, Nov 23, 2022 at 12:24:09PM +0900, INAGAKI Hiroshi wrote: > Use ARTIFACTS to generate initramfs-based factory image of I-O DATA > WN-AX1167GR instead of redundant recipe which generate on > KERNEL_INITRAMFS. > > Note: > > WN-AX1167GR has 2x OS images on stock firmware. > > stock log: > > flash manufacture id: c2, device id 20 18 > MX25L12805D(c2 2018c220) (16384 Kbytes) > mtd .name = raspi, .size = 0x0100 (16M) .erasesize = 0x0001 (64K) > .numeraseregions = 0 > Creating 10 MTD partitions on "raspi": > 0x-0x0100 : "ALL" > 0x-0x0003 : "Bootloader" > 0x0003-0x0004 : "Config " > 0x0004-0x0005 : "Factory" > 0x0005-0x0006 : "iNIC_rf" > 0x0006-0x007e : "Kernel" > 0x0080-0x00f8 : "app" > 0x00f9-0x00fa : "Key" > 0x00fa-0x00fb : "backup" > 0x00fb-0x0100 : "storage" > > 1st image is "Kernel" and 2nd is "app" when booted from 1st image. > In OpenWrt, those 2x partitions are combined to "firmware" with > undefined (empty) areas (0x7e-0x7f, 0xf8-0xf8). > > The size of an OS image partition is 0x78 (7680 KiB = 7.5 MiB), so > check-size for initramfs-factory image needs to be called with the size. > > Signed-off-by: INAGAKI Hiroshi > --- > target/linux/ramips/image/mt7621.mk | 24 +--- > 1 file changed, 5 insertions(+), 19 deletions(-) > > diff --git a/target/linux/ramips/image/mt7621.mk > b/target/linux/ramips/image/mt7621.mk > index 943fc62ecd..0e3f1cf0f5 100644 > --- a/target/linux/ramips/image/mt7621.mk > +++ b/target/linux/ramips/image/mt7621.mk > @@ -49,23 +49,6 @@ define Build/haier-sim_wr1800k-factory >$(CP) $(1) $(BIN_DIR)/ > endef > > -define Build/iodata-factory > - $(eval fw_size=$(word 1,$(1))) > - $(eval fw_type=$(word 2,$(1))) > - $(eval product=$(word 3,$(1))) > - $(eval factory_bin=$(word 4,$(1))) > - if [ -e $(KDIR)/tmp/$(KERNEL_INITRAMFS_IMAGE) -a "$$(stat -c%s $@)" -lt > "$(fw_size)" ]; then \ > - $(CP) $(KDIR)/tmp/$(KERNEL_INITRAMFS_IMAGE) $(factory_bin); \ > - $(STAGING_DIR_HOST)/bin/mksenaofw \ > - -r 0x30a -p $(product) -t $(fw_type) \ > - -e $(factory_bin) -o $(factory_bin).new; \ > - mv $(factory_bin).new $(factory_bin); \ > - $(CP) $(factory_bin) $(BIN_DIR)/; \ > - else \ > - echo "WARNING: initramfs kernel image too big, cannot generate > factory image (actual $$(stat -c%s $@); max $(fw_size))" >&2; \ > - fi > -endef > - > define Build/iodata-mstc-header > ( \ > data_size_crc="$$(dd if=$@ ibs=64 skip=1 2>/dev/null | gzip -c > | \ > @@ -972,10 +955,13 @@ define Device/iodata_wn-ax1167gr >$(Device/dsa-migration) >$(Device/uimage-lzma-loader) >IMAGE_SIZE := 15552k > - KERNEL_INITRAMFS := $$(KERNEL) | \ > - iodata-factory 7864320 4 0x1055 > $(KDIR)/tmp/$$(KERNEL_INITRAMFS_PREFIX)-factory.bin >DEVICE_VENDOR := I-O DATA >DEVICE_MODEL := WN-AX1167GR > +ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),) > + ARTIFACTS := initramfs-factory.bin > + ARTIFACT/initramfs-factory.bin := append-image initramfs-kernel.bin | \ Please use 'append-image-stage' so this will work also with the ImageBuilder where initramfs is not being generated/present. > + check-size 7680k | senao-header -r 0x30a -p 0x1055 -t 4 > +endif >DEVICE_PACKAGES := kmod-mt7603 kmod-mt76x2 > endef > TARGET_DEVICES += iodata_wn-ax1167gr > -- > 2.36.1.windows.1 > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 3/3] bcm63xx: add support for Tp-Link Archer VR400 v1
The Archer VR400 v1 is an EOL xDSL router with 802.11bgn/802.11ac wifi.
Hardware:
- SoC: Broadcom BCM63167
- CPU: dual core BMIPS4350 V8.0 @400MHz
- RAM: 128 MB DDR2
- Flash: 16 MB SPI NOR
- Ethernet LAN: 3x 100Mbit
- Ethernet WAN: 1x GbE
- Wifi 2.4 GHz: SoC integrated BCM435F 802.11b/g/n
- WiFi 5 GHz: onboard BCM4352 802.11ac
- USB: 1x 2.0
- Buttons: 3x, 1 reset
- LEDs: 10x, all green
Installation via UART serial console and TFTP:
- Configure a static IP on the computer e.g: 192.168.1.7
- Put the openwrt-factory.bin in a TFTP server in the computer
- Power on the router with the serial console connected
- While initializing the bootloader press any key to reach the CLI
- At the CFE command line, execute the command:
f 192.168.1.7:openwrt-factory.bin image
- Wait until it finish.
Back to OEM firmware:
- Stop the bootloader with the serial console
- Flash the OEM firmware using the CFE web UI: http://192.168.1.1
Unsupported:
- xDSL
- Wifi 2.4 GHz
- WiFi 5 GHz, BCM4352, might eventually get basic support.
Signed-off-by: Daniel González Cabanelas
Signed-off-by: Artemii Karavashkin
---
Changes in v2:
- added USB packages.
.../bcm63xx/base-files/etc/board.d/01_leds| 4 +
.../bcm63xx/base-files/etc/board.d/02_network | 4 +
.../dts/bcm63167-tplink-archer-vr400-v1.dts | 177 ++
target/linux/bcm63xx/image/bcm63xx.mk | 14 ++
.../patches-5.10/519-board_bcm63268.patch | 52 -
...31-board_bcm6348-bt-voyager-2500v-bb.patch | 2 +-
.../patches-5.15/519-board_bcm63268.patch | 52 -
...31-board_bcm6348-bt-voyager-2500v-bb.patch | 2 +-
8 files changed, 299 insertions(+), 8 deletions(-)
create mode 100644 target/linux/bcm63xx/dts/bcm63167-tplink-archer-vr400-v1.dts
diff --git a/target/linux/bcm63xx/base-files/etc/board.d/01_leds
b/target/linux/bcm63xx/base-files/etc/board.d/01_leds
index 75e8afef9d..92fb1bc408 100644
--- a/target/linux/bcm63xx/base-files/etc/board.d/01_leds
+++ b/target/linux/bcm63xx/base-files/etc/board.d/01_leds
@@ -94,6 +94,10 @@ sercomm,h500-s-vfes)
telsey,cpva502plus)
ucidef_set_led_netdev "lan" "LAN" "amber:link" "eth0"
;;
+tplink,archer-vr400-v1)
+ ucidef_set_led_netdev "wan" "WAN" "green:wan" "eth0.2"
+ ucidef_set_led_usbdev "usb" "USB" "green:usb" "1-1"
+ ;;
esac
board_config_flush
diff --git a/target/linux/bcm63xx/base-files/etc/board.d/02_network
b/target/linux/bcm63xx/base-files/etc/board.d/02_network
index b48aa57d2e..32547bf448 100644
--- a/target/linux/bcm63xx/base-files/etc/board.d/02_network
+++ b/target/linux/bcm63xx/base-files/etc/board.d/02_network
@@ -159,6 +159,10 @@ sky,sr102)
ucidef_add_switch "switch0" \
"0:lan" "1:lan" "2:lan" "3:wan" "8t@eth0"
;;
+tplink,archer-vr400-v1)
+ ucidef_add_switch "switch0" \
+ "0:lan:3" "1:lan:2" "2:lan:1" "3:wan" "8t@eth0"
+ ;;
*)
ucidef_set_interfaces_lan_wan "eth1" "eth0"
;;
diff --git a/target/linux/bcm63xx/dts/bcm63167-tplink-archer-vr400-v1.dts
b/target/linux/bcm63xx/dts/bcm63167-tplink-archer-vr400-v1.dts
new file mode 100644
index 00..a3dbca7d78
--- /dev/null
+++ b/target/linux/bcm63xx/dts/bcm63167-tplink-archer-vr400-v1.dts
@@ -0,0 +1,177 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Device Tree file for TP-Link Archer VR400 v1
+ *
+ * Copyright (C) 2022 Daniel González Cabanelas
+ * Copyright (C) 2022 Artemii Karavashkin
+ */
+
+#include "bcm63268.dtsi"
+
+#include
+#include
+
+/ {
+ model = "TP-Link Archer VR400 v1";
+ compatible = "tplink,archer-vr400-v1", "brcm,bcm63167", "brcm,bcm63268";
+
+ aliases {
+ led-boot = _power_green;
+ led-failsafe = _power_green;
+ led-running = _power_green;
+ led-upgrade = _power_green;
+ };
+
+ chosen {
+ bootargs = "rootfstype=squashfs,jffs2 noinitrd
console=ttyS0,115200";
+ stdout-path = "serial0:115200n8";
+ };
+
+ keys {
+ compatible = "gpio-keys";
+
+ reset {
+ label = "reset";
+ gpios = < 32 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ debounce-interval = <60>;
+ };
+
+ wps {
+ label = "wps";
+ gpios = < 33 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ debounce-interval = <60>;
+ };
+
+ rfkill {
+ label
[PATCH v2 2/3] bcm63xx: build tplink images
Add macros and a python script to build images compatible with tplink
CFE bootloaders.
Signed-off-by: Daniel González Cabanelas
---
Changes in v2:
- factory image fixed. (cfe-tplink-crcfix.py doesn't work if CFE
already prepended)
scripts/cfe-tplink-crcfix.py | 48 +++
target/linux/bcm63xx/image/Makefile | 23 +
target/linux/bcm63xx/image/bcm63xx.mk | 19 +++
3 files changed, 90 insertions(+)
create mode 100755 scripts/cfe-tplink-crcfix.py
diff --git a/scripts/cfe-tplink-crcfix.py b/scripts/cfe-tplink-crcfix.py
new file mode 100755
index 00..2db6d6cce9
--- /dev/null
+++ b/scripts/cfe-tplink-crcfix.py
@@ -0,0 +1,48 @@
+#!/usr/bin/python3
+# SPDX-License-Identifier: GPL-2.0-or-later
+#
+# Copyright (C) 2022 OpenWrt.org, based on cameo-tag.py
+#
+# this tool fixes the CRC32 (kernel+rootfs) found in CFE headers from
+# Tp-Link bcm63xx devices. It doesn't recalculate header checksums
+# since CFE doesn't make any header integrity verification to boot OpenWrt.
+
+import argparse
+import os
+import struct
+import zlib
+
+READ_UNTIL_EOF = -1
+CFE_HEADER_SIZE = 512
+
+def read_buffer(offset, count):
+args.cfeimage_file.seek(offset)
+return bytearray(args.cfeimage_file.read(count))
+
+def write_buffer(whence, buf):
+args.cfeimage_file.seek(0, whence)
+args.cfeimage_file.write(buf)
+
+def invertcrc(buf):
+return (zlib.crc32(buf) ^ 0x).to_bytes(4, 'big')
+
+def checksum_header(buf):
+BINCRC32 = args.crc_offset
+ROOTFSADDRESS = buf[124:128]
+ROOTFSLEN = buf[128:132]
+IMLEN = struct.unpack('>i', ROOTFSADDRESS)[0] + struct.unpack('>i',
ROOTFSLEN)[0] + CFE_HEADER_SIZE
+buf[BINCRC32:BINCRC32+4] = invertcrc(buf[CFE_HEADER_SIZE:IMLEN])
+return buf
+
+parser = argparse.ArgumentParser(description='Insert CRC in tplink CFE
firmware tags.')
+parser.add_argument('cfeimage_file', type=argparse.FileType('r+b'))
+# crc_offset should be 148 or 152
+parser.add_argument('crc_offset', type=int)
+args = parser.parse_args()
+
+args.cfeimage_file.seek(0, os.SEEK_END)
+if args.cfeimage_file.tell() <= CFE_HEADER_SIZE:
+raise ValueError(f"CFE image must be larger than {CFE_HEADER_SIZE} bytes")
+
+buf = checksum_header(read_buffer(0, READ_UNTIL_EOF))
+write_buffer(os.SEEK_SET, buf)
diff --git a/target/linux/bcm63xx/image/Makefile
b/target/linux/bcm63xx/image/Makefile
index f35358173c..cbd0f7787d 100644
--- a/target/linux/bcm63xx/image/Makefile
+++ b/target/linux/bcm63xx/image/Makefile
@@ -143,6 +143,15 @@ define Build/cfe-jffs2-cferam
rm -f $@.kernel
endef
+define Build/cfe-kernel-header
+ $(TOPDIR)/scripts/cfe-bin-header.py \
+ --input-file $@ \
+ --output-file $@-tmp \
+ --load-addr $(if
$(DEVICE_LOADADDR),$(DEVICE_LOADADDR),$(LOADER_ENTRY)) \
+ --entry-addr $(if
$(DEVICE_LOADADDR),$(DEVICE_LOADADDR),$(LOADER_ENTRY))
+ mv $@-tmp $@
+endef
+
define Build/cfe-jffs2-kernel
rm -rf $@-kernel
mkdir -p $@-kernel
@@ -274,6 +283,20 @@ define Build/zyxel-bin
mv $@.zyxel $@
endef
+define Build/tplink-prepend-cfe
+ dd if=$(KDIR)/bcm63xx-cfe/$(CFE_BIN_FILE) bs=128k conv=sync
of=cfeprepend.bin
+ dd if=$@ >> cfeprepend.bin
+ mv cfeprepend.bin $@
+endef
+
+define Build/tplink-sysupgrade
+ # append 512 bytes to avoid computing CRC for data beyond jffs2 EOF mark
+ dd if=/dev/null bs=512 count=1 >> $(IMAGE_ROOTFS)
+ $(call Build/tplink-v2-image, -v 0.9.1 -s)
+ # insert ~CRC32 (rootfs+kernel) to allow CFE booting Openwrt
+ $(TOPDIR)/scripts/cfe-tplink-crcfix.py $@ $(TPLINK_CRC_OFFSET)
+endef
+
define Build/redboot-bin
# Prepare kernel and rootfs
dd if=$(IMAGE_KERNEL) of=$(BIN_DIR)/$(REDBOOT_PREFIX)-vmlinux.gz
bs=65536 conv=sync
diff --git a/target/linux/bcm63xx/image/bcm63xx.mk
b/target/linux/bcm63xx/image/bcm63xx.mk
index 97959d7819..bbf4da6505 100644
--- a/target/linux/bcm63xx/image/bcm63xx.mk
+++ b/target/linux/bcm63xx/image/bcm63xx.mk
@@ -5,9 +5,12 @@
DEVICE_VARS += HCS_MAGIC_BYTES HCS_REV_MIN HCS_REV_MAJ
DEVICE_VARS += BLOCK_SIZE FLASH_MB IMAGE_OFFSET
+DEVICE_VARS += CFE_BIN_FILE
DEVICE_VARS += CFE_BOARD_ID CFE_EXTRAS
DEVICE_VARS += NETGEAR_BOARD_ID NETGEAR_REGION
DEVICE_VARS += REDBOOT_PREFIX
+DEVICE_VARS += TPLINK_HWID TPLINK_HWREV TPLINK_FLASHLAYOUT
+DEVICE_VARS += TPLINK_HWREVADD TPLINK_HVERSION TPLINK_CRC_OFFSET
define Device/bcm33xx
KERNEL_INITRAMFS := kernel-bin | append-dtb | lzma | loader-lzma bin |
hcs-initramfs
@@ -59,6 +62,22 @@ define Device/bcm63xx_redboot
REDBOOT_PREFIX := $$(DEVICE_IMG_PREFIX)
endef
+define Device/bcm63xx_tplink
+ FILESYSTEMS := squashfs
+ DEVICE_VENDOR := TP-Link
+ TPLINK_HWID := 0x0
+ TPLINK_HWREV := 0x1
+ TPLINK_HWREVADD := 0x0
+ TPLINK_HVERSION := 3
+ TPLINK_FLASHLAYOUT :=
+ TPLINK_CRC_OFFSET := 152
+ CFE_BIN_FILE :=
+ KERNEL := kernel-bin | append-dtb
[PATCH v2 1/3] bcm63xx: kernel: enable the tplink image parser
Enable the tplink mtd firmware splitter to allow booting images with tplink headers. Since known devices with these headers are dual core, only enable this driver in the SMP subtarget. Signed-off-by: Daniel González Cabanelas --- Changes in v2: no changes target/linux/bcm63xx/smp/config-default | 1 + 1 file changed, 1 insertion(+) diff --git a/target/linux/bcm63xx/smp/config-default b/target/linux/bcm63xx/smp/config-default index a6eae6e41d..b09989da70 100644 --- a/target/linux/bcm63xx/smp/config-default +++ b/target/linux/bcm63xx/smp/config-default @@ -39,3 +39,4 @@ CONFIG_ZLIB_DEFLATE=y CONFIG_ZLIB_INFLATE=y CONFIG_ZSTD_COMPRESS=y CONFIG_ZSTD_DECOMPRESS=y +CONFIG_MTD_SPLIT_TPLINK_FW=y -- 2.38.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Add swig/host build dependency [Was: Re: [PATCH] uboot-mediatek: clean up build dependencies]
On Fri, Nov 18, 2022 at 09:38:55AM -0500, Peter Naulls wrote: > On 11/17/22 14:33, Petr Štetiar wrote: > > Daniel Golle [2022-11-17 17:01:43]: > > > > Hi, > > > > > Add swig/host to build dependencies. > > > > this doesn't looks like a cleanup as commit subject suggests, but rather > > contrary :-) > > Thanks all in any case for looking at this. We have a possible need to modify > our vendor (or vendor's vendor, hard to be sure) U-Boot. On our MT7621 > boards we have vendor versions 2.0.0 aka Ralink version 2.0.0 and 1.1.3 aka > Ralink > version 4.3.0.0. And I have the Mediatek SDK with source for what claims to > be version 5.0.0.0. > > Attempts to clarify with the vendor what's going on or get exact sources > or history have proven challenging due to timezones and language barriers, > and I think they simply may not know. > > Obviously using the OpenWrt version is going to be probably more satisfactory, > although there may well be vendor changes to support MCU etc. > > It's been many many years since I did u-boot work, but is there some magic to > load u-boot image into RAM on mt7621 and run it to try it out before flashing? > I know there are configuration options for DDR and CPU frequency, etc, but > tftping the u-boot binaries variously and using 'go' result in an apparently > stopped system. @lynxis has done this on Aarch64 MediaTek SoC just a few days ago and wrote a nice blog post summarizing the process. Probably most of it is the same on MIPS-based targets: https://lunarius.fe80.eu/blog/openwrt-u-boot-boot-u-boot.html > > This is the only meaningful documentation I have found. > > https://u-boot.readthedocs.io/en/latest/board/mediatek/mt7621.html > > Thanks! > > > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] uboot-mediatek: clean up build dependencies
Conditionally depend on arm-trusted-firmware-tools as it is only needed on Cortex-A based systems, hence do not depend on it when building for MIPSel based SoCs. Add swig/host to build dependencies. Reported-by: Peter Naulls Signed-off-by: Daniel Golle --- package/boot/uboot-mediatek/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/boot/uboot-mediatek/Makefile b/package/boot/uboot-mediatek/Makefile index 9d823ec698..cab5c83f3e 100644 --- a/package/boot/uboot-mediatek/Makefile +++ b/package/boot/uboot-mediatek/Makefile @@ -3,7 +3,7 @@ include $(INCLUDE_DIR)/kernel.mk PKG_VERSION:=2022.10 PKG_HASH:=50b4482a505bc281ba8470c399a3c26e145e29b23500bc35c50debd7fa46bdf8 -PKG_BUILD_DEPENDS:=arm-trusted-firmware-tools/host +PKG_BUILD_DEPENDS:=!TARGET_ramips:arm-trusted-firmware-tools/host swig/host include $(INCLUDE_DIR)/u-boot.mk include $(INCLUDE_DIR)/package.mk -- 2.38.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 2/3] bcm63xx: build tplink images
Add macros and a python script to build images compatible with tplink
CFE bootloaders.
Signed-off-by: Daniel González Cabanelas
---
scripts/cfe-tplink-crcfix.py | 48 +++
target/linux/bcm63xx/image/Makefile | 21
target/linux/bcm63xx/image/bcm63xx.mk | 19 +++
3 files changed, 88 insertions(+)
create mode 100755 scripts/cfe-tplink-crcfix.py
diff --git a/scripts/cfe-tplink-crcfix.py b/scripts/cfe-tplink-crcfix.py
new file mode 100755
index 00..2db6d6cce9
--- /dev/null
+++ b/scripts/cfe-tplink-crcfix.py
@@ -0,0 +1,48 @@
+#!/usr/bin/python3
+# SPDX-License-Identifier: GPL-2.0-or-later
+#
+# Copyright (C) 2022 OpenWrt.org, based on cameo-tag.py
+#
+# this tool fixes the CRC32 (kernel+rootfs) found in CFE headers from
+# Tp-Link bcm63xx devices. It doesn't recalculate header checksums
+# since CFE doesn't make any header integrity verification to boot OpenWrt.
+
+import argparse
+import os
+import struct
+import zlib
+
+READ_UNTIL_EOF = -1
+CFE_HEADER_SIZE = 512
+
+def read_buffer(offset, count):
+args.cfeimage_file.seek(offset)
+return bytearray(args.cfeimage_file.read(count))
+
+def write_buffer(whence, buf):
+args.cfeimage_file.seek(0, whence)
+args.cfeimage_file.write(buf)
+
+def invertcrc(buf):
+return (zlib.crc32(buf) ^ 0x).to_bytes(4, 'big')
+
+def checksum_header(buf):
+BINCRC32 = args.crc_offset
+ROOTFSADDRESS = buf[124:128]
+ROOTFSLEN = buf[128:132]
+IMLEN = struct.unpack('>i', ROOTFSADDRESS)[0] + struct.unpack('>i',
ROOTFSLEN)[0] + CFE_HEADER_SIZE
+buf[BINCRC32:BINCRC32+4] = invertcrc(buf[CFE_HEADER_SIZE:IMLEN])
+return buf
+
+parser = argparse.ArgumentParser(description='Insert CRC in tplink CFE
firmware tags.')
+parser.add_argument('cfeimage_file', type=argparse.FileType('r+b'))
+# crc_offset should be 148 or 152
+parser.add_argument('crc_offset', type=int)
+args = parser.parse_args()
+
+args.cfeimage_file.seek(0, os.SEEK_END)
+if args.cfeimage_file.tell() <= CFE_HEADER_SIZE:
+raise ValueError(f"CFE image must be larger than {CFE_HEADER_SIZE} bytes")
+
+buf = checksum_header(read_buffer(0, READ_UNTIL_EOF))
+write_buffer(os.SEEK_SET, buf)
diff --git a/target/linux/bcm63xx/image/Makefile
b/target/linux/bcm63xx/image/Makefile
index f35358173c..58accf20b8 100644
--- a/target/linux/bcm63xx/image/Makefile
+++ b/target/linux/bcm63xx/image/Makefile
@@ -143,6 +143,15 @@ define Build/cfe-jffs2-cferam
rm -f $@.kernel
endef
+define Build/cfe-kernel-header
+ $(TOPDIR)/scripts/cfe-bin-header.py \
+ --input-file $@ \
+ --output-file $@-tmp \
+ --load-addr $(if
$(DEVICE_LOADADDR),$(DEVICE_LOADADDR),$(LOADER_ENTRY)) \
+ --entry-addr $(if
$(DEVICE_LOADADDR),$(DEVICE_LOADADDR),$(LOADER_ENTRY))
+ mv $@-tmp $@
+endef
+
define Build/cfe-jffs2-kernel
rm -rf $@-kernel
mkdir -p $@-kernel
@@ -274,6 +283,18 @@ define Build/zyxel-bin
mv $@.zyxel $@
endef
+define Build/tplink-append-cfe
+ dd if=$(KDIR)/bcm63xx-cfe/$(CFE_BIN_FILE) bs=128k conv=sync >> $@
+endef
+
+define Build/tplink-sysupgrade
+ # append 512 bytes to avoid computing CRC for data beyond jffs2 EOF mark
+ dd if=/dev/null bs=512 count=1 >> $(IMAGE_ROOTFS)
+ $(call Build/tplink-v2-image, -v 0.9.1 -s)
+ # insert ~CRC32 (rootfs+kernel) to allow CFE booting Openwrt
+ $(TOPDIR)/scripts/cfe-tplink-crcfix.py $@ $(TPLINK_CRC_OFFSET)
+endef
+
define Build/redboot-bin
# Prepare kernel and rootfs
dd if=$(IMAGE_KERNEL) of=$(BIN_DIR)/$(REDBOOT_PREFIX)-vmlinux.gz
bs=65536 conv=sync
diff --git a/target/linux/bcm63xx/image/bcm63xx.mk
b/target/linux/bcm63xx/image/bcm63xx.mk
index 97959d7819..7c2d4c53e5 100644
--- a/target/linux/bcm63xx/image/bcm63xx.mk
+++ b/target/linux/bcm63xx/image/bcm63xx.mk
@@ -5,9 +5,12 @@
DEVICE_VARS += HCS_MAGIC_BYTES HCS_REV_MIN HCS_REV_MAJ
DEVICE_VARS += BLOCK_SIZE FLASH_MB IMAGE_OFFSET
+DEVICE_VARS += CFE_BIN_FILE
DEVICE_VARS += CFE_BOARD_ID CFE_EXTRAS
DEVICE_VARS += NETGEAR_BOARD_ID NETGEAR_REGION
DEVICE_VARS += REDBOOT_PREFIX
+DEVICE_VARS += TPLINK_HWID TPLINK_HWREV TPLINK_FLASHLAYOUT
+DEVICE_VARS += TPLINK_HWREVADD TPLINK_HVERSION TPLINK_CRC_OFFSET
define Device/bcm33xx
KERNEL_INITRAMFS := kernel-bin | append-dtb | lzma | loader-lzma bin |
hcs-initramfs
@@ -59,6 +62,22 @@ define Device/bcm63xx_redboot
REDBOOT_PREFIX := $$(DEVICE_IMG_PREFIX)
endef
+define Device/bcm63xx_tplink
+ FILESYSTEMS := squashfs
+ DEVICE_VENDOR := TP-Link
+ TPLINK_HWID := 0x0
+ TPLINK_HWREV := 0x1
+ TPLINK_HWREVADD := 0x0
+ TPLINK_HVERSION := 3
+ TPLINK_FLASHLAYOUT :=
+ TPLINK_CRC_OFFSET := 152
+ CFE_BIN_FILE :=
+ KERNEL := kernel-bin | append-dtb | relocate-kernel | lzma |
cfe-kernel-header
+ IMAGES := factory.bin sysupgrade.bin
+ IMAGE/sysupgrade.bin := tplink-sysupgrade
+ IMAGE/factory.bin := tplink-append-cfe | tplink-s
[PATCH 3/3] bcm63xx: add support for Tp-Link Archer VR400 v1
The Archer VR400 v1 is an EOL xDSL router with 802.11bgn/802.11ac wifi.
Hardware:
- SoC: Broadcom BCM63167
- CPU: dual core BMIPS4350 V8.0 @400MHz
- RAM: 128 MB DDR2
- Flash: 16 MB SPI NOR
- Ethernet LAN: 3x 100Mbit
- Ethernet WAN: 1x GbE
- Wifi 2.4 GHz: SoC integrated BCM435F 802.11b/g/n
- WiFi 5 GHz: onboard BCM4352 802.11ac
- Buttons: 3x, 1 reset
- LEDs: 10x, all green
Installation via UART serial console and TFTP:
- Configure a static IP on the computer e.g: 192.168.1.7
- Put the openwrt-factory.bin in a TFTP server in the computer
- Power on the router with the serial console connected
- While initializing the bootloader press any key to reach the CLI
- At the CFE command line, execute the command:
f 192.168.1.7:openwrt-factory.bin image
- Wait until it finish.
Back to OEM firmware:
- Stop the bootloader with the serial console
- Flash the OEM firmware using the CFE web UI: http://192.168.1.1
Unsupported:
- xDSL
- Wifi 2.4 GHz
- WiFi 5 GHz, BCM4352, might eventually get basic support.
Signed-off-by: Daniel González Cabanelas
Signed-off-by: Artemii Karavashkin
---
.../bcm63xx/base-files/etc/board.d/01_leds| 4 +
.../bcm63xx/base-files/etc/board.d/02_network | 4 +
.../dts/bcm63167-tplink-archer-vr400-v1.dts | 177 ++
target/linux/bcm63xx/image/bcm63xx.mk | 13 ++
.../patches-5.10/519-board_bcm63268.patch | 52 -
...31-board_bcm6348-bt-voyager-2500v-bb.patch | 2 +-
.../patches-5.15/519-board_bcm63268.patch | 52 -
...31-board_bcm6348-bt-voyager-2500v-bb.patch | 2 +-
8 files changed, 298 insertions(+), 8 deletions(-)
create mode 100644 target/linux/bcm63xx/dts/bcm63167-tplink-archer-vr400-v1.dts
diff --git a/target/linux/bcm63xx/base-files/etc/board.d/01_leds
b/target/linux/bcm63xx/base-files/etc/board.d/01_leds
index 75e8afef9d..92fb1bc408 100644
--- a/target/linux/bcm63xx/base-files/etc/board.d/01_leds
+++ b/target/linux/bcm63xx/base-files/etc/board.d/01_leds
@@ -94,6 +94,10 @@ sercomm,h500-s-vfes)
telsey,cpva502plus)
ucidef_set_led_netdev "lan" "LAN" "amber:link" "eth0"
;;
+tplink,archer-vr400-v1)
+ ucidef_set_led_netdev "wan" "WAN" "green:wan" "eth0.2"
+ ucidef_set_led_usbdev "usb" "USB" "green:usb" "1-1"
+ ;;
esac
board_config_flush
diff --git a/target/linux/bcm63xx/base-files/etc/board.d/02_network
b/target/linux/bcm63xx/base-files/etc/board.d/02_network
index b48aa57d2e..32547bf448 100644
--- a/target/linux/bcm63xx/base-files/etc/board.d/02_network
+++ b/target/linux/bcm63xx/base-files/etc/board.d/02_network
@@ -159,6 +159,10 @@ sky,sr102)
ucidef_add_switch "switch0" \
"0:lan" "1:lan" "2:lan" "3:wan" "8t@eth0"
;;
+tplink,archer-vr400-v1)
+ ucidef_add_switch "switch0" \
+ "0:lan:3" "1:lan:2" "2:lan:1" "3:wan" "8t@eth0"
+ ;;
*)
ucidef_set_interfaces_lan_wan "eth1" "eth0"
;;
diff --git a/target/linux/bcm63xx/dts/bcm63167-tplink-archer-vr400-v1.dts
b/target/linux/bcm63xx/dts/bcm63167-tplink-archer-vr400-v1.dts
new file mode 100644
index 00..a3dbca7d78
--- /dev/null
+++ b/target/linux/bcm63xx/dts/bcm63167-tplink-archer-vr400-v1.dts
@@ -0,0 +1,177 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Device Tree file for TP-Link Archer VR400 v1
+ *
+ * Copyright (C) 2022 Daniel González Cabanelas
+ * Copyright (C) 2022 Artemii Karavashkin
+ */
+
+#include "bcm63268.dtsi"
+
+#include
+#include
+
+/ {
+ model = "TP-Link Archer VR400 v1";
+ compatible = "tplink,archer-vr400-v1", "brcm,bcm63167", "brcm,bcm63268";
+
+ aliases {
+ led-boot = _power_green;
+ led-failsafe = _power_green;
+ led-running = _power_green;
+ led-upgrade = _power_green;
+ };
+
+ chosen {
+ bootargs = "rootfstype=squashfs,jffs2 noinitrd
console=ttyS0,115200";
+ stdout-path = "serial0:115200n8";
+ };
+
+ keys {
+ compatible = "gpio-keys";
+
+ reset {
+ label = "reset";
+ gpios = < 32 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ debounce-interval = <60>;
+ };
+
+ wps {
+ label = "wps";
+ gpios = < 33 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ debounce-interval = <60>;
+ };
+
+ rfkill {
+ label = "rfkill";
+ gpios = &l
[PATCH 1/3] bcm63xx: kernel: enable the tplink image parser
Enable the tplink mtd firmware splitter to allow booting images with tplink headers. Since known devices with these headers are dual core, only enable this driver in the SMP subtarget. Signed-off-by: Daniel González Cabanelas --- target/linux/bcm63xx/smp/config-default | 1 + 1 file changed, 1 insertion(+) diff --git a/target/linux/bcm63xx/smp/config-default b/target/linux/bcm63xx/smp/config-default index a6eae6e41d..b09989da70 100644 --- a/target/linux/bcm63xx/smp/config-default +++ b/target/linux/bcm63xx/smp/config-default @@ -39,3 +39,4 @@ CONFIG_ZLIB_DEFLATE=y CONFIG_ZLIB_INFLATE=y CONFIG_ZSTD_COMPRESS=y CONFIG_ZSTD_DECOMPRESS=y +CONFIG_MTD_SPLIT_TPLINK_FW=y -- 2.38.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
bcm63xx: kernel: fix up bcm63268 roboswitch gpio registers
Some BCM63268 bootloaders may leave gpio registers (related to the
roboswitch) disabled before loading the OpenWrt firmware. As result of
this, the switch won't work.
These registers, if not enabled, probably avoid forwarding packets.
Fix it.
Signed-off-by: Daniel González Cabanelas
---
...IPS-BCM63XX-add-support-for-BCM63268.patch | 51 +++
...MIPS-BCM63XX-add-support-for-BCM6318.patch | 10 ++--
...BCM63XX-add-PCIe-support-for-BCM6318.patch | 10 ++--
...-MIPS-BCM63XX-USB-ENETSW-6318-clocks.patch | 4 +-
.../347-MIPS-BCM6318-USB-support.patch| 4 +-
...-MIPS-BCM63XX-fix-BCM63268-USB-clock.patch | 6 +--
...IPS-BCM63XX-add-BCM63268-USB-support.patch | 2 +-
...X-add-clkdev-lookups-for-device-tree.patch | 20
...enable-rgmii-clock-on-external-ports.patch | 2 +-
...CM63XX-Register-SPI-flash-if-present.patch | 2 +-
.../430-MIPS-BCM63XX-add-nand-clocks.patch| 8 +--
.../431-MIPS-BCM63XX-add-nand-rset.patch | 2 +-
...IPS-BCM63XX-add-support-for-BCM63268.patch | 51 +++
...MIPS-BCM63XX-add-support-for-BCM6318.patch | 10 ++--
...BCM63XX-add-PCIe-support-for-BCM6318.patch | 10 ++--
...-MIPS-BCM63XX-USB-ENETSW-6318-clocks.patch | 4 +-
.../347-MIPS-BCM6318-USB-support.patch| 4 +-
...-MIPS-BCM63XX-fix-BCM63268-USB-clock.patch | 6 +--
...IPS-BCM63XX-add-BCM63268-USB-support.patch | 2 +-
...X-add-clkdev-lookups-for-device-tree.patch | 20
...enable-rgmii-clock-on-external-ports.patch | 2 +-
...CM63XX-Register-SPI-flash-if-present.patch | 2 +-
.../430-MIPS-BCM63XX-add-nand-clocks.patch| 8 +--
.../431-MIPS-BCM63XX-add-nand-rset.patch | 2 +-
24 files changed, 154 insertions(+), 88 deletions(-)
diff --git
a/target/linux/bcm63xx/patches-5.10/339-MIPS-BCM63XX-add-support-for-BCM63268.patch
b/target/linux/bcm63xx/patches-5.10/339-MIPS-BCM63XX-add-support-for-BCM63268.patch
index 84209d6e3b..0f59d57f1e 100644
---
a/target/linux/bcm63xx/patches-5.10/339-MIPS-BCM63XX-add-support-for-BCM63268.patch
+++
b/target/linux/bcm63xx/patches-5.10/339-MIPS-BCM63XX-add-support-for-BCM63268.patch
@@ -46,16 +46,37 @@ Signed-off-by: Jonas Gorski
val = bcm_mpi_readl(MPI_CSBASE_REG(0));
--- a/arch/mips/bcm63xx/clk.c
+++ b/arch/mips/bcm63xx/clk.c
-@@ -169,6 +169,8 @@ static void enetsw_set(struct clk *clk,
+@@ -52,6 +52,18 @@ static void bcm_hwclock_set(u32 mask, in
+ bcm_perf_writel(reg, PERF_CKCTL_REG);
+ }
+
++static void bcm_gpiorobosw_set(u32 mask, int enable)
++{
++ u32 reg;
++
++ reg = bcm_gpio_readl(GPIO_ROBOSW_SW_CTRL_REG);
++ if (enable)
++ reg |= mask;
++ else
++ reg &= ~mask;
++ bcm_gpio_writel(reg, GPIO_ROBOSW_SW_CTRL_REG);
++}
++
+ /*
+ * Ethernet MAC "misc" clock: dma clocks and main clock on 6348
+ */
+@@ -169,6 +181,10 @@ static void enetsw_set(struct clk *clk,
clk_disable_unlocked(_swpkt_sar);
}
bcm_hwclock_set(CKCTL_6368_ROBOSW_EN, enable);
+ } else if (BCMCPU_IS_63268()) {
++ bcm_gpiorobosw_set(GPIO_ROBOSW_MII_DUMB_FWDG_EN |
++ GPIO_ROBOSW_HW_FWDG_EN, enable);
+ bcm_hwclock_set(CKCTL_63268_ROBOSW_EN, enable);
} else {
return;
}
-@@ -214,6 +216,8 @@ static void usbh_set(struct clk *clk, in
+@@ -214,6 +230,8 @@ static void usbh_set(struct clk *clk, in
bcm_hwclock_set(CKCTL_6362_USBH_EN, enable);
else if (BCMCPU_IS_6368())
bcm_hwclock_set(CKCTL_6368_USBH_EN, enable);
@@ -64,7 +85,7 @@ Signed-off-by: Jonas Gorski
else
return;
-@@ -236,6 +240,8 @@ static void usbd_set(struct clk *clk, in
+@@ -236,6 +254,8 @@ static void usbd_set(struct clk *clk, in
bcm_hwclock_set(CKCTL_6362_USBD_EN, enable);
else if (BCMCPU_IS_6368())
bcm_hwclock_set(CKCTL_6368_USBD_EN, enable);
@@ -73,7 +94,7 @@ Signed-off-by: Jonas Gorski
else
return;
-@@ -262,9 +268,13 @@ static void spi_set(struct clk *clk, int
+@@ -262,9 +282,13 @@ static void spi_set(struct clk *clk, int
mask = CKCTL_6358_SPI_EN;
else if (BCMCPU_IS_6362())
mask = CKCTL_6362_SPI_EN;
@@ -89,7 +110,7 @@ Signed-off-by: Jonas Gorski
bcm_hwclock_set(mask, enable);
}
-@@ -283,6 +293,8 @@ static void hsspi_set(struct clk *clk, i
+@@ -283,6 +307,8 @@ static void hsspi_set(struct clk *clk, i
mask = CKCTL_6328_HSSPI_EN;
else if (BCMCPU_IS_6362())
mask = CKCTL_6362_HSSPI_EN;
@@ -98,7 +119,7 @@ Signed-off-by: Jonas Gorski
else
return;
-@@ -352,6 +364,8 @@ static void pcie_set(struct clk *clk, in
+@@ -352,6 +378,8 @@ static void pcie_set(struct clk *clk, in
bcm_hwclock_set(CKCTL_6328_PCIE_EN, enable);
else if (BCMCPU_IS_6362())
bcm_hwclock_set(CKCT
Re: [PATCH] procd: jail/jail: correctly check for null pointer
On Tue, Nov 08, 2022 at 02:26:47PM +, Philipp Meier 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: Tue, 8 Nov 2022 14:26:47 +
> From: Philipp Meier
> To: John Crispin
> CC: "openwrt-devel@lists.openwrt.org"
> Subject: [PATCH] procd: jail/jail: correctly check for null pointer
>
> Author: Philipp Meier
> Date: Tue Nov 8 14:38:37 2022 +0100
This looks like the output of `git show`.
Please use `git format-patch` or `git send-email` in future.
>
> procd: jail/jail: correctly check for null pointer
>
> Handle case where opts.sysctl is not used.
>
> Signed-off-by: Philipp Meier
I've cleaned and picked up your patch, thank you!
>
> diff --git a/jail/jail.c b/jail/jail.c
> index ce6b268..31b64e5 100644
> --- a/jail/jail.c
> +++ b/jail/jail.c
> @@ -215,6 +215,10 @@ static void free_hooklist(struct hook_execvpe **hooklist)
>
> static void free_sysctl(void) {
> struct sysctl_val *cur;
> +
> + if (!opts.sysctl)
> + return;
> +
The patch somehow got white-space mangled (tabs got converted to spaces),
probably by copy & pasting it into some MUA. If you really have no way to
use `git send-email` and also importing a draft email created using
`git format-patch` cannot work for you, please attach the file created
by `git format-patch`. Using copy & paste will *always* create a lot of
extra work, because one then has to apply the patch manually (which is also
error-prone and should be avoided).
> cur = *opts.sysctl;
>
> while (cur) {
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
