Re: [PATCH 1/2] realtek/rtl839x: respect phy-is-integrated property

[Daniel Golle]

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

[Daniel Golle]

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

[Daniel Golle]

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

[Daniel Golle]

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

[Daniel Golle]

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)

[Daniel Golle]

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

[Daniel Golle]

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)

[Daniel Golle]

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)

[Daniel Golle]

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?

[Daniel Golle]

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?

[Daniel Golle]

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?

[Daniel Golle]

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

[Daniel Golle]

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

[Daniel Golle]

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?

[Daniel Golle]

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)

[Daniel Golle]

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: OpenWrt One - celebrating 20 years of OpenWrt

[Daniel Golle]

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

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

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

Re: OpenWrt One - celebrating 20 years of OpenWrt

[Daniel Golle]

Hi!

On Wed, Jan 10, 2024 at 11:47:08AM +0100, Bjørn Mork wrote:
> John Crispin  writes:
> 
> > At the beginning we focused on the most powerful (and
> > expensive) configurations possible but finally ended up with something
> > rather simple and above all,feasible.
> 
> That's a very wise choice. And most of the compromises make sense to
> me. Except the
> 
> > * Storage: M.2 2042 for NVMe SSD (PCIe gen 2 x1)
> 
> This seems like a strange priority for an OpenWrt device.  It's not
> useful to most OpenWrt users or applications.  Having two different boot
> devices is more than enough.
> 
> > * What will the M.2 slot be used for?
> > - we will use M.2 with M-key for NVMe storage. There is a
> >   work-in-progress patch to make PCIe work inside the U-Boot
> >   bootloader. This will allow booting other Linux distributions such
> >   as Debian and Alpine directly from NVMe
> 
> And you even make a point of it being more suitable for other Linux
> distros. That should not be an OpenWrt priority.
> 
> > * Why is there no USB 3.x host port on the device?
> > - the USB 3.x and PCIe buses are shared in the selected SoC silicon,
> >   hence only a single High-Speed USB port is available
> 
> And here's the biggest problem with that choice.  USB3 would have
> allowed storage expansion as well as more OpenWrt applicable use cases
> like additional ethernet adapters or modems.  And with a limited
> connector and board space cost compared to an m.2 slot.  The USB A
> port is already there.

Regarding all of the above: exposing the PCIe lane gives you the biggest
possible flexibility. If you want USB 3 you can use an adapter like this:
https://www.delock.com/produkt/63174/merkmale.html

Including USB 3 will significantly increase the cost of the design not
because of connectors, but because of the interference problems we will
have to deal with and somehow mitigate (and the smaller the board the
harder that will get). I've seen too many devices with such problems
and only very few manage to have well-working 2.4 GHz Wi-Fi next to
a USB 3 host.

> 
> > * What is the purpose of the console USB-C port?
> > - Holtek UART to USB bridge with CDC-ACM support on USB-C makes the
> >   device ultra easy to communicate with. No extra hardware or drivers
> >   will be required. Android for example has CDC-ACM support enabled by
> >  default
> 
> This is nice. But how about making it a real advantage over the
> traditional 4 pin header?  You could have used a UART bridge with some
> additional GPIO pins, and connected them to useful SoC IOs.  Possibly
> via some mux.  I'd love to see reset and bootsel controlled by the USB
> UART bridge.

Good point. That would also make it more accessible and easy automated
testing a lot.

> 
> Ideally we would have a more advanced USB bridge with open source
> firmware and more than one USB function.  But I guess that adds a lot of
> complexity to the project. Reusing/abusing RS232 control signals is an
> alternative.
> 
> Finally, I'd prefer a much more compact board than the BPi-R4 size.
> 
> Along with a well designed minimalistic case with sufficient passive
> cooling and optional integrated antennas.  Thinking something along the
> Flirc RPi4 cases, using the case itself as a cooler. With half the case
> radio transparent and a choice between antenna pigtails and integrated
> antennas.  I realize that such a case will be relatively expensive. But
> without it all you have is yet another midrange dev board.  This is your
> chance to make a device which shouts "OpenWrt!!!" whenever someone sees
> it. Just like the original WRT did.  Not that that design was something
> to brag about beauty wise :-)

I also think we should should have a pre-assembled-with-case-and-antennas
option in addition to just offering the plain board.

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

Re: OpenWrt One - celebrating 20 years of OpenWrt

[Daniel Golle]

On Tue, Jan 09, 2024 at 06:49:04PM +0100, Janusz Dziedzic wrote:
> wt., 9 sty 2024 o 18:02 Robert Marko  napisał(a):
> >
> > On Tue, 9 Jan 2024 at 17:53, Rafał Miłecki  wrote:
> > >
> > > On 9.01.2024 13:29, John Crispin wrote:
> > > > On 09.01.24 12:56, Robert Marko wrote:
> > > >> ---SNIP---
> > > >>
> > > >>> Why not 6GHz?
> > > >> 6GHz requires an external card, and I doubt you can fit that in the
> > > >> target price.
> > > >>
> > > >> Regards,
> > > >> Robert
> > > >
> > > > correct. as mentioned in the email, we wanted to start out small. also 
> > > > upstream mac80211 is still missing a bunch of 11be related features.
> > >
> > > 6 GHz doesn't imply 802.11be, does it? I'm really not sure.
> > >
> > > Does MediaTek have any 802.11ax solutions that cover both: 5 GHz and
> > > 6 GHz? Maybe it'd be worth checking if that's an option and then use
> > > voting to see if people care?
> >
> > You can use 6GHz as part of 802.11ax as well, but you need an external card 
> > or
> > you need to sacrifice the built-in 5GHz for 6GHz and that isn't really
> > a good idea
> > in my opinion.
> >
> Even will be 150$ it is still good price for router with 2.4/5/6GHz
> (MTK base ACER predator W6 is about 200$).
> Or at least add extra m2 AE Key slot - then we can put there mt7916
> card, as possible extension (eg.
> https://asiarf.com/product/wi-fi-6e-m-2-ae-key-module-mt7916-aw7916-aed/).
> What will be price in case of this extra m2 AE Key slot?

You can use M.2 key adapters for that
https://www.delock.com/produkt/63343/merkmale.html

An additional slot is *not* an option as we got only a single PCIe lane.

Hopefully there are also going to be single-band (6 GHz only) 4T4R or
even 4T5R modules based on MT7916E available at some point...

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

Re: OpenWrt One - celebrating 20 years of OpenWrt

[Daniel Golle]

On Tue, Jan 09, 2024 at 05:52:57PM +0100, Rafał Miłecki wrote:
> On 9.01.2024 13:29, John Crispin wrote:
> > On 09.01.24 12:56, Robert Marko wrote:
> > > ---SNIP---
> > > 
> > > > Why not 6GHz?
> > > 6GHz requires an external card, and I doubt you can fit that in the
> > > target price.
> > > 
> > > Regards,
> > > Robert
> > 
> > correct. as mentioned in the email, we wanted to start out small. also 
> > upstream mac80211 is still missing a bunch of 11be related features.
> 
> 6 GHz doesn't imply 802.11be, does it? I'm really not sure.

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

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

> 
> Does MediaTek have any 802.11ax solutions that cover both: 5 GHz and
> 6 GHz? Maybe it'd be worth checking if that's an option and then use
> voting to see if people care?

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

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

Re: OpenWrt One - celebrating 20 years of OpenWrt

[Daniel Golle]

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

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

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

Re: Battlemesh x OpenWrt meeting in Cyprus?

[Daniel Golle]

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

[Daniel Golle]

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

[Daniel Golle]

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

[Daniel Golle]

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

[Daniel Golle]

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

[Daniel Golle]

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

Re: 回复: [PATCH 1/2] mac80211: rework MT7620 PA/LNA RF calibration

[Daniel Golle]

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

[Daniel Golle]

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

[Daniel Golle]

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

[Daniel Golle]

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]);
> ++

Re: [PATCH 4/4] gemini: Bump to kernel v6.1

[Daniel Golle]

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 

Re: Wifi at the Luci web interface

[Daniel Golle]

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?

[Daniel Golle]

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?

[Daniel Golle]

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?

[Daniel Golle]

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

[Daniel Golle]

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

[Daniel Golle]

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

[Daniel Golle]

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

[Daniel Golle]

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

[Daniel Golle]

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

[Daniel Golle]

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

[Daniel Golle]

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

Re: [iwinfo PATCH] devices: add support for declaring compatible matched devices

[Daniel Golle]

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

[Daniel Golle]

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

Re: question to block mount/umount

[Daniel Golle]

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?

[Daniel Golle]

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

[Daniel Golle]

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

[Daniel Golle]

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

[Daniel Golle]

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

Re: [PATCH] linux: add in labels for block2mtd

[Daniel Golle]

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

[Daniel Golle]

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

[Daniel Golle]

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

[Daniel Golle]

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

[Daniel Golle]

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

[Daniel Golle]

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

[Daniel Golle]

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

Re: Add swig/host build dependency [Was: Re: [PATCH] uboot-mediatek: clean up build dependencies]

[Daniel Golle]

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

[Daniel Golle]

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

Re: [PATCH] procd: jail/jail: correctly check for null pointer

[Daniel Golle]

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

Re: howto support ramoops (former crashlog.o)

[Daniel Golle]

Hi Bastian,

On Tue, Aug 23, 2022 at 04:47:28PM +, Bastian Bittorf wrote:
> I'am trying to add ramoops support for a specific mediatek model.
> There are alreay a few commit regarding this, but i'am not apply
> to harvest a crashlog after a crash-reboot.

pstore/ramoops can only work on platforms which do NOT clear DRAM
content on (re-)boot. Many of the $vendor loaders unfortunately do that.
Archer C6U being an MT7621-based unit will probably need a replacement
bootloader in order to change that behavior. As it is a rather
straight-forward board with SPI-NOR, creating a replacement loader is
not hard (see uboot-mediatek package).

However, I haven't yet tried pstore on MT7621 and the proprietary DRAM
calibration blob may always clear DRAM content on boot without any way
to prevent that.
So maybe we simply don't have the option to use pstore/ramoops on that
platform across reboots (I can try this in about a week from now when I'm
back home and tell you more).

Another (more wastefull) option is to use kexec to restart Linux in case
of a crash instead of resetting the CPU -- more wasteful because you
will have to load the to-be-kexec'ed kernel into the RAM and hence you
have a few megabytes less available at runtime. But you can be sure that
DRAM content will be preserved.


Cheers


Daniel


> 
> # openwrt$ git grep "ramoops@"
> package/boot/uboot-mediatek/patches/050-mt7622-enable-pstore.patch:+ 
> ramoops@42ff {
> target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8065-nighthawk.dtsi: 
> ramoops@4210 {
> target/linux/mediatek/patches-5.15/105-dts-mt7622-enable-pstore.patch:+ 
> ramoops@42ff {
> 
> This looks good, e.g. 0x42ff = the upper 48 Megabyte minus 64k
> My Router Archer C6U v1 has 128mb RAM, so i go for:
> 
> 128 * 1024 * 1024 = 134217728 = 0x800,  
> substracting 0x1 = 0x7ff - so my dts-patch looks like:
> 
> 
> +reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + /* 64 KiB reserved for ramoops/pstore */
> + ramoops@7ff {
> + compatible = "ramoops";
> + reg = <0 0x7ff 0 0x1>;
> + record-size = <0x1000>;
> + };   
> +};
> 
> 
> It builds and the running image has 'pstore' automatically mounted,
> and the kernelmodule loads, and is visible in device-tree:
> 
> root@box:~ hexdump -C /proc/device-tree/reserved-memory/ramoops@7ff/reg
>   00 00 00 00 07 ff 00 00  00 00 00 00 00 01 00 00  ||
> 0010
> root@box:~ hexdump -C 
> /proc/device-tree/reserved-memory/ramoops@7ff/record-size
>   00 00 10 00   ||
> 0004
> root@box:~ mount | grep pstore
> pstore on /sys/fs/pstore type pstore (rw,noatime)
> root@box:~ lsmod | grep pstore
> pstore  9910  1 
> 
> but when crashing the kernel with: echo 'c' >/proc/sysrq-trigger
> the store is always empty:
> 
> root@box:~ ls -l /sys/fs/pstore/
> 
> Has anyone succeeded and has maybe a hint for me?
> 
> bye, bastian
> 
> 
> ___
> 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: Setting Linux Capabilities

[Daniel Golle]

On Wed, Aug 17, 2022 at 09:15:12AM +, Ravi Paluri (QUIC) wrote:
> > OpenWrt has procd-ujail, to set capabilities with it:
> > https://github.com/openwrt/openwrt/blob/master/package/utils/busybox/files/sysntpd#L80
> > https://github.com/openwrt/openwrt/blob/master/package/utils/busybox/files/ntpd.capabilities
> 
> Thanks Etienne for the pointers and letting us know that jailing needs to be 
> enabled for capabilities to work.

You can also use procd/ujail to just drop/set capabilities WITHOUT
having to use the chroot-jail and other functionality at the same time.

> 
> Thanks,
> Ravi
> 
> -Original Message-
> From: Etienne Champetier  
> Sent: Tuesday, August 16, 2022 5:34 PM
> To: Ravi Paluri (QUIC) 
> Cc: openwrt-devel@lists.openwrt.org
> Subject: Re: Setting Linux Capabilities
> 
> WARNING: This email originated from outside of Qualcomm. Please be wary of 
> any links or attachments, and do not enable macros.
> 
> Hi Ravi,
> 
> Le mar. 16 août 2022 à 07:52, Ravi Paluri (QUIC)  a 
> écrit :
> >
> > Hi Team,
> > We would like to set below capabilities for our process.
> > * CAP_NET_ADMIN
> > * CAP_NET_RAW
> >
> > Do we need to use APIs mentioned in 
> > https://linux.die.net/man/3/cap_set_flag and 
> > https://linux.die.net/man/3/cap_set_proc to get this functionality?
> >
> > On Systemd, I see that this can be achieved by writing below lines in a 
> > service file.
> > CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_RAW 
> > AmbientCapabilities=CAP_NET_ADMIN CAP_NET_RAW
> >
> > So, would like to know if there is any thing similar that can be done in 
> > procd init scripts?
> 
> OpenWrt has procd-ujail, to set capabilities with it:
> https://github.com/openwrt/openwrt/blob/master/package/utils/busybox/files/sysntpd#L80
> https://github.com/openwrt/openwrt/blob/master/package/utils/busybox/files/ntpd.capabilities
> 
> Best
> Etienne
> 
> > Thanks,
> > Ravi
> ___
> 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 6/7] tools: add 7z host package

[Daniel Golle]

On Sun, Jul 31, 2022 at 03:36:32PM +0200, Sander Vanheule wrote:
> On Sat, 2022-07-23 at 22:53 +0200, Jan Hoffmann wrote:
> > Add the 7zr command line tool, which is a version of the 7z application
> > that only supports 7z archives.
> > 
> > 7z is one of the two compression formats supported in H3C firmware
> > images (the alternative would be ARJ).
> > 
> > (Alternatively, the 7zr command line tool could also be built from a
> > current version of the public-domain LZMA SDK. That would require
> > repackaging the source package, as it is only provided in 7z format.)
> > 
> > Signed-off-by: Jan Hoffmann 
> 
> This caused builds to fail on systems with GCC 12 (Arch, Fedora 36).

Strange, I'm on archlinux with gcc 12.1.0 and it worked for me.
Maybe it only fails in silent mode when warnings are treated as errors?

Anyway, thanks for taking care of that!

> 
> Pushed out a fix by bumping the package to version 22.01 (released two weeks
> ago) with commit 101190419969 ("tools: bump 7z package to 22.01"). Thanks to
> Tomasz for pointing out that the latest version would fix the issue.
> 
> Best,
> Sander
> 
> ___
> 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 0/7] realtek: add HPE 1920 support

[Daniel Golle]

On Thu, Jul 28, 2022 at 03:27:14PM +0200, Sander Vanheule wrote:
> On Thu, 2022-07-28 at 15:10 +0200, Jan Hoffmann wrote:
> > > This adds support for three switches from the HPE 1920 series. It has
> > > been tested on HPE 1920-8G and HPE 1920-16G. Support for HPE 1920-24G
> > > is also included, as it uses the same board as the 16-port model.
> > > 
> > > The patch series depends on the firmware-utils patch adding the
> > > mkh3cimg and mkh3cvfs tools.
> > 
> > This patch series has just been merged. However, as mentioned in the 
> > cover letter, it depends on new tools in firmware-utils. As the 
> > corresponding patch series ("add tools for H3C devices") hasn't been 
> > merged yet, this won't actually build.
> 
> I've pushed a revert commit to avoid breaking the builds.
> 
> Can someone explain why this whole series needed to be merged so quickly? 
> These *7* patches have
> only been posted on Saturday, and testing was performed for patches 2-4. At 
> least patches 5-7
> could've remained unmerged awaiting some further comments.

As 5-7 depend on the actual device for testing they are unlikely to
receive great amounts of feedback, but are also unlikely to break
anything.

> 
> > 
> > Please tell me if I should have made this dependency clearer in any way, 
> > so I can avoid similar situations in the future.
> 
> It was plainly stated in the cover letter, I don't think you could have been 
> any clearer about this
> dependency.

Yes, it was absolutely clear and I had it in my local firmware-utils
tree for which I used CONFIG_SRC_TREE_OVERRIDE.
The fact that the cover letter doesn't become part of git history was
part of the reason why I forgot about that before pushing.



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

Re: [PATCH 1/4] pcre2: adds pcre2 to base

[Daniel Golle]

On Thu, May 19, 2022 at 06:37:28PM +0200, Dominick Grift wrote:
> libselinux-3.4 requires pcre2
> 
> Signed-off-by: Dominick Grift 
> ---
>  package/libs/pcre2/Config.in | 30 
>  package/libs/pcre2/Makefile  | 92 
>  2 files changed, 122 insertions(+)
>  create mode 100644 package/libs/pcre2/Config.in
>  create mode 100644 package/libs/pcre2/Makefile
> 
> diff --git a/package/libs/pcre2/Config.in b/package/libs/pcre2/Config.in
> new file mode 100644
> index 00..8777a4e84c
> --- /dev/null
> +++ b/package/libs/pcre2/Config.in
> @@ -0,0 +1,30 @@
> +config PCRE2_JIT_ENABLED
> + bool
> + depends on PACKAGE_libpcre2 && (aarch64 || aarch64_be || arm || i386 || 
> i686 || x86_64 || mips || mipsel || mips64 || mips64el || powerpc || 
> powerpc64 || powerpcle || sparc)
> + default y if (arm || i686 || x86_64)

Can you explain the choice of architectures for which you are
suggesting to enable JIT by default?
Wouldn't e.g. aarch64 benefit just as well?

> + prompt "Enable JIT compiler support"
> + help
> + Enable JIT (Just-In-Time) compiler support.
> +
> + Just-in-time compiling is a heavyweight optimization that can 
> greatly
> + speed up pattern matching. However, it comes at the cost of 
> extra
> + processing before the match is performed, so it is of most 
> benefit when
> + the same pattern is going to be matched many times. This does 
> not
> + necessarily mean many calls of a matching function; if the 
> pattern is
> + not anchored, matching attempts may take place many times at 
> various
> + positions in the subject, even for a single call. Therefore, if 
> the
> + subject string is very long, it may still pay to use JIT even 
> for
> + one-off matches. JIT support is available for all of the 8-bit, 
> 16-bit
> + and 32-bit PCRE2 libraries and adds about 100KB to the resulting
> + libpcre2.so. JIT support applies only to the traditional 
> Perl-compatible
> + matching function. It does not apply when the DFA matching 
> function is
> + being used.
> +
> + Enabling this option can give an about 10x performance increase 
> on JIT
> + operations. It can be desireable for e.g. high performance 
> Apache
> + mod_rewrite or HA-Proxy reqrep operations.
> +
> + However, JIT should _only_ be enabled on architectures that are 
> supported.
> + Enabling JIT on unsupported platforms will result in a 
> compilation
> + failure. A list of supported architectures can be found here:
> + https://pcre.org/current/doc/html/pcre2jit.html#SEC2
> diff --git a/package/libs/pcre2/Makefile b/package/libs/pcre2/Makefile
> new file mode 100644
> index 00..4e75a1cda9
> --- /dev/null
> +++ b/package/libs/pcre2/Makefile
> @@ -0,0 +1,92 @@
> +#
> +# Copyright (C) 2017 Shane Peelar
> +#
> +# This is free software, licensed under the GNU General Public License v2.
> +# See /LICENSE for more information.
> +#
> +
> +include $(TOPDIR)/rules.mk
> +
> +PKG_NAME:=pcre2
> +PKG_VERSION:=10.37
> +PKG_RELEASE:=$(AUTORELEASE)
> +
> +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
> +PKG_SOURCE_URL:=@SF/pcre/$(PKG_NAME)/$(PKG_VERSION)
> +PKG_HASH:=4d95a96e8b80529893b4562be12648d798b957b1ba1aae39606bbc2ab956d270
> +
> +PKG_MAINTAINER:=Shane Peelar 
> +PKG_LICENSE:=BSD-3-Clause
> +PKG_LICENSE_FILES:=LICENCE
> +PKG_CPE_ID:=cpe:/a:pcre:pcre
> +
> +PKG_CONFIG_DEPENDS:=\
> + CONFIG_PACKAGE_libpcre2-16 \
> + CONFIG_PACKAGE_libpcre2-32 \
> + CONFIG_PCRE2_JIT_ENABLED
> +
> +include $(INCLUDE_DIR)/package.mk
> +include $(INCLUDE_DIR)/cmake.mk
> +
> +define Package/libpcre2/default
> +  SECTION:=libs
> +  CATEGORY:=Libraries
> +  URL:=https://www.pcre.org/
> +endef
> +
> +define Package/libpcre2/config
> +  source "$(SOURCE)/Config.in"
> +endef
> +
> +define Package/libpcre2
> +  $(call Package/libpcre2/default)
> +  TITLE:=A Perl Compatible Regular Expression library
> +endef
> +
> +define Package/libpcre2-16
> +  $(call Package/libpcre2/default)
> +  TITLE:=A Perl Compatible Regular Expression library (16bit support)
> +endef
> +
> +define Package/libpcre2-32
> +  $(call Package/libpcre2/default)
> +  TITLE:=A Perl Compatible Regular Expression library (32bit support)
> +endef
> +
> +CMAKE_OPTIONS += \
> + -DBUILD_SHARED_LIBS=ON \
> + -DPCRE2_BUILD_PCRE2_8=ON \
> + -DPCRE2_BUILD_PCRE2_16=O$(if $(CONFIG_PACKAGE_libpcre2-16),N,FF) \
> + -DPCRE2_BUILD_PCRE2_32=O$(if $(CONFIG_PACKAGE_libpcre2-32),N,FF) \
> + -DPCRE2_DEBUG=OFF \
> + -DPCRE2_DISABLE_PERCENT_ZT=ON \
> + -DPCRE2_SUPPORT_JIT=O$(if $(CONFIG_PCRE2_JIT_ENABLED),N,FF) \
> + -DPCRE2_SHOW_REPORT=OFF \
> + -DPCRE2_BUILD_PCRE2GREP=OFF \
> + -DPCRE2_BUILD_TESTS=OFF
> +
> +define Build/InstallDev
> + $(call 

[PATCH] blockd: restore device_move semantics

[Daniel Golle]

Before commit 4963db4 block device were only removed and re-added in
case of device_move() returning a non-zero value. Commit 4963db4 then
(supposedly) accidentally inverted that logic and also (probably to
work-around the problems resulting from the now inverted logic) limited
this behavior to autofs mounts, leaving the autofs codepath in a semi-
broken state.
Restore the original semantics as of before commit 4963db4 to fully
restore functionality for autofs mounts.

Fixes: 4963db4 ("blockd: use uloop_process for calling /sbin/hotplug-call 
mount")
Signed-off-by: Daniel Golle 
---
 blockd.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/blockd.c b/blockd.c
index 8bb5005..9572fd0 100644
--- a/blockd.c
+++ b/blockd.c
@@ -349,13 +349,11 @@ block_hotplug(struct ubus_context *ctx, struct 
ubus_object *obj,
 
vlist_add(, >node, device->name);
 
-   if (old && !device_move(old, device)) {
-   if (device->autofs) {
-   device_mount_remove(ctx, old);
-   device_mount_add(ctx, device);
-   } else {
+   if (old && device_move(old, device)) {
+   device_mount_remove(ctx, old);
+   device_mount_add(ctx, device);
+   if (!device->autofs)
block("mount", NULL, NULL, 0, NULL);
-   }
} else if (device->autofs) {
device_mount_add(ctx, device);
}
-- 
2.35.1


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

Re: [PATCH/RFC] kernel-defaults.mk: get rid of BuildID

[Daniel Golle]

On Tue, Apr 05, 2022 at 05:05:43PM +0200, Felix Fietkau wrote:
> On 05.04.22 03:14, Daniel Golle wrote:
> > When building the Linux kernel, the linker generates a hash of all
> > versions of tools involved in a build called BuildID in ELF header.
> > This breaks reproducibility accross different buildhosts eventhough
> > OpenWrt builds the toolchain from source -- the build-id hash ends up
> > to be the only thing which differs in the resulting builds.
> > 
> > The cause is most likely a result of the build hosts' architectures,
> > OSs and standard C libraries being different.
> > 
> > While in theory it is true that tools may produce a different output
> > depending on archtecture, OS and libc of the buildhost, in practice
> > this is (fortunately) hardly ever the case and hence it contradicts
> > ld(1) which states:
> > 
> >   'The "md5" and "sha1" styles produces an identifier that is always
> >the same in an identical output file, but will be unique among all
> >nonidentical output files.'
> > 
> > (the kernel is using sha1 style build-id, rebuilding the kernel on a
> > different buildhost results in everything being identical **except**
> > for the build-id)
> > 
> > Hence, to achieve reproducible builds we will either have to resort to
> > identical containers/VMs for building or get rid of the BuildID hash
> > alltogether (or use a different build-id style)
> > 
> > At this point, this seems to be what Debian is doing as well in order
> > to achieve reproducible kernel builds, see[1].
> > 
> > [1]: https://wiki.debian.org/SameKernel#How_this_works
> > Signed-off-by: Daniel Golle 
> > 
> > diff --git a/include/kernel-defaults.mk b/include/kernel-defaults.mk
> > index 1e82f7d739..9c8d5fbe97 100644
> > --- a/include/kernel-defaults.mk
> > +++ b/include/kernel-defaults.mk
> > @@ -46,6 +46,7 @@ else
> > if [ -d $(LINUX_DIR)/user_headers ]; then \
> > rm -rf $(LINUX_DIR)/user_headers; \
> > fi
> > +   $(SED) -i $(LINUX_DIR)/Makefile  -e 's/--build-id=.*/--build-id=none/g'
> I don't like running sed on the linux Makefile, as this interferes with
> creating patches for it. I think it would be better to simply override
> KBUILD_LDFLAGS_MODULE on the kernel/module build command line.

You probably meant LDFLAGS_vmlinux because from what I understand
KBUILD_LDFLAGS_MODULE only applies when building modules but not when
linking vmlinux.
As ld only cares about the last mentioned --build-id= parameter
supplied, we can override it using KBUILD_LDFLAGS (which should apply
to both, vmlinux.elf as well as modules).
I haven't tried any of that yet though.

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

[PATCH/RFC] kernel-defaults.mk: get rid of BuildID

[Daniel Golle]

When building the Linux kernel, the linker generates a hash of all
versions of tools involved in a build called BuildID in ELF header.
This breaks reproducibility accross different buildhosts eventhough
OpenWrt builds the toolchain from source -- the build-id hash ends up
to be the only thing which differs in the resulting builds.

The cause is most likely a result of the build hosts' architectures,
OSs and standard C libraries being different.

While in theory it is true that tools may produce a different output
depending on archtecture, OS and libc of the buildhost, in practice
this is (fortunately) hardly ever the case and hence it contradicts
ld(1) which states:

 'The "md5" and "sha1" styles produces an identifier that is always
  the same in an identical output file, but will be unique among all
  nonidentical output files.'

(the kernel is using sha1 style build-id, rebuilding the kernel on a
different buildhost results in everything being identical **except**
for the build-id)

Hence, to achieve reproducible builds we will either have to resort to
identical containers/VMs for building or get rid of the BuildID hash
alltogether (or use a different build-id style)

At this point, this seems to be what Debian is doing as well in order
to achieve reproducible kernel builds, see[1].

[1]: https://wiki.debian.org/SameKernel#How_this_works
Signed-off-by: Daniel Golle 
---
To investigate the issue of non-reproducible kernel images accross
buildhosts I compated the files build by OpenWrt's buildbots with
Paul's rebuilder script running on his (Aarch64) Mac.
The resulting bzImage binaries were compared by first using
scripts/extract-vmlinux to extract the ELF contents from bzImages
and then compared using dffoscope:

Format-specific differences are supported for ELF binaries but no file-specific 
differences were detected; falling back to a binary diff.
@@ -1254946,16 +1254946,16 @@
 01326210: 0400  0800  0c00  5865 6e00  Xen.
 01326220:   0080  0400  0800   
 01326230: 0400  5865 6e00      Xen.
 01326240: 0400  2000  0500  474e 5500   ...GNU.
 01326250: 0100 01c0 0400  df00     
 01326260: 0200 01c0 0400  0700     
 01326270: 0400  1400  0300  474e 5500  GNU.
-01326280: b737 4be0 66fd dc7f 9fc8 24b6 6354 d8f9  .7K.f.$.cT..
-01326290: a42c b698 0600  0100  0001   .,..
+01326280: 2008 eb34 e442 f784 6573 d75b 9bd2 b23f   ..4.B..es.[...?
+01326290: 536e a33e 0600  0100  0001   Sn.>
 013262a0: 4c69 6e75 7800    0400   Linux...
 013262b0: 0800  1200  5865 6e00 b004 0001  Xen.
 013262c0:          
 013262d0:          
 013262e0:          
 013262f0:          
 01326300:          
(all the remaining ELF is bit-by-bit identical)

Using file(1) revealed that the difference is exactly the build-id:
linux1.elf: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically 
linked, BuildID[sha1]=b7374be066fddc7f9fc824b66354d8f9a42cb698, stripped
linux2.elf: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically 
linked, BuildID[sha1]=2008eb34e442f7846573d75b9bd2b23f536ea33e, stripped

 include/kernel-defaults.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/kernel-defaults.mk b/include/kernel-defaults.mk
index 1e82f7d739..9c8d5fbe97 100644
--- a/include/kernel-defaults.mk
+++ b/include/kernel-defaults.mk
@@ -46,6 +46,7 @@ else
if [ -d $(LINUX_DIR)/user_headers ]; then \
rm -rf $(LINUX_DIR)/user_headers; \
fi
+   $(SED) -i $(LINUX_DIR)/Makefile  -e 's/--build-id=.*/--build-id=none/g'
   endef
 endif
 
-- 
2.35.1


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

Re: [PATCH fstools] partname: add "fstools_use_partlabel" option to find part from label

[Daniel Golle]

On Sat, Mar 12, 2022 at 01:05:17PM +0900, INAGAKI Hiroshi wrote:
> This patch adds "fstools_use_partlabel" option to partname driver.
> 
> The Linux Kernel supports "root=PARTLABEL=" syntax, but fstools
> doesn't and fail to parse the path to the root device.
> To use this syntax, add the option and find from all block devices.
> 
> Note:
> This change is required for I-O DATA HDL-A/HDL2-A. On they, kernel and
> rootfs are stored in the storage device connected to SATA, port1 or
> port2 and the path to the partition will be assigned dynamically. So
> "root=PARTLABEL=" syntax is required instead of "/dev/sdXN".
> 
> Signed-off-by: INAGAKI Hiroshi 
> ---
>  libfstools/partname.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/libfstools/partname.c b/libfstools/partname.c
> index f59c52e..7e57311 100644
> --- a/libfstools/partname.c
> +++ b/libfstools/partname.c
> @@ -121,6 +121,7 @@ static struct volume *partname_volume_find(char *name)
>   char *rootdev = NULL, *devname, *tmp;
>   int j;
>   bool found = false;
> + bool use_label = false;
>   glob_t gl;
>  
>   if (get_var_from_file("/proc/cmdline", "fstools_ignore_partname", 
> rootparam, sizeof(rootparam))) {
> @@ -128,12 +129,17 @@ static struct volume *partname_volume_find(char *name)
>   return NULL;
>   }
>  
> - if (get_var_from_file("/proc/cmdline", "root", rootparam, 
> sizeof(rootparam))) {
> + if (get_var_from_file("/proc/cmdline", "fstools_use_partlabel", 
> rootparam, sizeof(rootparam)))
> + if (!strcmp("1", rootparam))
> + use_label = true;
> +
> + if (get_var_from_file("/proc/cmdline", "root", rootparam, 
> sizeof(rootparam)) &&
> + !use_label) {

Wouldn't it be easier to use strncmp() to match the PARTLABEL= prefix
in string stored at rootparam? In that case you won't have to introduce
a new 'fstools_use_partlabel' parameter and achieve the same result.

>   rootdev = rootdevname(rootparam);
>   /* find partition on same device as rootfs */
>   snprintf(ueventgstr, sizeof(ueventgstr), "%s/%s/*/uevent", 
> block_dir_name, rootdev);
>   } else {
> - /* no 'root=' kernel cmdline parameter, find on any block 
> device */
> + /* no 'root=' kernel cmdline parameter or use_label=true, find 
> on any block device */
>   snprintf(ueventgstr, sizeof(ueventgstr), "%s/*/uevent", 
> block_dir_name);
>   }
>  
> -- 
> 2.34.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] uqmi: corrected too short received SMS

[Daniel Golle]

Hi Henrik,

thank you for submitting this patch. I've also noticed that problem
long ago but it wasn't important for me at the time, so I didn't go
into fixing it.

On Sat, Mar 12, 2022 at 12:33:54AM +0100, Henrik Ginstmark wrote:
> When characters with ascii values bigger than 0x7f are used, the
> length of the received text
> message is too short.
> 
> Test message sent: 123äÄ123
> Before correction:
> root@OpenWrt:/tmp# uqmi -d /dev/cdc-wdm0 --get-message 20
> Raw text: 31 32 33 7b 5b 31 32 33
> {
> "smsc": "+4672441",
> "sender": "+46x",
> "timestamp": "2022-03-11 18:48:10",
> "text": "123äÄ1"
> }
> 
> after correction:
> root@OpenWrt:/tmp# uqmi -d /dev/cdc-wdm0 --get-message 20
> Raw text: 31 32 33 7b 5b 31 32 33
> {
> "smsc": "+4672441",
> "sender": "+46x",
> "timestamp": "2022-03-11 18:48:10",
> "text": "123äÄ123"
> }
> 
> Signed-off-by: Henrik Ginstmark 
> ---
>  uqmi/src/commands-wms.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/uqmi/src/commands-wms.c b/uqmi/src/commands-wms.c
> index 700d79f..a58fd6a 100644
> --- a/uqmi/src/commands-wms.c
> +++ b/uqmi/src/commands-wms.c
> @@ -222,8 +222,8 @@ static int decode_udh(const unsigned char *data)
>  static void decode_7bit_field(char *name, const unsigned char *data,
> int data_len, int bit_offset)

I've fixed the line-wrappign problems here ...

>  {
> char *dest = blobmsg_alloc_string_buffer(, name, 3 *
> data_len + 2);

... and here ...
> -   pdu_decode_7bit_str(dest, data, CEILDIV(data_len * 7, 8), bit_offset);
> -   dest[data_len] = 0;
> +   int out_len = pdu_decode_7bit_str(dest, data, CEILDIV(data_len
> * 7, 8), bit_offset);

... and here, so the patch would apply.

> +   dest[out_len] = 0;
> blobmsg_add_string_buffer();
>  }
> 
> --
> 2.34.1

Please use 'git format-send-email' or 'git format-patch' next time to
avoid the MUA messing around with line-wrapping.
For this submission it's ok, I've already fixed it manually.


Cheers


Daniel

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

Re: [PATCH] realtek: net: dsa: configure better brport flags when ports leave the bridge

[Daniel Golle]

On Sat, Mar 05, 2022 at 10:36:07AM +0100, Bjørn Mork wrote:
> Ensures that the DSA driver set exactly the same default flags as the
> bridge when a port joins or leaves.  Without this we end up with a
> confusing flag mismatch, where DSA and bridge ports use different sets
> of flags.
> 
> This is critical as the "learning" mismatch will be harmful to the
> network, causing all traffic to be flooded on all ports.
> 
> The original commit was buggy, trying to set the flags one-by-one in a
> loop.  This was not supported by the API and the end result was that
> all but the last flag were cleared.  This bug was implicitly fixed
> upstream by commit e18f4c18ab5b ("net: switchdev: pass flags and mask
> to both {PRE_,}BRIDGE_FLAGS attributes").
> 
> This is a minimum temporary stop meaure fix for the critical lack of
> "learning" only.  The major API change associated with a full v5.12+
> backport is neither required nor wanted. A simpler fix, moving the
> call to dsa_port_bridge_flags() out of the loop,  has therefore been
> merged into this modified backport.
> 
> Fixes: afa3ab54c03d ("realtek: Backport bridge configuration for DSA")
> Signed-off-by: Bjørn Mork 
Acked-by: Daniel Golle 
(reviewed and lgtm, but can't test it before thursday)


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

Re: [PATCH 1/2] realtek: Use firewall4

[Daniel Golle]

On Tue, Mar 01, 2022 at 09:51:32PM +0100, Bjørn Mork wrote:
> Petr Štetiar  writes:
> 
> > Sander Vanheule  [2022-02-28 23:00:34]:
> >
> >> I wonder if it doesn't make more sense to drop the firewall package from 
> >> the
> >> default now, since there is only one interface, unless there is a different
> >> reason to keep the firewall.
> >
> > 1. consistency
> 
> With what exactly?  It's a switch. It doesn't need router specific
> software.

We may need to add a 'switch' DEVICE_TYPE in include/target.mk
selecting packages relevant for this class of devices.
('bridge' or 'ip-full', 'ethtool', ...)

> 
> > 2. supporting more common use cases out of the box
> 
> It's just bloat.  The flash size is small on many of these devices.

It's rather the very limited performance of the CPU and Ethernet MAC
used for the CPU port which makes me disregard those (layer-2)
switches being used for anything else than that.

> 
> > 3. wider testing audience of core networking components
> 
> The firewall package is tested on most devices. This should be enough.
> 
> I'm with Sander.  Please drop the firewall package.  Not sure how useful
> dnsmasq and odhcpd-ipv6only are either? Why would I want those on my
> switch? It's not a router, DNS server or DHCP server.

Exactly. I fully agree, none of those packages make much sense on this
class of devices and all of them should be dropped from default
installations. Obviously users may still install them if they really
want their switch to act as DHCP server and/or caching DNS resolver.


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

Re: [PATCH] realtek: ZyXEL GS1900-48: drop gpio-restart

[Daniel Golle]

On Mon, Feb 21, 2022 at 08:33:06PM +0100, Sander Vanheule wrote:
> On Mon, 2022-02-21 at 12:09 +0000, Daniel Golle wrote:
> > On Mon, Feb 21, 2022 at 10:04:13AM +0100, Sander Vanheule wrote:
> > > On Sun, 2022-02-20 at 21:13 +0100, Birger Koblitz wrote:
> > > > Hi,
> > > > 
> > > > during development I came across situations where the RTL839x
> > > > SoC's own reset did not always completely reset its state.
> > > > U-Boot was no longer able to boot via tftp afterwards.
> > > > This is the same situation we see on the RTL838x.
> > > > While users will hopefully never mess up the SoC as during
> > > > development, I would prefer a solution that reliably
> > > > resets the device over a solution that avoids a warning.
> > > 
> > > If you did not see all three warnings on your device, that would mean it's
> > > behaving differently. As Daniel noted, the fact that the third warning is 
> > > even
> > > emitted, means that gpio-restart failed to restart the device and is 
> > > returning
> > > from its handler. That either means the GPIO is incorrect (although it 
> > > matches
> > > the data from the stock firmware), or the RTL8231's output cannot be set 
> > > to the
> > > intended value.
> > > 
> > > At least for my device it is not just about avoiding an ugly warning. 
> > > gpio-
> > > restart effectively does nothing, so there's no point in setting it up.
> > > 
> > 
> > Thinking about it another night I think you are both right:
> > The GPIO does trigger a reliable reset, it's just **not fast enough**,
> > hence the warning about that it can sleep.
> > 
> 
> I just checked with my multimeter, and while the GPIO5 on the RTL8231 does go 
> high/low
> when I set the output high/low from Linux, my device certainly doesn't reset. 
> The other
> GPIO lines on the chip do work, since SFP modules are correctly detected.
> 
> Birger, just to be sure, can you confirm that your device does reset with 
> GPIO5 on the
> RTL8231?
> 
> > 
> > > > At least we should have a comment in, that states that
> > > > once this is fixed in libgpiod this should be the way
> > > > to reset the device. And we should look into fixing libgpiod.
> > > 
> > > There will be a good reason that gpio-restart is using gpiod_set_value() 
> > > instead
> > > of gpiod_set_value_cansleep(). I don't know that much about the kernel, 
> > > but
> > 
> > The reason is simple:
> > The restart code doesn't have any timeout, it expects an immediate
> > action and if it even reaches the next instruction, that would mean
> > the previous reset handler has failed.
> 
> Not sure what you mean here, gpio-restart does have a few built-in delays. 
> With the used
> default values this should give the following waveform (voltages inverted with
> GPIO_ACTIVE_LOW):
> 
>  |< 100ms >|< 100 ms >|<   3000 ms   >|< Restart failed
> _|_|  |___|__ [ active ]
> _X \__/   [inactive]
> 
>   ^ Restart should already occur here
> 
> There is some debouncing circuitry between the hard reset button and the 
> trace leading to
> the SoC, so maybe 100ms wouldn't be enough. Even if setting the GPIO is slow 
> (or happens
> asynchronously), I think 3s should be enough to allow the correct level to be 
> asserted.

Absolutely. 3s should be much more than enough.
Thank you for investigating this in such great depth!


> 
> > 
> > > since the system is being torn down, it is likely certain things cannot 
> > > be used
> > > anymore. Even if it would work with the current driver, once the RTL8231 
> > > is
> > > controlled through an MDIO bus (from a kernel perspective), things might 
> > > change.
> > 
> > Yes, it may not even be possible to have it use *_cansleep() and then
> > wait a defined amount of time, because that would mean spawning another
> > thread/worker/whatever for the timeout...
> > 
> > Not using bit-banging to control the RTL8231 could solve that.
> > MDIO access code typically just actively loop-waits until the busy-bit
> > of the bus control register has cleared -- no sleep()'ing involved
> > there.
> 
> The current driver for the RTL82131 doesn't use bit-banging, but talks to the 
> AUX-MDIO
> control registers directly to perform register reads and writes. To wait for 
> MDIO
> transfers to finish, udelay() i

Re: [PATCH v3 2/2] iproute2: add support for cpu set

[Daniel Golle]

On Mon, Feb 21, 2022 at 03:27:19PM +0300, Arınç ÜNAL wrote:
> On 21/02/2022 05:30, Daniel Golle wrote:
> > On Mon, Feb 21, 2022 at 01:37:10AM +0100, Ansuel Smith wrote:
> > > > 
> > > > On Thu, Feb 03, 2022 at 01:44:12AM +0100, Ansuel Smith wrote:
> > > > > Add support for cpu set useful to set CPU port for dsa devices.
> > > > 
> > > > Please also document the newly added 'cpu' parameter in the command-
> > > > line output -- the manpage isn't even installed/available for OpenWrt
> > > > users.
> > > > 
> > > 
> > > Should I wait for other review or should I send v3?
> > 
> > Give it a test-run and make sure
> > ip link XXX set cpu YYY
> > actually works -- when I tried it gave me
> > RTNETLINK answers: Not supported
> > eventhough the DSA driver does set the .port_change_cpu_port
> > function. If it works for you with whatever DSA driver you are trying
> > with, I will figure why it didn't work on MT7530...
> 
> MT7530 DSA driver does not support port 5 as the CPU port if that's what you
> tried.
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/net/dsa/mt7530.txt#n63

There is a patch by @LGA1150 adding that:
https://github.com/frank-w/BPI-R2-4.14/commit/47499f9ef4dc6a0888329412347c539ef1d4a514

I works quite nicely with their tree, I also got it running before when
using the device-tree default-cpu hack we now dropped:
https://github.com/frank-w/BPI-R2-4.14/commit/a740207fdbc4cc4c29e74d0735a180d58197f252

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

Re: [PATCH] realtek: ZyXEL GS1900-48: drop gpio-restart

[Daniel Golle]

On Mon, Feb 21, 2022 at 10:04:13AM +0100, Sander Vanheule wrote:
> On Sun, 2022-02-20 at 21:13 +0100, Birger Koblitz wrote:
> > Hi,
> > 
> > during development I came across situations where the RTL839x
> > SoC's own reset did not always completely reset its state.
> > U-Boot was no longer able to boot via tftp afterwards.
> > This is the same situation we see on the RTL838x.
> > While users will hopefully never mess up the SoC as during
> > development, I would prefer a solution that reliably
> > resets the device over a solution that avoids a warning.
> 
> If you did not see all three warnings on your device, that would mean it's
> behaving differently. As Daniel noted, the fact that the third warning is even
> emitted, means that gpio-restart failed to restart the device and is returning
> from its handler. That either means the GPIO is incorrect (although it matches
> the data from the stock firmware), or the RTL8231's output cannot be set to 
> the
> intended value.
> 
> At least for my device it is not just about avoiding an ugly warning. gpio-
> restart effectively does nothing, so there's no point in setting it up.
> 

Thinking about it another night I think you are both right:
The GPIO does trigger a reliable reset, it's just **not fast enough**,
hence the warning about that it can sleep.


> > At least we should have a comment in, that states that
> > once this is fixed in libgpiod this should be the way
> > to reset the device. And we should look into fixing libgpiod.
> 
> There will be a good reason that gpio-restart is using gpiod_set_value() 
> instead
> of gpiod_set_value_cansleep(). I don't know that much about the kernel, but

The reason is simple:
The restart code doesn't have any timeout, it expects an immediate
action and if it even reaches the next instruction, that would mean
the previous reset handler has failed.

> since the system is being torn down, it is likely certain things cannot be 
> used
> anymore. Even if it would work with the current driver, once the RTL8231 is
> controlled through an MDIO bus (from a kernel perspective), things might 
> change.

Yes, it may not even be possible to have it use *_cansleep() and then
wait a defined amount of time, because that would mean spawning another
thread/worker/whatever for the timeout...

Not using bit-banging to control the RTL8231 could solve that.
MDIO access code typically just actively loop-waits until the busy-bit
of the bus control register has cleared -- no sleep()'ing involved
there.


> 
> > 
> > Cheers,
> >    Birger
> > 
> > 
> > On 20/02/2022 19:50, Sander Vanheule wrote:
> > > GPIO 5 on the RTL8231 can be used to reset the system, but gpio-restart
> > > uses gpiod_set_value. This triggers a kernel warning and backtrace for
> > > GPIO pins that can sleep, such as the RTL8231's. Two warnings are
> > > emitted by libgpiod, and a third warning by gpio-restart itself after it
> > > fails to restart the system:
> > > 
> > > [  106.654008] [ cut here ]
> > > [  106.659240] WARNING: CPU: 0 PID: 4279 at drivers/gpio/gpiolib.c:3098
> > > gpiod_set_value+0x7c/0x108
> > >     [ Stack dump and call trace ]
> > > [  106.826218] ---[ end trace d1de50b401f5a153 ]---
> > > [  106.962992] [ cut here ]
> > > [  106.968208] WARNING: CPU: 0 PID: 4279 at drivers/gpio/gpiolib.c:3098
> > > gpiod_set_value+0x7c/0x108
> > >     [ Stack dump and call trace ]
> > > [  107.136718] ---[ end trace d1de50b401f5a154 ]---
> > > [  111.087092] [ cut here ]
> > > [  111.092271] WARNING: CPU: 0 PID: 4279 at drivers/power/reset/gpio-
> > > restart.c:46 gpio_restart_notify+0xc0/0xdc
> > >     [ Stack dump and call trace ]
> > > [  111.256629] ---[ end trace d1de50b401f5a155 ]---
> > > 
> > > By removing gpio-restart from this device, we skip the restart-by-GPIO
> > > attempt and rely only on the watchdog for restarts, which is already the
> > > de facto behaviour.
> > > 
> > > Signed-off-by: Sander Vanheule 
> > > ---
> > >   target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts | 5 -
> > >   1 file changed, 5 deletions(-)
> > > 
> > > diff --git a/target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts
> > > b/target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts
> > > index dd392c5a9beb..e0e79068d2bc 100644
> > > --- a/target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts
> > > +++ b/target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts
> > > @@ -39,11 +39,6 @@
> > > gpio-controller;
> > > };
> > >   
> > > -   gpio-restart {
> > > -   compatible = "gpio-restart";
> > > -   gpios = < 5 GPIO_ACTIVE_LOW>;
> > > -   };
> > > -
> > > keys {
> > > compatible = "gpio-keys-polled";
> > > poll-interval = <20>;

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org

Re: [PATCH v3 2/2] iproute2: add support for cpu set

[Daniel Golle]

On Mon, Feb 21, 2022 at 01:37:10AM +0100, Ansuel Smith wrote:
> >
> > On Thu, Feb 03, 2022 at 01:44:12AM +0100, Ansuel Smith wrote:
> > > Add support for cpu set useful to set CPU port for dsa devices.
> >
> > Please also document the newly added 'cpu' parameter in the command-
> > line output -- the manpage isn't even installed/available for OpenWrt
> > users.
> >
> 
> Should I wait for other review or should I send v3?

Give it a test-run and make sure
ip link XXX set cpu YYY
actually works -- when I tried it gave me
RTNETLINK answers: Not supported
eventhough the DSA driver does set the .port_change_cpu_port
function. If it works for you with whatever DSA driver you are trying
with, I will figure why it didn't work on MT7530...


> 
> > >
> > > Signed-off-by: Ansuel Smith 
> > > ---
> > >  ...101-iplink_allow_to_change_cpu_value.patch | 81 +++
> > >  1 file changed, 81 insertions(+)
> > >  create mode 100644 
> > > package/network/utils/iproute2/patches/101-iplink_allow_to_change_cpu_value.patch
> > >
> > > diff --git 
> > > a/package/network/utils/iproute2/patches/101-iplink_allow_to_change_cpu_value.patch
> > >  
> > > b/package/network/utils/iproute2/patches/101-iplink_allow_to_change_cpu_value.patch
> > > new file mode 100644
> > > index ..1bb2bb1f
> > > --- /dev/null
> > > +++ 
> > > b/package/network/utils/iproute2/patches/101-iplink_allow_to_change_cpu_value.patch
> > > @@ -0,0 +1,81 @@
> > > +From 8642516618b60a2827215f2bed54d4d0aa1da48a Mon Sep 17 00:00:00 2001
> > > +From: Ansuel Smith 
> > > +Date: Sun, 23 Jan 2022 00:31:49 +0100
> > > +Subject: [PATCH] iplink: allow to change cpu of dsa device
> > > +
> > > +Allow to change the cpu port linked to a given dsa interface.
> > > +This is useful in the case of multi-CPU port DSA to assign the correct
> > > +port to the different user ports.
> > > +
> > > +Signed-off-by: Ansuel Smith 
> > > +---
> > > + include/uapi/linux/if_link.h | 1 +
> > > + ip/iplink.c  | 7 +++
> > > + man/man8/ip-link.8.in| 7 +++
> > > + 3 files changed, 15 insertions(+)
> > > +
> > > +diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
> > > +index 41708e26..901b5544 100644
> > > +--- a/include/uapi/linux/if_link.h
> > >  b/include/uapi/linux/if_link.h
> > > +@@ -341,6 +341,7 @@ enum {
> > > + IFLA_ALT_IFNAME, /* Alternative ifname */
> > > + IFLA_PERM_ADDRESS,
> > > + IFLA_PROTO_DOWN_REASON,
> > > ++IFLA_CPU,
> > > +
> > > + /* device (sysfs) name as parent, used instead
> > > +  * of IFLA_LINK where there's no parent netdev
> > > +diff --git a/ip/iplink.c b/ip/iplink.c
> > > +index a3ea775d..254c35c5 100644
> > > +--- a/ip/iplink.c
> > >  b/ip/iplink.c
> > > +@@ -595,6 +595,7 @@ int iplink_parse(int argc, char **argv, struct 
> > > iplink_req *req, char **type)
> > > + int index = 0;
> > > + int group = -1;
> > > + int addr_len = 0;
> > > ++int cpu = -1;
> > > + int err;
> > > +
> > > + ret = argc;
> > > +@@ -625,6 +626,12 @@ int iplink_parse(int argc, char **argv, struct 
> > > iplink_req *req, char **type)
> > > + } else if (matches(*argv, "link") == 0) {
> > > + NEXT_ARG();
> > > + link = *argv;
> > > ++} else if (matches(*argv, "cpu") == 0) {
> > > ++NEXT_ARG();
> > > ++cpu = ll_name_to_index(*argv);
> > > ++if (!cpu)
> > > ++return nodev(*argv);
> > > ++addattr32(>n, sizeof(*req), IFLA_CPU, cpu);
> > > + } else if (matches(*argv, "address") == 0) {
> > > + NEXT_ARG();
> > > + addr_len = ll_addr_a2n(abuf, sizeof(abuf), *argv);
> > > +diff --git a/man/man8/ip-link.8.in b/man/man8/ip-link.8.in
> > > +index 19a0c9ca..406db8ad 100644
> > > +--- a/man/man8/ip-link.8.in
> > >  b/man/man8/ip-link.8.in
> > > +@@ -152,6 +152,9 @@ ip-link \- network device configuration
> > > + .br
> > > + .RB "[ " nomaster " ]"
> > > + .br
> > > ++.RB "[ " cpu
> > > ++.IR DEVICE " ]"
> > > ++.br
> > > + .RB "[ " vrf
> > > + .IR NAME " ]"
> > > + .br
> > > +@@ -2299,6 +2302,10 @@ set master device of the device (enslave device).
> > > + .BI nomaster
> > > + unset master device of the device (release device).
> > > +
> > > ++.TP
> > > ++.BI cpu " DEVICE"
> > > ++set cpu device of the dsa device.
> > > ++
> > > + .TP
> > > + .BI addrgenmode " eui64|none|stable_secret|random"
> > > + set the IPv6 address generation mode
> > > +--
> > > +2.33.1
> > > +
> > > --
> > > 2.34.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] realtek: ZyXEL GS1900-48: drop gpio-restart

[Daniel Golle]

On Sun, Feb 20, 2022 at 09:13:24PM +0100, Birger Koblitz wrote:
> Hi,
> 
> during development I came across situations where the RTL839x
> SoC's own reset did not always completely reset its state.
> U-Boot was no longer able to boot via tftp afterwards.
> This is the same situation we see on the RTL838x.
> While users will hopefully never mess up the SoC as during
> development, I would prefer a solution that reliably
> resets the device over a solution that avoids a warning.
> At least we should have a comment in, that states that
> once this is fixed in libgpiod this should be the way
> to reset the device. And we should look into fixing libgpiod.

In the case shown by Sander, gpio-restart isn't used and/or
doesn't have the desired effect of restarting the device anyway,
resulting in the next lower priority restart handler (in this case
the watchdog) to carry out the restart.
Ie. what is there right now is a no-op, at least on the device which
Sander has used to capture the log shown below.


> On 20/02/2022 19:50, Sander Vanheule wrote:
> > GPIO 5 on the RTL8231 can be used to reset the system, but gpio-restart
> > uses gpiod_set_value. This triggers a kernel warning and backtrace for
> > GPIO pins that can sleep, such as the RTL8231's. Two warnings are
> > emitted by libgpiod, and a third warning by gpio-restart itself after it
> > fails to restart the system:
> > 
> > [  106.654008] [ cut here ]
> > [  106.659240] WARNING: CPU: 0 PID: 4279 at drivers/gpio/gpiolib.c:3098 
> > gpiod_set_value+0x7c/0x108
> > [ Stack dump and call trace ]
> > [  106.826218] ---[ end trace d1de50b401f5a153 ]---
> > [  106.962992] [ cut here ]
> > [  106.968208] WARNING: CPU: 0 PID: 4279 at drivers/gpio/gpiolib.c:3098 
> > gpiod_set_value+0x7c/0x108
> > [ Stack dump and call trace ]
> > [  107.136718] ---[ end trace d1de50b401f5a154 ]---
> > [  111.087092] [ cut here ]
> > [  111.092271] WARNING: CPU: 0 PID: 4279 at 
> > drivers/power/reset/gpio-restart.c:46 gpio_restart_notify+0xc0/0xdc
> > [ Stack dump and call trace ]
> > [  111.256629] ---[ end trace d1de50b401f5a155 ]---
> > 
> > By removing gpio-restart from this device, we skip the restart-by-GPIO
> > attempt and rely only on the watchdog for restarts, which is already the
> > de facto behaviour.
> > 
> > Signed-off-by: Sander Vanheule 
> > ---
> >   target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts | 5 -
> >   1 file changed, 5 deletions(-)
> > 
> > diff --git a/target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts 
> > b/target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts
> > index dd392c5a9beb..e0e79068d2bc 100644
> > --- a/target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts
> > +++ b/target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts
> > @@ -39,11 +39,6 @@
> > gpio-controller;
> > };
> > -   gpio-restart {
> > -   compatible = "gpio-restart";
> > -   gpios = < 5 GPIO_ACTIVE_LOW>;
> > -   };
> > -
> > keys {
> > compatible = "gpio-keys-polled";
> > poll-interval = <20>;
> 
> ___
> 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 v3 2/2] iproute2: add support for cpu set

[Daniel Golle]

On Thu, Feb 03, 2022 at 01:44:12AM +0100, Ansuel Smith wrote:
> Add support for cpu set useful to set CPU port for dsa devices.

Please also document the newly added 'cpu' parameter in the command-
line output -- the manpage isn't even installed/available for OpenWrt
users.

> 
> Signed-off-by: Ansuel Smith 
> ---
>  ...101-iplink_allow_to_change_cpu_value.patch | 81 +++
>  1 file changed, 81 insertions(+)
>  create mode 100644 
> package/network/utils/iproute2/patches/101-iplink_allow_to_change_cpu_value.patch
> 
> diff --git 
> a/package/network/utils/iproute2/patches/101-iplink_allow_to_change_cpu_value.patch
>  
> b/package/network/utils/iproute2/patches/101-iplink_allow_to_change_cpu_value.patch
> new file mode 100644
> index ..1bb2bb1f
> --- /dev/null
> +++ 
> b/package/network/utils/iproute2/patches/101-iplink_allow_to_change_cpu_value.patch
> @@ -0,0 +1,81 @@
> +From 8642516618b60a2827215f2bed54d4d0aa1da48a Mon Sep 17 00:00:00 2001
> +From: Ansuel Smith 
> +Date: Sun, 23 Jan 2022 00:31:49 +0100
> +Subject: [PATCH] iplink: allow to change cpu of dsa device
> +
> +Allow to change the cpu port linked to a given dsa interface.
> +This is useful in the case of multi-CPU port DSA to assign the correct
> +port to the different user ports.
> +
> +Signed-off-by: Ansuel Smith 
> +---
> + include/uapi/linux/if_link.h | 1 +
> + ip/iplink.c  | 7 +++
> + man/man8/ip-link.8.in| 7 +++
> + 3 files changed, 15 insertions(+)
> +
> +diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
> +index 41708e26..901b5544 100644
> +--- a/include/uapi/linux/if_link.h
>  b/include/uapi/linux/if_link.h
> +@@ -341,6 +341,7 @@ enum {
> + IFLA_ALT_IFNAME, /* Alternative ifname */
> + IFLA_PERM_ADDRESS,
> + IFLA_PROTO_DOWN_REASON,
> ++IFLA_CPU,
> + 
> + /* device (sysfs) name as parent, used instead
> +  * of IFLA_LINK where there's no parent netdev
> +diff --git a/ip/iplink.c b/ip/iplink.c
> +index a3ea775d..254c35c5 100644
> +--- a/ip/iplink.c
>  b/ip/iplink.c
> +@@ -595,6 +595,7 @@ int iplink_parse(int argc, char **argv, struct 
> iplink_req *req, char **type)
> + int index = 0;
> + int group = -1;
> + int addr_len = 0;
> ++int cpu = -1;
> + int err;
> + 
> + ret = argc;
> +@@ -625,6 +626,12 @@ int iplink_parse(int argc, char **argv, struct 
> iplink_req *req, char **type)
> + } else if (matches(*argv, "link") == 0) {
> + NEXT_ARG();
> + link = *argv;
> ++} else if (matches(*argv, "cpu") == 0) {
> ++NEXT_ARG();
> ++cpu = ll_name_to_index(*argv);
> ++if (!cpu)
> ++return nodev(*argv);
> ++addattr32(>n, sizeof(*req), IFLA_CPU, cpu);
> + } else if (matches(*argv, "address") == 0) {
> + NEXT_ARG();
> + addr_len = ll_addr_a2n(abuf, sizeof(abuf), *argv);
> +diff --git a/man/man8/ip-link.8.in b/man/man8/ip-link.8.in
> +index 19a0c9ca..406db8ad 100644
> +--- a/man/man8/ip-link.8.in
>  b/man/man8/ip-link.8.in
> +@@ -152,6 +152,9 @@ ip-link \- network device configuration
> + .br
> + .RB "[ " nomaster " ]"
> + .br
> ++.RB "[ " cpu
> ++.IR DEVICE " ]"
> ++.br
> + .RB "[ " vrf
> + .IR NAME " ]"
> + .br
> +@@ -2299,6 +2302,10 @@ set master device of the device (enslave device).
> + .BI nomaster
> + unset master device of the device (release device).
> + 
> ++.TP
> ++.BI cpu " DEVICE"
> ++set cpu device of the dsa device.
> ++
> + .TP
> + .BI addrgenmode " eui64|none|stable_secret|random"
> + set the IPv6 address generation mode
> +-- 
> +2.33.1
> +
> -- 
> 2.34.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 v3 1/2] linux: introduce multi-cpu dsa patch

[Daniel Golle]

On Thu, Feb 03, 2022 at 01:44:11AM +0100, Ansuel Smith wrote:
> Add support for multi-cpu dsa. This is a reworked version of the RFC patch
> proposed some time ago.
> By default every dsa port is connected to the first cpu port and the command
> 'ip link set PORT cpu CPU_PORT' can be used to change the used cpu port at
> runtime.

The current behavior with this patch applied is quite the opposite:
All user ports get assigned to the *last* CPU port.

Apart from that this looks good so far.

> A specific function port_change_cpu_port is required to correctly setup the
> port on cpu change request.
> 
> Signed-off-by: Ansuel Smith 
> ---
>  ...net-dsa-allow-for-multiple-CPU-ports.patch |  97 +++
>  ...add-ndo-for-setting-the-cpu-proprety.patch | 113 ++
>  ...t-ndo_set_cpu-for-changing-DSA-port-.patch | 100 
>  ...clude-net-add-dsa_cpu_ports-function.patch |  39 ++
>  4 files changed, 349 insertions(+)
>  create mode 100644 
> target/linux/generic/hack-5.10/780-1-net-dsa-allow-for-multiple-CPU-ports.patch
>  create mode 100644 
> target/linux/generic/hack-5.10/780-2-net-add-ndo-for-setting-the-cpu-proprety.patch
>  create mode 100644 
> target/linux/generic/hack-5.10/780-3-net-dsa-implement-ndo_set_cpu-for-changing-DSA-port-.patch
>  create mode 100644 
> target/linux/generic/hack-5.10/780-4-include-net-add-dsa_cpu_ports-function.patch
> 
> diff --git 
> a/target/linux/generic/hack-5.10/780-1-net-dsa-allow-for-multiple-CPU-ports.patch
>  
> b/target/linux/generic/hack-5.10/780-1-net-dsa-allow-for-multiple-CPU-ports.patch
> new file mode 100644
> index ..9b4a57c6
> --- /dev/null
> +++ 
> b/target/linux/generic/hack-5.10/780-1-net-dsa-allow-for-multiple-CPU-ports.patch
> @@ -0,0 +1,97 @@
> +From 48d1e9543273c7670ebef15a4d27b13023895a28 Mon Sep 17 00:00:00 2001
> +From: =?UTF-8?q?Marek=20Beh=C3=BAn?= 
> +Date: Sat, 24 Aug 2019 04:42:48 +0200
> +Subject: [PATCH 1/4] net: dsa: allow for multiple CPU ports
> +MIME-Version: 1.0
> +Content-Type: text/plain; charset=UTF-8
> +Content-Transfer-Encoding: 8bit
> +
> +Allow for multiple CPU ports in a DSA switch tree. The default assing
> +logic is still used where the first defined CPU port is selected for all
> +the user ports. The CPU port has to be changed at runtime.
> +
> +Signed-off-by: Marek Behún 
> +---
> + net/dsa/dsa2.c | 22 ++
> + 1 file changed, 14 insertions(+), 8 deletions(-)
> +
> +diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c
> +index 183003e45762..4a8de5e2f0f5 100644
> +--- a/net/dsa/dsa2.c
>  b/net/dsa/dsa2.c
> +@@ -240,7 +240,7 @@ static int dsa_tree_setup_default_cpu(struct 
> dsa_switch_tree *dst)
> + return 0;
> + }
> + 
> +-static void dsa_tree_teardown_default_cpu(struct dsa_switch_tree *dst)
> ++static void dsa_tree_teardown_default_cpus(struct dsa_switch_tree *dst)
> + {
> + struct dsa_port *dp;
> + 
> +@@ -553,7 +553,7 @@ static void dsa_tree_teardown_switches(struct 
> dsa_switch_tree *dst)
> + dsa_switch_teardown(dp->ds);
> + }
> + 
> +-static int dsa_tree_setup_master(struct dsa_switch_tree *dst)
> ++static int dsa_tree_setup_masters(struct dsa_switch_tree *dst)
> + {
> + struct dsa_port *dp;
> + int err;
> +@@ -562,14 +562,20 @@ static int dsa_tree_setup_master(struct 
> dsa_switch_tree *dst)
> + if (dsa_port_is_cpu(dp)) {
> + err = dsa_master_setup(dp->master, dp);
> + if (err)
> +-return err;
> ++goto teardown;
> + }
> + }
> + 
> + return 0;
> ++teardown:
> ++list_for_each_entry(dp, >ports, list)
> ++if (dsa_port_is_cpu(dp))
> ++dsa_master_teardown(dp->master);
> ++
> ++return err;
> + }
> + 
> +-static void dsa_tree_teardown_master(struct dsa_switch_tree *dst)
> ++static void dsa_tree_teardown_masters(struct dsa_switch_tree *dst)
> + {
> + struct dsa_port *dp;
> + 
> +@@ -601,7 +607,7 @@ static int dsa_tree_setup(struct dsa_switch_tree *dst)
> + if (err)
> + goto teardown_default_cpu;
> + 
> +-err = dsa_tree_setup_master(dst);
> ++err = dsa_tree_setup_masters(dst);
> + if (err)
> + goto teardown_switches;
> + 
> +@@ -614,7 +620,7 @@ static int dsa_tree_setup(struct dsa_switch_tree *dst)
> + teardown_switches:
> + dsa_tree_teardown_switches(dst);
> + teardown_default_cpu:
> +-dsa_tree_teardown_default_cpu(dst);
> ++dsa_tree_teardown_default_cpus(dst);
> + 
> + return err;
> + }
> +@@ -626,11 +632,11 @@ static void dsa_tree_teardown(struct dsa_switch_tree 
> *dst)
> + if (!dst->setup)
> + return;
> + 
> +-dsa_tree_teardown_master(dst);
> ++dsa_tree_teardown_masters(dst);
> + 
> + dsa_tree_teardown_switches(dst);
> + 
> +-dsa_tree_teardown_default_cpu(dst);
> ++dsa_tree_teardown_default_cpus(dst);
> + 
> + list_for_each_entry_safe(dl, next, >rtable, list) {
> + 

Re: [RFC] ApkWrt

[Daniel Golle]

On Sat, Feb 12, 2022 at 10:32:09PM +0100, Enrico Mioso wrote:
> Hello!
> thanks for your interesting work!
> 
> Out of curiosity - did you use extroot or some other mean to run the Alpine 
> Linux Container?

APK3 has the ability to manage different storage layers, one of them
being the normal rootfs. We use that just like we used opkg before.


For containers, we may use special packages which will be installed
into another storage layer (using 'uvol').
Then uxc (a minimalist OCI run-time based on OpenWrt's procd-ujail)
can be used to setup the container environment.

The idea is that in future we will have a binary repository which will
contain container packages, such as base-installations of popular
Linux distributions (I've packaged Alpine and Debian for now) or
complete exports of existing containerzied services (such as PiHole
or Jellyfin).
As a result, users should be able to manage containers just like they
would install/update/remove regular packages using the package
manager.

Ie.
apk add jellyfin
should create a storage volume and write the rootfs of the container
there (as well as OCI run-time config.json) and register the
container with uxc.

If selected to launch automatically when the system is started, uxc
will launch the container automatically once the storage volume becomes
available during boot up.

I hope this makes it a bit more clear.



> 
> Thanks!
> Enrico
> 
> 
> On Sat, 12 Feb 2022, Paul Spooren wrote:
> 
> > Date: Sat, 12 Feb 2022 14:16:05
> > From: Paul Spooren 
> > To: openwrt-devel 
> > Cc: Ariadne Conill ,
> > Daniel Golle , Timo Teras ,
> > John Crispin 
> > Subject: [RFC] ApkWrt
> > 
> > Hi all,
> > 
> > For the last year or so[1] I’ve been working on replacing the package 
> > manager OPKG with APK (Alpine Package Keeper)[2]. Different from our OPKG 
> > fork is APK an actively developed project. OPKG is replaced entirely, both 
> > on device as well as the build system.
> > 
> > Using some CI I started to build all available snapshot firmware images and 
> > published them for others to test[3]. Some targets fail to build but I’m 
> > working on it. Please feel free to give it a try and provide feedback!
> > 
> > At this point only the base system is compiled without the community feeds, 
> > the installation of remote packages already works (e.g. `apk add tc-full`). 
> > Other commands like `apk audit` allow system integrity checks and more.
> > 
> > The SDK already works to create `.apk` packages, the ImageBuilder requires 
> > a bit more work. Overall APK still depends on OpenSSL and libfetch, after 
> > getting the base up and running I’ll start to look into replacing those 
> > with more lightweight alternatives like WolfSSL and uclient-fetch.
> > 
> > Within the next month I hope to create documentation in collaboration with 
> > Daniel to explain how APK, uvol and uxc can work together. Essentially it 
> > allows to install containers on OpenWrt devices. Just a few days ago we ran 
> > Alpine Linux within a container on a Belkin RT3200, simply installed from 
> > an `alpine.apk` package, the same works for Debian containers. In future 
> > this could allow to run arbitrary container setups on routers.
> > 
> > This work required a bunch of help, so thanks to John, Timo, Ariadne and 
> > Daniel!
> > 
> > Best,
> > Paul
> > 
> > [1]: https://github.com/openwrt/openwrt/pull/4294
> > [2]: https://gitlab.alpinelinux.org/alpine/apk-tools
> > [3]: https://downloads.asu.aparcar.org/apkwrt/targets/
> > 
> > 
> > ___
> > 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: [RFC] ApkWrt

[Daniel Golle]

On Sat, Feb 12, 2022 at 02:28:40PM +, Lucas Ramage wrote:
> This is incredible work Paul!
> 
> If I were running Alpine, would I be able to install an OpenWrt repository in 
> /etc/apk/repositories and install OpenWrt packages?

At this point Alpine is still using APK version 2.2 while Paul's ApkWrt
is already using the upcoming APK 3.0 (which comes with a new index and
database format).
Once Alpine Linux will have switched to APK 3.0, packages from OpenWrt
should work on Alpine in most cases. It's a bit like installing
packages from Ubuntu on Debian. In most cases it just works.

> 
> Would I be able to copy my APKBUILDS over from Alpine's aports repository and 
> easily port them over to OpenWrt?

No, as OpenWrt is not using APKBUILD but rather we kept our
build and packaging system as-is and just use that to generate APK
packages instead of opkg's IPK.

> 
> I look forward to reading the documentation.
> 
> Regards,
> 
> On February 12, 2022 1:16:05 PM UTC, Paul Spooren  wrote:
> >Hi all,
> >
> >For the last year or so[1] I’ve been working on replacing the package 
> >manager OPKG with APK (Alpine Package Keeper)[2]. Different from our OPKG 
> >fork is APK an actively developed project. OPKG is replaced entirely, both 
> >on device as well as the build system.
> >
> >Using some CI I started to build all available snapshot firmware images and 
> >published them for others to test[3]. Some targets fail to build but I’m 
> >working on it. Please feel free to give it a try and provide feedback!
> >
> >At this point only the base system is compiled without the community feeds, 
> >the installation of remote packages already works (e.g. `apk add tc-full`). 
> >Other commands like `apk audit` allow system integrity checks and more.
> >
> >The SDK already works to create `.apk` packages, the ImageBuilder requires a 
> >bit more work. Overall APK still depends on OpenSSL and libfetch, after 
> >getting the base up and running I’ll start to look into replacing those with 
> >more lightweight alternatives like WolfSSL and uclient-fetch.
> >
> >Within the next month I hope to create documentation in collaboration with 
> >Daniel to explain how APK, uvol and uxc can work together. Essentially it 
> >allows to install containers on OpenWrt devices. Just a few days ago we ran 
> >Alpine Linux within a container on a Belkin RT3200, simply installed from an 
> >`alpine.apk` package, the same works for Debian containers. In future this 
> >could allow to run arbitrary container setups on routers.
> >
> >This work required a bunch of help, so thanks to John, Timo, Ariadne and 
> >Daniel!
> >
> >Best,
> >Paul
> >
> >[1]: https://github.com/openwrt/openwrt/pull/4294
> >[2]: https://gitlab.alpinelinux.org/alpine/apk-tools
> >[3]: https://downloads.asu.aparcar.org/apkwrt/targets/
> >
> >
> >___
> >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: [PATCH v3] kernel: backport MT7530 IRQ support

[Daniel Golle]

On Thu, Feb 10, 2022 at 12:00:25PM +0800, DENG Qingfang wrote:
> Support MT7530 PHY link change interrupts, and enable for MT7621.
> 
> For external MT7530, a GPIO IRQ line is required, which is
> board-specific, so it should be added to each DTS. In case the
> interrupt-controller property is missing, it will fall back to
> polling mode.

I've tried building this and it breaks. See comments inline:
> 
> Signed-off-by: DENG Qingfang 
> ---
>  ...net-dsa-mt7530-add-interrupt-support.patch | 417 ++
>  target/linux/ramips/dts/mt7621.dtsi   |   3 +
>  2 files changed, 420 insertions(+)
>  create mode 100644 
> target/linux/generic/backport-5.10/772-v5.14-net-dsa-mt7530-add-interrupt-support.patch
> 
> diff --git 
> a/target/linux/generic/backport-5.10/772-v5.14-net-dsa-mt7530-add-interrupt-support.patch
>  
> b/target/linux/generic/backport-5.10/772-v5.14-net-dsa-mt7530-add-interrupt-support.patch
> new file mode 100644
> index 00..47ac779efa
> --- /dev/null
> +++ 
> b/target/linux/generic/backport-5.10/772-v5.14-net-dsa-mt7530-add-interrupt-support.patch
> @@ -0,0 +1,417 @@
> +From ba751e28d44255744a30190faad0ca09b455c44d Mon Sep 17 00:00:00 2001
> +From: DENG Qingfang 
> +Date: Wed, 19 May 2021 11:32:00 +0800
> +Subject: [PATCH] net: dsa: mt7530: add interrupt support
> +
> +Add support for MT7530 interrupt controller to handle internal PHYs.
> +In order to assign an IRQ number to each PHY, the registration of MDIO bus
> +is also done in this driver.
> +
> +Signed-off-by: DENG Qingfang 
> +Reviewed-by: Andrew Lunn 
> +Reviewed-by: Florian Fainelli 
> +Reviewed-by: Vladimir Oltean 
> +Signed-off-by: David S. Miller 
> +---
> + drivers/net/dsa/mt7530.c | 263 +++
> + drivers/net/dsa/mt7530.h |  21 +++-
> + 2 files changed, 255 insertions(+), 29 deletions(-)
> +
> +--- a/drivers/net/dsa/mt7530.c
>  b/drivers/net/dsa/mt7530.c
> +@@ -10,6 +10,7 @@
> + #include 
> + #include 
> + #include 
> ++#include 
> + #include 
> + #include 
> + #include 
> +@@ -602,18 +603,14 @@ mt7530_mib_reset(struct dsa_switch *ds)
> + mt7530_write(priv, MT7530_MIB_CCR, CCR_MIB_ACTIVATE);
> + }
> + 
> +-static int mt7530_phy_read(struct dsa_switch *ds, int port, int regnum)
> ++static int mt7530_phy_read(struct mt7530_priv *priv, int port, int regnum)
> + {
> +-struct mt7530_priv *priv = ds->priv;
> +-
> + return mdiobus_read_nested(priv->bus, port, regnum);
> + }
> + 
> +-static int mt7530_phy_write(struct dsa_switch *ds, int port, int regnum,
> ++static int mt7530_phy_write(struct mt7530_priv *priv, int port, int regnum,
> + u16 val)
> + {
> +-struct mt7530_priv *priv = ds->priv;
> +-
> + return mdiobus_write_nested(priv->bus, port, regnum, val);
> + }
> + 
> +@@ -791,9 +788,8 @@ out:
> + }
> + 
> + static int
> +-mt7531_ind_phy_read(struct dsa_switch *ds, int port, int regnum)
> ++mt7531_ind_phy_read(struct mt7530_priv *priv, int port, int regnum)
> + {
> +-struct mt7530_priv *priv = ds->priv;
> + int devad;
> + int ret;
> + 
> +@@ -809,10 +805,9 @@ mt7531_ind_phy_read(struct dsa_switch *d
> + }
> + 
> + static int
> +-mt7531_ind_phy_write(struct dsa_switch *ds, int port, int regnum,
> ++mt7531_ind_phy_write(struct mt7530_priv *priv, int port, int regnum,
> +  u16 data)
> + {
> +-struct mt7530_priv *priv = ds->priv;
> + int devad;
> + int ret;
> + 
> +@@ -828,6 +823,22 @@ mt7531_ind_phy_write(struct dsa_switch *
> + return ret;
> + }
> + 
> ++static int
> ++mt753x_phy_read(struct mii_bus *bus, int port, int regnum)
> ++{
> ++struct mt7530_priv *priv = bus->priv;
> ++
> ++return priv->info->phy_read(priv, port, regnum);
> ++}
> ++
> ++static int
> ++mt753x_phy_write(struct mii_bus *bus, int port, int regnum, u16 val)
> ++{
> ++struct mt7530_priv *priv = bus->priv;
> ++
> ++return priv->info->phy_write(priv, port, regnum, val);
> ++}
> ++
> + static void
> + mt7530_get_strings(struct dsa_switch *ds, int port, u32 stringset,
> +uint8_t *data)
> +@@ -1991,6 +2002,211 @@ mt7530_setup(struct dsa_switch *ds)
> + return 0;
> + }
> + 
> ++static irqreturn_t
> ++mt7530_irq_thread_fn(int irq, void *dev_id)
> ++{
> ++struct mt7530_priv *priv = dev_id;
> ++bool handled = false;
> ++u32 val;
> ++int p;
> ++
> ++mutex_lock_nested(>bus->mdio_lock, MDIO_MUTEX_NESTED);
> ++val = mt7530_mii_read(priv, MT7530_SYS_INT_STS);
> ++mt7530_mii_write(priv, MT7530_SYS_INT_STS, val);
> ++mutex_unlock(>bus->mdio_lock);
> ++
> ++for (p = 0; p < MT7530_NUM_PHYS; p++) {
> ++if (BIT(p) & val) {
> ++unsigned int irq;
> ++
> ++irq = irq_find_mapping(priv->irq_domain, p);
> ++handle_nested_irq(irq);
> ++handled = true;
> ++}
> ++}
> ++
> ++return IRQ_RETVAL(handled);
> ++}
> ++
> ++static void
> ++mt7530_irq_mask(struct irq_data *d)

Re: [PATCH] Bugfix for OpenWrt package umdns

[Daniel Golle]

Hi Martin,

On Fri, Jan 21, 2022 at 12:37:14PM +0100, mroe...@metz-connect.com wrote:
> Hi John,
> 
> I would like to submit a patch for the OpenWrt package umdns. The patch 
> fixes a bug in the cache.c functions cache_record_find() and 
> cache_host_is_known(). In both functions, the last element of the AVL tree 
> is systematically missed, which can lead to duplicate cache entries and 
> lookup failures. The fix duplicates the correct AVL tree traversal 
> approach of cache_dump_recursive().
> 
> PS: Appologies if this message has format issues. This is my first attempt 
> to submit a patch to OpenWrt through our company IBM Notes infrastructure, 
> please let me know if the message format is unsuitable.

I've tried fixing up the new-lines, but that alone didn't do the trick
as all the white-space has apparently been mangled by the MUA.
If you can't use git-send-email, please use git-format-patch and
include the resulting file as attachment.

Please also add a short commit title heading the commit message.

Apart from that: thank you for reaching out and fixing this!


Cheers


Daniel

> 
> Best regards,
>   Martin
> 
> 
> Fix AVL tree traversal in cache_record_find() and cache_host_is_known():
> 
> The AVL tree traversal in both functions systematically misses the last
> AVL tree element. This can lead to duplicate cache entries and lookup 
> failures.
> 
> The fix duplicates the correct AVL tree traversal approach of 
> cache_dump_recursive().
> 
> Signed-off-by: Martin Röder 
> 
> --- a/cache.c
> +++ b/cache.c
> @@ -191,13 +191,10 @@ cache_record_find(char *record, int type
>  {
> struct cache_record *l = avl_find_element(, record, l, 
> avl);
>  
> -   if (!l)
> -   return NULL;
> -
> -   while (l && !avl_is_last(, >avl) && !strcmp(l->record, 
> record)) {
> +   while (l && !strcmp(l->record, record)) {
> struct cache_record *r = l;
>  
> -   l = avl_next_element(l, avl);
> +   l = !avl_is_last(, >avl) ? avl_next_element(l, 
> avl) : NULL;
> if (r->type != type)
> continue;
>  
> @@ -227,13 +224,10 @@ cache_host_is_known(char *record)
>  {
> struct cache_record *l = avl_find_element(, record, l, 
> avl);
>  
> -   if (!l)
> -   return 0;
> -
> -   while (l && !avl_is_last(, >avl) && !strcmp(l->record, 
> record)) {
> +   while (l && !strcmp(l->record, record)) {
> struct cache_record *r = l;
>  
> -   l = avl_next_element(l, avl);
> +   l = !avl_is_last(, >avl) ? avl_next_element(l, 
> avl) : NULL;
> if ((r->type != TYPE_A) && (r->type != TYPE_))
> continue;
> return 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 procd] utils: fix get_active_console when kernel returns multiple values

[Daniel Golle]

Hi Mathew,

On Tue, Jan 25, 2022 at 03:12:08AM +, Mathew McBride wrote:
> /sys/class/tty/console/active may return multiple values on
> kernels where framebuffer support is enabled but the system
> is supposed to be using a serial console.
> e.g
> $ cat /sys/class/tty/console/active
> tty0 ttyS0

On BPi-R2 (which got HDMI with console) I'm seeing this:
root@OpenWrt:~# cat /sys/class/tty/console/active
ttyS2 tty1

And I suspect it will be the same at least for

linux/tegra/image/generic-bootscript:setenv bootargs "root=PARTUUID=${ptuuid} 
rw rootwait console=ttyS0,115200 console=tty0"
linux/bcm27xx/image/cmdline.txt:console=serial0,115200 console=tty1 
root=/dev/mmcblk0p2 rootfstype=squashfs,ext4 rootwait
linux/rockchip/image/mmc.bootscript:setenv bootargs "console=ttyS2,150 
console=tty1 earlycon=uart8250,mmio32,0xff1a root=PARTUUID=${uuid} rw 
rootwait"

as the order of console in that sysfs file apparently corresponds to
the order of console= arguments passed via kernel cmdline.

bcm27xx, mt7623 and tegra enable the frame-buffer console via inittab,
while rockchip doesn't ship /etc/inittab.

> 
> On such systems, tty0 is a dummy console:
> [0.008273] Console: colour dummy device 80x25
> [0.012742] printk: console [tty0] enabled
> 
> The serial console doesn't appear until much later:
> [0.092468] 21c0500.serial: ttyS0 at MMIO 0x21c0500
> [1.713893] printk: console [ttyS0] enabled
> 
> So far this only appears to happen on systems using
> device tree.
> 
> In these circumstances, use the last console device
> shown in the sysfs active file.

While I agree that we need to somehow unify and solve this, just
changing the current behavior will break serial console access at least
on the targets listed above.

So either you should suggest to change the affected target to ship
/etc/inittab or supply console= kernel parameter, or we change all the
other targets above (and maybe more where console= parameter originates
from existing non-OpenWrt-built bootchain).

Does our current behaviour (using first active console) violate any
universal convention we should obey?


Cheers


Daniel

> 
> Fixes: 2cfc26f ("inittab: detect active console from kernel if no console= 
> specified")
> Signed-off-by: Mathew McBride 
> ---
>  utils/utils.c | 25 ++---
>  1 file changed, 18 insertions(+), 7 deletions(-)
> 
> diff --git a/utils/utils.c b/utils/utils.c
> index f0c4a90..43b24c6 100644
> --- a/utils/utils.c
> +++ b/utils/utils.c
> @@ -138,6 +138,10 @@ blobmsg_list_equal(struct blobmsg_list *l1, struct 
> blobmsg_list *l2)
>  char *get_active_console(char *out, int len)
>  {
>   char line[CMDLINE_SIZE + 1];
> + char *sptr, *token;
> + char *console = NULL;
> +
> + memset(line, 0, sizeof(line));
>   int fd = open("/sys/class/tty/console/active", O_RDONLY);
>   ssize_t r;
>  
> @@ -152,15 +156,22 @@ char *get_active_console(char *out, int len)
>   if (r <= 0)
>   return NULL;
>  
> - /* The active file is terminated by a newline which we need to strip */
> - char *newline = strtok(line, "\n");
> -
> - if (newline != NULL) {
> - strncpy(out, newline, len);
> - return out;
> + /* There may be multiple 'active' consoles.
> +  * On kernels that support both graphical and
> +  * serial consoles, Linux may create a 'dummy'
> +  * framebuffer console on tty0 if no other console
> +  * device has been probed yet. Often a serial
> +  * driver (e.g ttyS0) might only be probed later
> +  * in the boot process.
> +  */
> + for (token = strtok_r(line, " \t\n", ); token;
> +  token = strtok_r(NULL, " \t\n", )) {
> + strncpy(out, token, len);
> + console = out;
>   }
> + out[len-1] = '\0';
>  
> - return NULL;
> + return console;
>  }
>  
>  char* get_cmdline_val(const char* name, char* out, int len)
> -- 
> 2.30.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 firmware-utils 1/2] ptgen: add Chromium OS kernel partition support

[Daniel Golle]

On Thu, Jan 27, 2022 at 08:56:26PM -0800, Brian Norris wrote:
> On Thu, Jan 27, 2022 at 5:34 AM Daniel Golle  wrote:
> > Please see my comments inline below:
> >
> > On Sat, Jan 15, 2022 at 09:48:30PM -0800, Brian Norris wrote:
> > > [...]
> > > @@ -559,9 +585,8 @@ int main (int argc, char **argv)
> > >   uint32_t signature = 0x5452574F; /* 'OWRT' */
> > >   guid_t guid = GUID_INIT( signature, 0x2211, 0x4433, \
> > >   0x55, 0x66, 0x77, 0x88, 0x99, 0xAA, 0xBB, 0x00);
> > > - guid_t part_guid = GUID_PARTITION_BASIC_DATA;
> >
> > I think we should keep the default GUID, as there are uses for that
> > other than Chrome OS which expect a valid part_guid.
> 
> To be clear, the line you're highlighting was a dead assignment. In
> the original code, it was overwritten without ever being used.
> [...]
> So, this might be a little confusing to read, but I don't believe it
> breaks anything.

It's indeed just a bit confusing (and has been confusing also before
you ever touched it). The default to GUID_PARTITION_BASIC_DATA is
actually set in type_to_guid_and_name() function, so you are right,
it's safe to drop it from the main() function as it was already
dead code...

I'll apply your patches as-is.


Thank you!

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

Re: [PATCH firmware-utils 1/2] ptgen: add Chromium OS kernel partition support

[Daniel Golle]

Hi Brian,

thank you for taking care of liberating the Google devices ;)

Please see my comments inline below:

On Sat, Jan 15, 2022 at 09:48:30PM -0800, Brian Norris wrote:
> Chrom{ium,e} OS (shortened as "CrOS") bootloaders use a custom GPT
> partition type to locate their kernel(s), with custom attributes for
> noting properties around which partition(s) should be active and how
> many times they've been tried as part of their A/B in-place upgrade
> system.
> 
> OpenWRT doesn't use A/B updates for upgrades (instead, just shutting
> things down far enough to reprogram the necessary partitions), so all we
> need to do is tell the bootloader which one is the kernel partition, and
> how to use it (i.e., set the "successful" and "priority" attributes).
> 
> ptgen already supports some basic GPT partition creation, so just
> add support for a '-T ' argument. Currently, this
> only supports '-T cros_kernel', but it could be extended if there are
> other GPT partition types needed.
> 
> For GPT attribute and GUID definitions, see the CrOS verified boot
> sources:
> 
> https://chromium.googlesource.com/chromiumos/platform/vboot_reference/+/refs/heads/master/firmware/lib/cgptlib/include/cgptlib_internal.h
> https://chromium.googlesource.com/chromiumos/platform/vboot_reference/+/refs/heads/master/firmware/include/gpt.h
> 
> Wikipedia (!!) even notes the GUIDs:
> https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs
> 
> The GUID is also recognized in fdisk, and likely other utilities, but
> creation/manipulation is typically done via the 'cgpt' utility, provided
> as part of the Chromium vboot_reference project.
> 
> Signed-off-by: Brian Norris 
> ---
>  src/ptgen.c | 43 ++-
>  1 file changed, 38 insertions(+), 5 deletions(-)
> 
> diff --git a/src/ptgen.c b/src/ptgen.c
> index 69757c1fc7dc..7220dde42b92 100644
> --- a/src/ptgen.c
> +++ b/src/ptgen.c
> @@ -70,6 +70,10 @@ typedef struct {
>   GUID_INIT( 0x21686148, 0x6449, 0x6E6F, \
>   0x74, 0x4E, 0x65, 0x65, 0x64, 0x45, 0x46, 0x49)
>  
> +#define GUID_PARTITION_CHROME_OS_KERNEL \
> + GUID_INIT( 0xFE3A2A5D, 0x4F32, 0x41A7, \
> + 0xB7, 0x25, 0xAC, 0xCC, 0x32, 0x85, 0xA3, 0x09)
> +
>  #define GUID_PARTITION_LINUX_FIT_GUID \
>   GUID_INIT( 0xcae9be83, 0xb15f, 0x49cc, \
>   0x86, 0x3f, 0x08, 0x1b, 0x74, 0x4a, 0x2d, 0x93)
> @@ -116,7 +120,9 @@ struct partinfo {
>   int hybrid;
>   char *name;
>   short int required;
> + bool has_guid;
>   guid_t guid;
> + uint64_t gattr;  /* GPT partition attributes */
>  };
>  
>  /* GPT Partition table header */
> @@ -256,6 +262,23 @@ static inline int guid_parse(char *buf, guid_t *guid)
>   return 0;
>  }
>  
> +/*
> + * Map GPT partition types to partition GUIDs.
> + * NB: not all GPT partition types have an equivalent MBR type.
> + */
> +static inline bool parse_gpt_parttype(const char *type, struct partinfo 
> *part)
> +{
> + if (!strcmp(type, "cros_kernel")) {
> + part->has_guid = true;
> + part->guid = GUID_PARTITION_CHROME_OS_KERNEL;
> + /* Default attributes: bootable kernel. */
> + part->gattr = (1ULL << 48) |  /* priority=1 */
> +   (1ULL << 56);  /* success=1 */
> + return true;
> + }
> + return false;
> +}
> +
>  /* init an utf-16 string from utf-8 string */
>  static inline void init_utf16(char *str, uint16_t *buf, unsigned bufsize)
>  {
> @@ -416,6 +439,7 @@ static int gen_gptable(uint32_t signature, guid_t guid, 
> unsigned nr)
>   to_chs(sect - 1, pte[1].chs_end);
>   pmbr++;
>   }
> + gpte[i].attr = parts[i].gattr;
>  
>   if (parts[i].name)
>   init_utf16(parts[i].name, (uint16_t *)gpte[i].name, 
> GPT_ENTRY_NAME_SIZE / sizeof(uint16_t));
> @@ -523,7 +547,9 @@ fail:
>  
>  static void usage(char *prog)
>  {
> - fprintf(stderr, "Usage: %s [-v] [-n] [-g] -h  -s  -o 
>  [-a 0..4] [-l ] [-G ] [[-t ] [-r] [-N 
> ] -p [@]...] \n", prog);
> + fprintf(stderr, "Usage: %s [-v] [-n] [-g] -h  -s  -o 
> \n"
> + "  [-a 0..4] [-l ] [-G ]\n"
> + "  [[-t  | -T ] [-r] [-N 
> ] -p [@]...] \n", prog);
>   exit(EXIT_FAILURE);
>  }
>  
> @@ -559,9 +585,8 @@ int main (int argc, char **argv)
>   uint32_t signature = 0x5452574F; /* 'OWRT' */
>   guid_t guid = GUID_INIT( signature, 0x2211, 0x4433, \
>   0x55, 0x66, 0x77, 0x88, 0x99, 0xAA, 0xBB, 0x00);
> - guid_t part_guid = GUID_PARTITION_BASIC_DATA;

I think we should keep the default GUID, as there are uses for that
other than Chrome OS which expect a valid part_guid.

>  
> - while ((ch = getopt(argc, argv, "h:s:p:a:t:o:vnHN:gl:rS:G:")) != -1) {
> + while ((ch = getopt(argc, argv, "h:s:p:a:t:T:o:vnHN:gl:rS:G:")) != -1) {
>   

Re: [RFC PATCH v2 1/2] linux: introduce multi-cpu dsa patch

[Daniel Golle]

Please see two comments inline below

On Sun, Jan 23, 2022 at 01:35:25AM +0100, Ansuel Smith wrote:
> Add support for multi-cpu dsa. This is a reworked version of the RFC patch
> proposed some time ago.
> By default every dsa port is connected to the first cpu port and the command
> 'ip link set PORT cpu CPU_PORT' can be used to change the used cpu port at
> runtime.
> A specific function port_change_cpu_port is required to correctly setup the
> port on cpu change request.
> 
> Signed-off-by: Ansuel Smith 
> ---
>  ...net-dsa-allow_for_multiple_CPU_ports.patch | 151 ++
>  ...add_ndo_for_setting_the_cpu_property.patch | 113 +
>  ..._set_cpu_for_changing_ports_CPU_port.patch |  89 +++
>  ...clude-net-add-dsa_cpu_ports-function.patch |  34 
>  4 files changed, 387 insertions(+)
>  create mode 100644 
> target/linux/generic/hack-5.10/780-1-net-dsa-allow_for_multiple_CPU_ports.patch
>  create mode 100644 
> target/linux/generic/hack-5.10/780-2-net-add_ndo_for_setting_the_cpu_property.patch
>  create mode 100644 
> target/linux/generic/hack-5.10/780-3-net-dsa-implement_ndo_set_cpu_for_changing_ports_CPU_port.patch
>  create mode 100644 
> target/linux/generic/hack-5.10/780-4-include-net-add-dsa_cpu_ports-function.patch
> 
> diff --git 
> a/target/linux/generic/hack-5.10/780-1-net-dsa-allow_for_multiple_CPU_ports.patch
>  
> b/target/linux/generic/hack-5.10/780-1-net-dsa-allow_for_multiple_CPU_ports.patch
> new file mode 100644
> index ..7f2f349a
> --- /dev/null
> +++ 
> b/target/linux/generic/hack-5.10/780-1-net-dsa-allow_for_multiple_CPU_ports.patch
> @@ -0,0 +1,151 @@
> +From mboxrd@z Thu Jan  1 00:00:00 1970
> +Return-Path: 
> +X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
> + aws-us-west-2-korg-lkml-1.web.codeaurora.org
> +X-Spam-Level: 
> +X-Spam-Status: No, score=-9.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID,
> + 
> DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,
> + SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham
> + autolearn_force=no version=3.4.0
> +Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
> + by smtp.lore.kernel.org (Postfix) with ESMTP id 98EBDC3A5A2
> + for ; Sat, 24 Aug 2019 02:43:07 + (UTC)
> +Received: from vger.kernel.org (vger.kernel.org [209.132.180.67])
> + by mail.kernel.org (Postfix) with ESMTP id 6168A2173B
> + for ; Sat, 24 Aug 2019 02:43:07 + (UTC)
> +Authentication-Results: mail.kernel.org;
> + dkim=pass (1024-bit key) header.d=nic.cz header.i=@nic.cz 
> header.b="Kl8qU9Mx"
> +Received: (majord...@vger.kernel.org) by vger.kernel.org via listexpand
> +id S1726888AbfHXCnF (ORCPT );
> +Fri, 23 Aug 2019 22:43:05 -0400
> +Received: from mail.nic.cz ([217.31.204.67]:37268 "EHLO mail.nic.cz"
> +rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
> +id S1725807AbfHXCnD (ORCPT );
> +Fri, 23 Aug 2019 22:43:03 -0400
> +Received: from dellmb.labs.office.nic.cz (unknown 
> [IPv6:2001:1488:fffe:6:cac7:3539:7f1f:463])
> +by mail.nic.cz (Postfix) with ESMTP id 94D1E140D1E;
> +Sat, 24 Aug 2019 04:42:59 +0200 (CEST)
> +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default;
> +t=1566614579; bh=jPa21EsnWy9WksW68HSx/O+la2qm4ImIACY+K2cEnLY=;
> +h=From:To:Date;
> +b=Kl8qU9MxZdC3EQnTetDA7VbGXYIuwCO2zS6HinOo7XykIKQDlvB7jIUcH0FQLgG6T
> + BNf/aIsDASIL1PBSAlNynoTMSDf8m6I2Xo8auxQr4L6sslF683w8hY9PN7f+pYyL2R
> + FQs93FIJYSp5I2NCSktTxGFNumTvYPxA8lEqBaZo=
> +From:   =?UTF-8?q?Marek=20Beh=C3=BAn?= 
> +To: net...@vger.kernel.org
> +Cc: Andrew Lunn ,
> +Vivien Didelot ,
> +Florian Fainelli ,
> +David Ahern ,
> +Stephen Hemminger ,
> +=?UTF-8?q?Marek=20Beh=C3=BAn?= 
> +Subject: [PATCH RFC net-next 1/3] net: dsa: allow for multiple CPU ports
> +Date:   Sat, 24 Aug 2019 04:42:48 +0200
> +Message-Id: <20190824024251.4542-2-marek.be...@nic.cz>
> +X-Mailer: git-send-email 2.21.0
> +In-Reply-To: <20190824024251.4542-1-marek.be...@nic.cz>
> +References: <20190824024251.4542-1-marek.be...@nic.cz>
> +MIME-Version: 1.0
> +Content-Type: text/plain; charset=UTF-8
> +Content-Transfer-Encoding: 8bit
> +X-Virus-Scanned: clamav-milter 0.100.3 at mail.nic.cz
> +X-Virus-Status: Clean
> +Sender: netdev-ow...@vger.kernel.org
> +Precedence: bulk
> +List-ID: 
> +X-Mailing-List: net...@vger.kernel.org
> +Archived-At: 
> 
> +List-Archive: 
> +List-Post: 
> +
> +Allow for multiple CPU ports in a DSA switch tree. By default assign the
> +CPU ports to user ports in a round robin way, ie. if there are two CPU
> +ports connected to eth0 and eth1, and five user ports (lan1..lan5),
> +assign them as:
> +  lan1 <-> eth0
> +  lan2 <-> eth1
> +  lan3 <-> eth0
> +  lan4 <-> eth1
> + 

Re: [RFC PATCH v2 0/2] Add DSA MultiCPU port support

[Daniel Golle]

On Sun, Jan 23, 2022 at 01:35:24AM +0100, Ansuel Smith wrote:
> This adds the hack patches for DSA multicpu support.
> I still have to clean patch 1, 3, 4 but considering this is still a bit WIP
> I decided to clean and provide a correct patches for the final version.
> 
> This version won't change the logic by DSA that assing every port to the first
> cpu port. A init script is required to change the cpu port at runtime.

Imho we should also add patch

 From: LGA1150 
 Date: Mon, 17 May 2021 10:34:58 +0200
 Subject: [PATCH] net: dsa: add dts-property default_cpu

so this can be done in device-tree rather than using an init-script.

> This change was done for the only reason that a round-robin way can't be 
> trusted
> and is too random. Some cpu port in some switch (brcm) for example doesn't
> behave the same way and randomly assigning the cpu port would cause
> problems/malfunctions.

I agree that round-robin is not such a good idea, the commit message of
the patch itself will also have to be updated to reflect that change.

> 
> v2:
> - Rework iproute logic to not pollute link
> - Rework the round-robin cpu port assign logic
> 
> Ansuel Smith (2):
>   linux: introduce multi-cpu dsa patch
>   iproute2: add support for cpu set
> 
>  ...101-iplink_allow_to_change_cpu_value.patch |  81 ++
>  ...net-dsa-allow_for_multiple_CPU_ports.patch | 151 ++
>  ...add_ndo_for_setting_the_cpu_property.patch | 113 +
>  ..._set_cpu_for_changing_ports_CPU_port.patch |  89 +++
>  ...clude-net-add-dsa_cpu_ports-function.patch |  34 
>  5 files changed, 468 insertions(+)
>  create mode 100644 
> package/network/utils/iproute2/patches/101-iplink_allow_to_change_cpu_value.patch
>  create mode 100644 
> target/linux/generic/hack-5.10/780-1-net-dsa-allow_for_multiple_CPU_ports.patch
>  create mode 100644 
> target/linux/generic/hack-5.10/780-2-net-add_ndo_for_setting_the_cpu_property.patch
>  create mode 100644 
> target/linux/generic/hack-5.10/780-3-net-dsa-implement_ndo_set_cpu_for_changing_ports_CPU_port.patch
>  create mode 100644 
> target/linux/generic/hack-5.10/780-4-include-net-add-dsa_cpu_ports-function.patch
> 
> -- 
> 2.33.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 2/2] iproute2: add support for link set

[Daniel Golle]

On Fri, Jan 21, 2022 at 09:14:50PM +, Rui Salvaterra wrote:
> On Fri, 21 Jan 2022 at 21:11, Ansuel Smith  wrote:
> >
> > Should we follow the suggestion and add a specific attribute just for DSA?
> I believe that would be the right thing to do, but I'd like to know
> what Daniel and Marek think about it too.

While adding a new attribute for the DSA CPU port linked means more
added complexity, I still believe it's the right thing to do if that's
what would be acceptable upstream and hence significantly reduce the
burden of having to maintain and forward-port the patch locally in the
long run.
Personally I perceive the use of the existing 'set link' attribute to
be sound and aligned with it's use in other contexts, but that's most
certainly a matter of taste.

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

Re: Status of source-only targets

[Daniel Golle]

On Wed, Jan 12, 2022 at 10:50:41AM -0700, Philip Prindeville wrote:
> 
> 
> > On Jan 11, 2022, at 11:56 AM, Daniel Golle  wrote:
> > 
> > Sadly the falcon didn't really make it to fly with OpenWrt (yet).
> > It's used in a couple of GPON SFP modules, so would sure be an
> > interesting target...
> 
> 
> G.PON SFP modules?  Tell me about those!!!

See for example these threads in the forum:

https://forum.openwrt.org/t/support-zisa-op151s-gpon-onu-lantiq-sfp-module/24102/7
https://forum.openwrt.org/t/will-gpon-nokia-g-010s-a-change-sn/69602/2

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

Re: Status of source-only targets

[Daniel Golle]

On Mon, Jan 10, 2022 at 11:55:54PM +0100, Paul Spooren wrote:
> Hi,
> 
> Looking at openwrt.git I find seven targets with the source-only tag. The tag 
> means the build infrastructure skips building the targets. Does it make sense 
> to carry those target in tree or should we move them to our target archive?
> 
> - lantiq/falcon

Sadly the falcon didn't really make it to fly with OpenWrt (yet).
It's used in a couple of GPON SFP modules, so would sure be an
interesting target...

> - oxnas/ox810se

ox810se has recently seen some love upstream, Ethernet may work in
5.17+ and we could backport that for testing if anyone got the
hardware flying around.

> - malta/le64
> - malta/le
> - malta/be64

Those are very helpful for testing MIPS(el)32/64 and should be kept.

> 
> Those two targets are fairly new and likely “not fully ready yet”, do we 
> track progress somewhere?
> 
> - bmips
> - qoriq
> 
> Thanks for all further comments!
> 
> Best,
> 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: Switch issues and CI to GitHub

[Daniel Golle]

On Fri, Jan 07, 2022 at 12:07:38PM +, Sam Kuper wrote:
> On Fri, Jan 07, 2022 at 10:34:34AM +0100, Paul Spooren wrote:
> > Instead of maintaining flyspray and the server, I’d like to export all
> > flyspray issues, migrate them to GitHub and open GitHub issues for
> > openwrt/openwrt to the public.
> 
> Please don't do this.  GitHub has substantial accessibility and privacy
> flaws, compared to other options - and fails ethical code/bug-hosting
> criteria:  https://www.gnu.org/software/repo-criteria-evaluation.html
> 
> Please either stick with existing arrangements, or go with an ethical,
> accessible code/bug-host (e.g. SourceHut https://sr.ht ).

+1

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

Re: [PATCH] kernel/5.10: disable CONFIG_DEVTMPFS{,_MOUNT}

[Daniel Golle]

On Wed, Jan 05, 2022 at 03:54:56PM +, Daniel Golle wrote:
> On Wed, Jan 05, 2022 at 03:51:09PM +, Rui Salvaterra wrote:
> > We rely on procd to create/populate /dev for us. These can be safely 
> > disabled.
> 
> NACK. Disabling this will afaik break LXC and containers relying on it.
> We could enable it selectively on !SMALL_FLASH instead, to safe space
> on targets where anyway there are no resources for containers.

Just realizing that this is already defined in Config-kernel.in, so
removing it from the target configs is the right thing to do, just
the reasoning is different ;)

> 
> > 
> > Signed-off-by: Rui Salvaterra 
> > ---
> >  target/linux/archs38/config-5.10  | 1 -
> >  target/linux/layerscape/armv7/config-5.10 | 2 --
> >  target/linux/layerscape/armv8_64b/config-5.10 | 2 --
> >  target/linux/mediatek/mt7622/config-5.10  | 2 --
> >  target/linux/oxnas/config-5.10| 2 --
> >  target/linux/rockchip/armv8/config-5.10   | 2 --
> >  6 files changed, 11 deletions(-)
> > 
> > diff --git a/target/linux/archs38/config-5.10 
> > b/target/linux/archs38/config-5.10
> > index 5ba3877a64..b082a47331 100644
> > --- a/target/linux/archs38/config-5.10
> > +++ b/target/linux/archs38/config-5.10
> > @@ -84,7 +84,6 @@ CONFIG_CRYPTO_RNG=y
> >  CONFIG_CRYPTO_RNG2=y
> >  CONFIG_CRYPTO_RNG_DEFAULT=y
> >  CONFIG_CRYPTO_SHA256=y
> > -CONFIG_DEVTMPFS=y
> >  CONFIG_DMADEVICES=y
> >  CONFIG_DMA_DIRECT_REMAP=y
> >  CONFIG_DMA_ENGINE=y
> > diff --git a/target/linux/layerscape/armv7/config-5.10 
> > b/target/linux/layerscape/armv7/config-5.10
> > index 0ec201030f..dd97d67cba 100644
> > --- a/target/linux/layerscape/armv7/config-5.10
> > +++ b/target/linux/layerscape/armv7/config-5.10
> > @@ -170,8 +170,6 @@ CONFIG_DETECT_HUNG_TASK=y
> >  # CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND is not set
> >  # CONFIG_DEVFREQ_GOV_USERSPACE is not set
> >  # CONFIG_DEVFREQ_THERMAL is not set
> > -CONFIG_DEVTMPFS=y
> > -CONFIG_DEVTMPFS_MOUNT=y
> >  CONFIG_DMADEVICES=y
> >  CONFIG_DMA_CMA=y
> >  CONFIG_DMA_ENGINE=y
> > diff --git a/target/linux/layerscape/armv8_64b/config-5.10 
> > b/target/linux/layerscape/armv8_64b/config-5.10
> > index aa4be18f05..03c85a5aef 100644
> > --- a/target/linux/layerscape/armv8_64b/config-5.10
> > +++ b/target/linux/layerscape/armv8_64b/config-5.10
> > @@ -204,8 +204,6 @@ CONFIG_DECOMPRESS_LZMA=y
> >  CONFIG_DECOMPRESS_LZO=y
> >  CONFIG_DECOMPRESS_XZ=y
> >  CONFIG_DETECT_HUNG_TASK=y
> > -CONFIG_DEVTMPFS=y
> > -CONFIG_DEVTMPFS_MOUNT=y
> >  CONFIG_DIMLIB=y
> >  CONFIG_DMADEVICES=y
> >  CONFIG_DMATEST=y
> > diff --git a/target/linux/mediatek/mt7622/config-5.10 
> > b/target/linux/mediatek/mt7622/config-5.10
> > index da1b283f70..946cab7738 100644
> > --- a/target/linux/mediatek/mt7622/config-5.10
> > +++ b/target/linux/mediatek/mt7622/config-5.10
> > @@ -134,8 +134,6 @@ CONFIG_CRYPTO_SHA256=y
> >  CONFIG_CRYPTO_ZSTD=y
> >  CONFIG_DCACHE_WORD_ACCESS=y
> >  CONFIG_DEBUG_MISC=y
> > -CONFIG_DEVTMPFS=y
> > -CONFIG_DEVTMPFS_MOUNT=y
> >  CONFIG_DIMLIB=y
> >  CONFIG_DMADEVICES=y
> >  CONFIG_DMATEST=y
> > diff --git a/target/linux/oxnas/config-5.10 b/target/linux/oxnas/config-5.10
> > index b0e4789d1e..93fbf5386d 100644
> > --- a/target/linux/oxnas/config-5.10
> > +++ b/target/linux/oxnas/config-5.10
> > @@ -117,8 +117,6 @@ CONFIG_DECOMPRESS_LZ4=y
> >  CONFIG_DECOMPRESS_LZMA=y
> >  CONFIG_DECOMPRESS_LZO=y
> >  CONFIG_DECOMPRESS_XZ=y
> > -CONFIG_DEVTMPFS=y
> > -CONFIG_DEVTMPFS_MOUNT=y
> >  CONFIG_DMA_CMA=y
> >  CONFIG_DMA_REMAP=y
> >  CONFIG_DNOTIFY=y
> > diff --git a/target/linux/rockchip/armv8/config-5.10 
> > b/target/linux/rockchip/armv8/config-5.10
> > index 9769bab72d..1063489dc6 100644
> > --- a/target/linux/rockchip/armv8/config-5.10
> > +++ b/target/linux/rockchip/armv8/config-5.10
> > @@ -167,8 +167,6 @@ CONFIG_DEVFREQ_GOV_USERSPACE=y
> >  # CONFIG_DEVFREQ_THERMAL is not set
> >  CONFIG_DEVMEM=y
> >  # CONFIG_DEVPORT is not set
> > -CONFIG_DEVTMPFS=y
> > -CONFIG_DEVTMPFS_MOUNT=y
> >  CONFIG_DMADEVICES=y
> >  CONFIG_DMA_CMA=y
> >  CONFIG_DMA_DIRECT_REMAP=y
> > -- 
> > 2.34.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

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

Re: [PATCH] kernel/5.10: disable CONFIG_DEVTMPFS{,_MOUNT}

[Daniel Golle]

On Wed, Jan 05, 2022 at 03:51:09PM +, Rui Salvaterra wrote:
> We rely on procd to create/populate /dev for us. These can be safely disabled.

NACK. Disabling this will afaik break LXC and containers relying on it.
We could enable it selectively on !SMALL_FLASH instead, to safe space
on targets where anyway there are no resources for containers.

> 
> Signed-off-by: Rui Salvaterra 
> ---
>  target/linux/archs38/config-5.10  | 1 -
>  target/linux/layerscape/armv7/config-5.10 | 2 --
>  target/linux/layerscape/armv8_64b/config-5.10 | 2 --
>  target/linux/mediatek/mt7622/config-5.10  | 2 --
>  target/linux/oxnas/config-5.10| 2 --
>  target/linux/rockchip/armv8/config-5.10   | 2 --
>  6 files changed, 11 deletions(-)
> 
> diff --git a/target/linux/archs38/config-5.10 
> b/target/linux/archs38/config-5.10
> index 5ba3877a64..b082a47331 100644
> --- a/target/linux/archs38/config-5.10
> +++ b/target/linux/archs38/config-5.10
> @@ -84,7 +84,6 @@ CONFIG_CRYPTO_RNG=y
>  CONFIG_CRYPTO_RNG2=y
>  CONFIG_CRYPTO_RNG_DEFAULT=y
>  CONFIG_CRYPTO_SHA256=y
> -CONFIG_DEVTMPFS=y
>  CONFIG_DMADEVICES=y
>  CONFIG_DMA_DIRECT_REMAP=y
>  CONFIG_DMA_ENGINE=y
> diff --git a/target/linux/layerscape/armv7/config-5.10 
> b/target/linux/layerscape/armv7/config-5.10
> index 0ec201030f..dd97d67cba 100644
> --- a/target/linux/layerscape/armv7/config-5.10
> +++ b/target/linux/layerscape/armv7/config-5.10
> @@ -170,8 +170,6 @@ CONFIG_DETECT_HUNG_TASK=y
>  # CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND is not set
>  # CONFIG_DEVFREQ_GOV_USERSPACE is not set
>  # CONFIG_DEVFREQ_THERMAL is not set
> -CONFIG_DEVTMPFS=y
> -CONFIG_DEVTMPFS_MOUNT=y
>  CONFIG_DMADEVICES=y
>  CONFIG_DMA_CMA=y
>  CONFIG_DMA_ENGINE=y
> diff --git a/target/linux/layerscape/armv8_64b/config-5.10 
> b/target/linux/layerscape/armv8_64b/config-5.10
> index aa4be18f05..03c85a5aef 100644
> --- a/target/linux/layerscape/armv8_64b/config-5.10
> +++ b/target/linux/layerscape/armv8_64b/config-5.10
> @@ -204,8 +204,6 @@ CONFIG_DECOMPRESS_LZMA=y
>  CONFIG_DECOMPRESS_LZO=y
>  CONFIG_DECOMPRESS_XZ=y
>  CONFIG_DETECT_HUNG_TASK=y
> -CONFIG_DEVTMPFS=y
> -CONFIG_DEVTMPFS_MOUNT=y
>  CONFIG_DIMLIB=y
>  CONFIG_DMADEVICES=y
>  CONFIG_DMATEST=y
> diff --git a/target/linux/mediatek/mt7622/config-5.10 
> b/target/linux/mediatek/mt7622/config-5.10
> index da1b283f70..946cab7738 100644
> --- a/target/linux/mediatek/mt7622/config-5.10
> +++ b/target/linux/mediatek/mt7622/config-5.10
> @@ -134,8 +134,6 @@ CONFIG_CRYPTO_SHA256=y
>  CONFIG_CRYPTO_ZSTD=y
>  CONFIG_DCACHE_WORD_ACCESS=y
>  CONFIG_DEBUG_MISC=y
> -CONFIG_DEVTMPFS=y
> -CONFIG_DEVTMPFS_MOUNT=y
>  CONFIG_DIMLIB=y
>  CONFIG_DMADEVICES=y
>  CONFIG_DMATEST=y
> diff --git a/target/linux/oxnas/config-5.10 b/target/linux/oxnas/config-5.10
> index b0e4789d1e..93fbf5386d 100644
> --- a/target/linux/oxnas/config-5.10
> +++ b/target/linux/oxnas/config-5.10
> @@ -117,8 +117,6 @@ CONFIG_DECOMPRESS_LZ4=y
>  CONFIG_DECOMPRESS_LZMA=y
>  CONFIG_DECOMPRESS_LZO=y
>  CONFIG_DECOMPRESS_XZ=y
> -CONFIG_DEVTMPFS=y
> -CONFIG_DEVTMPFS_MOUNT=y
>  CONFIG_DMA_CMA=y
>  CONFIG_DMA_REMAP=y
>  CONFIG_DNOTIFY=y
> diff --git a/target/linux/rockchip/armv8/config-5.10 
> b/target/linux/rockchip/armv8/config-5.10
> index 9769bab72d..1063489dc6 100644
> --- a/target/linux/rockchip/armv8/config-5.10
> +++ b/target/linux/rockchip/armv8/config-5.10
> @@ -167,8 +167,6 @@ CONFIG_DEVFREQ_GOV_USERSPACE=y
>  # CONFIG_DEVFREQ_THERMAL is not set
>  CONFIG_DEVMEM=y
>  # CONFIG_DEVPORT is not set
> -CONFIG_DEVTMPFS=y
> -CONFIG_DEVTMPFS_MOUNT=y
>  CONFIG_DMADEVICES=y
>  CONFIG_DMA_CMA=y
>  CONFIG_DMA_DIRECT_REMAP=y
> -- 
> 2.34.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: procd/ujail question

[Daniel Golle]

On Fri, Dec 10, 2021 at 04:03:34PM +0100, e9hack wrote:
> 
> Hi,
> 
> usually the files for a jailed process must be given via procd_add_jail_mount 
> or procd_add_jail_mount_rw. It looks like that this isn't necessary for 
> hostapd. Why not? I can't found this two parameters in '/etc/init.d/wpad'.

Using namespaces is not mandatory when using other ujail features (ie.
capabilities or seccomp can be used also without namespaces).

So hostapd doesn't use mount/filesystem namespaces at this moment but
rather only uses ujail to retain some capabilities while being run as
user and group 'network' (instead of 'root').
I choose to do it in that way because the files needed for hostapd at
run-time depend on the configuration (think: tls certificates or
credentials stored in files) which isn't known by the init script and
may also change without having to restart the process. Hence limiting
filesystem access would always conflict with configurations which are
using addtional files.

Another example is umdns which uses ujail only for setting up seccomp
filter and doesn't make use of any other ujail features.

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

Re: procd/ujail behaviour

[Daniel Golle]

Hi Hartmut,

yes, this is a known problem affecting jailed services not terminating
on TERM signal (or not terminating fast enough).
As trapping KILL signal is not possible, simply forwarding this signal
to the jailed process is not possible.

I have a patch ready which lets ujail handle the timeout and sending of
SIGKILL (instead of letting procd send SIGKILL to ujail which will not
have the desired effect). However, in this way the termination timeout
can not be adjusted and is hard-coded to 5 seconds for now (passing the
term-timeout as paramter to ujail would be possible, but I haven't
implemented that yet).

Another option would be to hijack another signal (SIGUSR2, for example)
to be sent to ujail by procd which would make ujail then send SIGKILL
to the jailed process. While hat approach is more easy to implement and
allows using the existing timeout logic in procd (which is adjustable),
it then no longer allows forwarding that hijacked signal (SIGUSR2) to
the jailed process which is also not nice.

An even more complicated option would be to let ujail *always* expose
an ubus object and then let procd tell ujail to send signals via ubus.
(this is currently implemented for OCI containers, but not for ujail'ed
services).

It'd be nice if you can try the patch attached (to be put in
package/system/procd/patches) and let me know what you think.


Cheers


Daniel


On Fri, Dec 10, 2021 at 02:12:30PM +0100, e9hack wrote:
> 
> Hi,
> 
> I did update the init script for stubby, that it runs with ujail. Stubby does 
> run, but it isn't possible to stop it via '/etc/init.d/stubby stop'. The 
> ujail process is stopped, but stubby itself not. It looks like that it isn't 
> possible to stop stubby with SIGTERM. Stubby will be ended by SIGKILL only. 
> Procd sends first SIGTERM and than SIGKILL to ujail, but ujail sends SIGTERM 
> only. Either ujail doesn't send SIGKILL if the jailed process doesn't 
> terminate or procd sends SIGKILL to early so that ujail can't send SIGKILL 
> any more. In the log I see the following messages:
> 
> Fri Dec 10 13:35:52 2021 user.err : jail: forwarding signal 15 to the jailed 
> process
> Fri Dec 10 13:35:52 2021 daemon.err stubby[6669]: jail: forwarding signal 15 
> to the jailed process
> Fri Dec 10 13:35:57 2021 daemon.info procd: Instance stubby::stubby pid 6669 
> not stopped on SIGTERM, sending SIGKILL instead
> 
> 6669 was the pid of the ujail process.
> 
> In ujail, I changed a few DEBUG() calls to ERROR(). Without this, the first 
> two lines are not shown.
> 
> Any ideas?
> 
> Regards,
> Hartmut
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>From 478ef55cdc2d0e0a615a4fb19430d2ca34c21b31 Mon Sep 17 00:00:00 2001
From: Daniel Golle 
Date: Fri, 10 Dec 2021 13:48:59 +
Subject: [PATCH] jail: make sure jailed process is terminated

Don't ever send SIGKILL to ujail, as that will kill ujail but not the
jailed process.
Instead, let ujail send SIGKILL in case of SIGTERM not succeeding after
a fixed timeout of 5 seconds.

Signed-off-by: Daniel Golle 
---
 jail/jail.c| 8 +++-
 service/instance.c | 9 ++---
 2 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/jail/jail.c b/jail/jail.c
index 6e9306d..bc2c039 100644
--- a/jail/jail.c
+++ b/jail/jail.c
@@ -1093,11 +1093,17 @@ static void jail_handle_signal(int signo)
if (hook_running) {
DEBUG("forwarding signal %d to the hook process\n", signo);
kill(hook_process.pid, signo);
+   /* set timeout to send SIGKILL hook process in case SIGTERM 
doesn't succeed */
+   if (signo == SIGTERM)
+   uloop_timeout_set(_process_timeout, 5000);
}
 
if (jail_running) {
DEBUG("forwarding signal %d to the jailed process\n", signo);
kill(jail_process.pid, signo);
+   /* set timeout to send SIGKILL jail process in case SIGTERM 
doesn't succeed */
+   if (signo == SIGTERM)
+   uloop_timeout_set(_process_timeout, 5000);
}
 }
 
@@ -1112,7 +1118,7 @@ static void signals_init(void)
 
if (!sigismember(, i))
continue;
-   if ((i == SIGCHLD) || (i == SIGPIPE) || (i == SIGSEGV))
+   if ((i == SIGCHLD) || (i == SIGPIPE) || (i == SIGSEGV) || (i == 
SIGSTOP) || (i == SIGKILL))
continue;
 
s.sa_handler = jail_handle_signal;
diff --git a/service/instance.c b/service/instance.c
index 748c1e5..07a6239 100644
--- a/service/instance.c
+++ b/service/instance.c
@@ -867,7 +867,8 @@ instance_stop(struct service_instance *in, bool halt)
in->halt = halt;
in->restart = in->respawn = 

Re: P2812HNUF3

[Daniel Golle]

Hi Ivar,

On Thu, Dec 09, 2021 at 10:14:22PM +0100, Ivar Orskaug wrote:
> Hi,
> P2812HNUF3 is currently broken in main because of the kernel 5.10
> increase in size. This patch increases the kernel flash partition to
> 3072k, aligning with P2812HNUF1. Would it be possible to apply it to
> main?

The patch looks good and all missing is a Signed-off-by: line.
As sysupgrade also won't be possible when having an older version
with 2MiB kernel limit running we should bump set DEVICE_COMPAT_VERSION
see below.

> Regards Ivar
> 
> diff --git 
> a/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_zyxel_p-2812hnu-f3.dts
> b/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_zyxel_p-2812hnu-f3.dts
> index 376cdaeb61..86520247d0 100644
> --- 
> a/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_zyxel_p-2812hnu-f3.dts
> +++ 
> b/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_zyxel_p-2812hnu-f3.dts
> @@ -55,11 +55,11 @@
> 
> partition@0 {
> label = "kernel";
> -   reg = <0x0 0x20>;
> +   reg = <0x0 0x30>;
> };
> -   partition@20 {
> +   partition@30 {
> label = "ubi";
> -   reg = <0x20 0x7e0>;
> +   reg = <0x30 0x7d0>;
> };
> };
>  };
> diff --git a/target/linux/lantiq/image/vr9.mk 
> b/target/linux/lantiq/image/vr9.mk
> index 909479587c..9e9818bdbf 100644
> --- a/target/linux/lantiq/image/vr9.mk
> +++ b/target/linux/lantiq/image/vr9.mk
> @@ -282,7 +282,7 @@ define Device/zyxel_p-2812hnu-f3
>DEVICE_VARIANT := F3
>BOARD_NAME := P2812HNUF3
>DEVICE_PACKAGES := kmod-rt2800-pci wpad-basic-wolfssl kmod-usb-dwc2
> -  KERNEL_SIZE := 2048k
> +  KERNEL_SIZE := 3072k
>SUPPORTED_DEVICES += P2812HNUF3
DEVICE_COMPAT_VERSION := 1.1
DEVICE_COMPAT_MESSAGE := Flash layout changed

>DEFAULT := n
>  endef
> 
> ___
> 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: dnsmasq issue

[Daniel Golle]

On Sun, Dec 05, 2021 at 01:26:18PM +0100, e9hack wrote:
> Hi,
> 
> the scripts are executed. I did a mistake with path names for the logging 
> files.
> 
> But the issue with executing dnsmasq twice is still open.

Do I understand correctly that you only observe this only in case of
procd-ujail being installed and hence dnsmasq being started with ujail?
Or does this phenomenon also happen if running without ujail?

> 
> Regards,
> Hartmut
> 
> Am 05.12.2021 um 12:13 schrieb e9hack+dnsmasq:
> > 
> > Hi,
> > 
> > I did configure a user script by adding:
> > 
> > option dhcpscript '/etc/dnsmasq-test.sh'
> > 
> > The script and the main-script are never executed. I did add a line to both 
> > scripts, which shall log to /var/run/dnsmaq/test-{1|2}.log
> > 
> > If I check afterwards if dnsmasq is running, I see two instances. One runs 
> > as user dnsmasq and the other as user root.
> > 
> > root@my-home:~# ps -ww | grep dnsmasq.conf.main
> > 12651 root  2652 S    {dnsmasq} /sbin/ujail -n dnsmasq -u -l -e 
> > USER_DHCPSCRIPT -r /bin/ubus -r /etc/TZ -r /etc/config/dhcp.dnsmasq -r 
> > /etc/dnsmasq-test.sh -r /etc/dnsmasq.conf -r /etc/ethers -r /etc/group -r 
> > /etc/hosts -r /etc/passwd -w /tmp/dhcp.leases -r /tmp/dnsmasq.d/main -r 
> > /tmp/hosts/dhcp.main -r /usr/bin/jshn -r /usr/lib/dnsmasq/dhcp-script.sh -r 
> > /usr/share/dnsmasq/dhcpbogushostname.conf -r 
> > /usr/share/dnsmasq/rfc6761.conf -r /usr/share/dnsmasq/trust-anchors.conf -r 
> > /usr/share/libubox/jshn.sh -r /var/etc/dnsmasq.conf.main -w 
> > /var/run/dnsmasq/ -- /usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf.main -k
> > 12652 dnsmasq   4828 S    /usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf.main -k
> > 12653 root  4564 S    /usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf.main -k
> > 15415 root  1392 S    grep dnsmasq.conf.main
> > 
> > In the ujail command line, must the part '-e USER_DHCPSCRIPT' contain the 
> > content of the variable?
> > 
> > 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: dnsmasq issue

[Daniel Golle]

On Sun, Dec 05, 2021 at 12:13:16PM +0100, e9hack+dnsmasq wrote:
> 
> Hi,
> 
> I did configure a user script by adding:
> 
> option dhcpscript '/etc/dnsmasq-test.sh'
> 
> The script and the main-script are never executed. I did add a line to both 
> scripts, which shall log to /var/run/dnsmaq/test-{1|2}.log
> 
> If I check afterwards if dnsmasq is running, I see two instances. One runs as 
> user dnsmasq and the other as user root.

Usually dnsmasq should open sockets and then change to user dnsmasq to
drop priviledges (it does so by itself, ujail is not involved there).

> 
> root@my-home:~# ps -ww | grep dnsmasq.conf.main
> 12651 root  2652 S{dnsmasq} /sbin/ujail -n dnsmasq -u -l -e 
> USER_DHCPSCRIPT -r /bin/ubus -r /etc/TZ -r /etc/config/dhcp.dnsmasq -r 
> /etc/dnsmasq-test.sh -r /etc/dnsmasq.conf -r /etc/ethers -r /etc/group -r 
> /etc/hosts -r /etc/passwd -w /tmp/dhcp.leases -r /tmp/dnsmasq.d/main -r 
> /tmp/hosts/dhcp.main -r /usr/bin/jshn -r /usr/lib/dnsmasq/dhcp-script.sh -r 
> /usr/share/dnsmasq/dhcpbogushostname.conf -r /usr/share/dnsmasq/rfc6761.conf 
> -r /usr/share/dnsmasq/trust-anchors.conf -r /usr/share/libubox/jshn.sh -r 
> /var/etc/dnsmasq.conf.main -w /var/run/dnsmasq/ -- /usr/sbin/dnsmasq -C 
> /var/etc/dnsmasq.conf.main -k
> 12652 dnsmasq   4828 S/usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf.main -k
> 12653 root  4564 S/usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf.main -k
> 15415 root  1392 Sgrep dnsmasq.conf.main
> 
> In the ujail command line, must the part '-e USER_DHCPSCRIPT' contain the 
> content of the variable?

No, the content of the variable is read and copied from the host
environment by ujail and only passing the name is the inteded way to
use this feature. You can verify it being set correctly by checking
/proc/$pid/environ.

Be aware that you can also use /etc/hotplug.d/{dhcp,neigh,tftp} to have
scripts executed on dnsmasq events (and other than using
option dhcpscript the script is then run as as user root)

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

Re: uqmi: add dms_get_operating_mode

[Daniel Golle]

Hi Henrik,

On Wed, Dec 01, 2021 at 01:46:01AM +0100, Henrik Ginstmark wrote:
> Hi
> 
> Is it possible to add dms_get_operating_mode command?

Doesn't seem much of a stretch, so why not ;)

> Then it would be possible to verify if the modem is in flight mode or not.
> 
> Or how can I contribute to uqmi?

Generally, follow this guideline
https://openwrt.org/submitting-patches

When sending a patch for a sub-project like uqmi, please make sure to
prefix the message subject to clearly indicate the patch has to be
applied on uqmi.git and not on openwrt.git (just like you did)

What is missing here is mostly a patch description, and your
Signed-off-by: ... 


Cheers


Daniel

> 
> 
> BR
> Henrik Ginstmark
> 
> ---
> commands-dms.c
> 
> @@ -375,6 +375,38 @@ qmi_set_dms_reset_request(msg);
> return QMI_CMD_REQUEST;
> }
> 
> +static void
> +cmd_dms_get_operating_mode_cb(struct qmi_dev *qmi, struct qmi_request
> *req, struct qmi_msg *msg)
> +{
> + struct qmi_dms_get_operating_mode_response res;
> +
> + const char *modes[] = {
> + [QMI_DMS_OPERATING_MODE_ONLINE] = "online",
> + [QMI_DMS_OPERATING_MODE_LOW_POWER] = "low_power",
> + [QMI_DMS_OPERATING_MODE_FACTORY_TEST] = "factory_test",
> + [QMI_DMS_OPERATING_MODE_OFFLINE] = "offline",
> + [QMI_DMS_OPERATING_MODE_RESET] = "reset",
> + [QMI_DMS_OPERATING_MODE_SHUTTING_DOWN] = "shutting_down",
> + [QMI_DMS_OPERATING_MODE_PERSISTENT_LOW_POWER] = "persistent_low_power",
> + [QMI_DMS_OPERATING_MODE_MODE_ONLY_LOW_POWER] = "mode_only_low_power",
> + };
> + int s = 0;
> +
> + qmi_parse_dms_get_operating_mode_response(msg, );
> + if (res.set.mode &&
> +res.data.mode < ARRAY_SIZE(modes))
> + s = res.data.mode;
> +
> + blobmsg_add_string(, NULL, modes[s]);
> +}
> +
> +static enum qmi_cmd_result
> +cmd_dms_get_operating_mode_prepare(struct qmi_dev *qmi, struct
> qmi_request *req, struct qmi_msg *msg, char *arg)
> +{
> + qmi_set_dms_get_operating_mode_request(msg);
> + return QMI_CMD_REQUEST;
> +}
> +
> #define cmd_dms_set_operating_mode_cb no_cb
> static enum qmi_cmd_result
> cmd_dms_set_operating_mode_prepare(struct qmi_dev *qmi, struct
> qmi_request *req, struct qmi_msg *msg, char *arg)
> 
> 
> ---
> commands-dms.h
> 
> @@ -37,6 +37,7 @@
> __uqmi_command(dms_get_imsi, get-imsi, no, QMI_SERVICE_DMS), \
> __uqmi_command(dms_get_imei, get-imei, no, QMI_SERVICE_DMS), \
> __uqmi_command(dms_get_msisdn, get-msisdn, no, QMI_SERVICE_DMS), \
> +   __uqmi_command(dms_get_operating_mode,
> get-device-operating-mode, no, QMI_SERVICE_DMS), \
> __uqmi_command(dms_set_operating_mode,
> set-device-operating-mode, required, QMI_SERVICE_DMS), \
> __uqmi_command(dms_reset, reset-dms, no, QMI_SERVICE_DMS), \
> __uqmi_command(dms_set_fcc_authentication, fcc-auth, no,
> QMI_SERVICE_DMS) \
> @@ -67,6 +58,7 @@
> "  --get-imei:   Get International
> Mobile Equipment ID\n" \
> "  --get-msisdn: Get the MSISDN
> (telephone number)\n" \
> "  --reset-dms:  Reset the DMS service\n" 
> \
> +   "  --get-device-operating-mode   Get the device
> operating mode\n" \
> "  --set-device-operating-modeSet the device
> operating mode\n" \
> "(modes: online,
> low_power, factory_test, offline\n" \
> "
> reset,shutting_down, persistent_low_power,\n" \

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