Re: gpio-mt7621 offset fix for 5.10 kernel series
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.--- Begin Message --- On Wed, Oct 19, 2022 at 1:10 AM Rosen Penev wrote: > > On Tue, Oct 18, 2022 at 3:50 PM Peter Naulls wrote: > > > > On 10/18/22 17:10, Lukas Zeller wrote: > > . > > > > > > Just not any more - the mt7621 had this too. I currently patch it back > > > into > > > 22.03's gpio-mt7621.c for my builds and set base in the DTS, see [3] > > > > > > I can follow the rationale to get rid of legacy GPIOs, but in the context > > > of experimenting platforms, where GPIOs are a thing to work with in > > > user space, there's just no real replacement yet (see details in [1],[2]). > > > > Yes, I see. > > > > I have a mix of C and scripted GPIO access in my setup, and certainly I can > > move to libgpiod for that - or just just access them as files with > > named GPIOs as setup per the DTS. > Let's CC Sergio, who upstreamed this driver. For kernel developers, setting base in GPIOs is a no go. You have to let the kernel to assign its numbers so you can handle different GPIO layouts with multiple chips. This is the reason we have 'gpio-line-names' property so you can set up names for your pins and use it together with actual user space tools libgpiod and gpiod. Any other gpio user space library is considered deprecated in these days. Best regards, Sergio Paracuellos > > > > I do see the GPIO shell examples in the OpenWrt wiki, but the code needs > > more work to deal with multiple banks, and it just makes figuring out > > the GPIO number to use more clunky without any good cause. > > > > Now, the numbered GPIOs really are just for debug in my system, the > > actual code will use the named ones, but still. > > > > Is the long-term intent for shell scripting to instead use the libgpiod > > tools? > > > > https://openwrt.org/docs/techref/hardware/port.gpio > > > > ___ > > openwrt-devel mailing list > > openwrt-devel@lists.openwrt.org > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: gpio-mt7621 offset fix for 5.10 kernel series
On Tue, Oct 18, 2022 at 3:50 PM Peter Naulls wrote: > > On 10/18/22 17:10, Lukas Zeller wrote: > . > > > > Just not any more - the mt7621 had this too. I currently patch it back into > > 22.03's gpio-mt7621.c for my builds and set base in the DTS, see [3] > > > > I can follow the rationale to get rid of legacy GPIOs, but in the context > > of experimenting platforms, where GPIOs are a thing to work with in > > user space, there's just no real replacement yet (see details in [1],[2]). > > Yes, I see. > > I have a mix of C and scripted GPIO access in my setup, and certainly I can > move to libgpiod for that - or just just access them as files with > named GPIOs as setup per the DTS. Let's CC Sergio, who upstreamed this driver. > > I do see the GPIO shell examples in the OpenWrt wiki, but the code needs > more work to deal with multiple banks, and it just makes figuring out > the GPIO number to use more clunky without any good cause. > > Now, the numbered GPIOs really are just for debug in my system, the > actual code will use the named ones, but still. > > Is the long-term intent for shell scripting to instead use the libgpiod > tools? > > https://openwrt.org/docs/techref/hardware/port.gpio > > ___ > 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: gpio-mt7621 offset fix for 5.10 kernel series
On 10/18/22 17:10, Lukas Zeller wrote: . Just not any more - the mt7621 had this too. I currently patch it back into 22.03's gpio-mt7621.c for my builds and set base in the DTS, see [3] I can follow the rationale to get rid of legacy GPIOs, but in the context of experimenting platforms, where GPIOs are a thing to work with in user space, there's just no real replacement yet (see details in [1],[2]). Yes, I see. I have a mix of C and scripted GPIO access in my setup, and certainly I can move to libgpiod for that - or just just access them as files with named GPIOs as setup per the DTS. I do see the GPIO shell examples in the OpenWrt wiki, but the code needs more work to deal with multiple banks, and it just makes figuring out the GPIO number to use more clunky without any good cause. Now, the numbered GPIOs really are just for debug in my system, the actual code will use the named ones, but still. Is the long-term intent for shell scripting to instead use the libgpiod tools? https://openwrt.org/docs/techref/hardware/port.gpio ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: gpio-mt7621 offset fix for 5.10 kernel series
Hi Peter and Martin, > On 18 Oct 2022, at 22:02, Peter Naulls wrote: > > On 10/18/22 15:55, Martin Blumenstingl wrote: >> [...] my understanding is that the recommended way for >> accessing GPIOs from userspace (in case that's what you need) should >> be done through libgpiod. > > Thanks for pointing me at this. Of course, I don't keep tabs on all the > kernel development. I did investigate this in June on this list [1] and in the openwrt forum [2] and tried to ask some questions about the right way to handle this, but apparently it did not echo for some reason back then. > I will say the following though: > > It looks a bit odd - the 416 is arbitrary at best, but I'm sure it comes > from some calculation. The MT76xx GPIO has 3 banks with 32 GPIOs each, and the driver initializes them in the order 0,1,2. The automatic lecagcy GPIO number assignment works by allocating numbers down from 512 in chunks of 32. So bank 0 gets 512-32 = 480 as base, bank1 gets 448 and bank2 gets 416. But GPIOs *within* the chunks are counted upwards, so you'll get a very unintuitive zigzag mapping when comparing with the pin names in the datasheet. > All/most of the other ramips use the ramips GPIO driver instead, which > does specify the base, although that's in the the DTS; there's no > facility for that in the mt7621 setup at present. Just not any more - the mt7621 had this too. I currently patch it back into 22.03's gpio-mt7621.c for my builds and set base in the DTS, see [3] I can follow the rationale to get rid of legacy GPIOs, but in the context of experimenting platforms, where GPIOs are a thing to work with in user space, there's just no real replacement yet (see details in [1],[2]). So IMHO, at least the "base" of property should stay for a while. Best Regards Lukas [1] http://lists.openwrt.org/pipermail/openwrt-devel/2022-June/038912.html [2] https://forum.openwrt.org/t/state-of-userland-access-to-gpio-based-hardware/130505 [3] https://plan44.ch/downloads/v22.03-metapatch-readd-of-base-to-gpio-mt7621.patch signature.asc Description: Message signed with OpenPGP ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 05/16] realtek: add switch port LED driver
On 10/16/22 16:58, Sander Vanheule wrote:
Hi Alex,
Hi
[snip]
+
+ if (current_trigger != rtl_trigger && !bitmap_empty(group->ports,
group->size)) {
+ dev_warn(ctrl->dev, "cannot map (%d,%d) to group %d: 0x%02x
!= 0x%02x\n",
+ led->port, led->index, group->index,
current_trigger, rtl_trigger);
+ return ERR_PTR(-ENOSPC);
+ }
It seems that the rtl_hw_trigger cannot be changed once any of the LEDs
are switched to "realtek-switchport".
# echo realtek-switchport | tee /sys/class/leds/green:lan*_1000/trigger
# echo 13 | tee /sys/class/leds/green:lan*_1000/rtl_hw_trigger
tee: /sys/class/leds/green:lan1_1000/rtl_hw_trigger: I/O error
[ 852.47] realtek-switch-port-led realtek-switchcore-port-leds.0:
cannot map (15,1) to group 0: 0x1f != 0x0a
[ 852.48] realtek-switch-port-led realtek-switchcore-port-leds.0:
cannot map (14,1) to group 0: 0x1f != 0x0a
...
However, doing things in opposite order works (after reboot):
-
# echo 13 | tee /sys/class/leds/green:lan*_1000/rtl_hw_trigger
# echo realtek-switchport | tee /sys/class/leds/green:lan*_1000/trigger
# grep . /sys/kernel/debug/rtl838x/led/led*
/sys/kernel/debug/rtl838x/led/led1_sw_p_en_ctrl:0x0fff00ff
/sys/kernel/debug/rtl838x/led/led_mode_ctrl:0x00838147
This behaviour is intentional, but I am open to suggestions on improving it, as
I agree it isn't very nice.
When using the "netdev" trigger, the sysfs configuration files are only exposed
when the trigger is selected. This makes sense if each LED can be configured
independently of the others.
The hardware trigger on RTL838x requires an LED to be part of a group (or "set"
in the SDK). As such, an LED itself cannot be configured to trigger on a certain
hardware state, but the group it belongs to must be configured. That is why I
opted to let the user set a HW trigger condition before activating the HW
trigger, since activation means assigning the LED to one of the limited number
of groups.
One alternative would be to only expose the rtl_hw_trigger file once the
"realtek-switchport" trigger is selected, but that would mean I have to either
* ignore configurations that cannot currently be mapped to any active group,
* change the behaviour of other LEDs belonging to an already existing group,
if
the HW trigger is overwritten.
The latter may work on RTL838x, where there is only one HW trigger setting for
any given LED. On RTL839x this is not possible though, because there is no way
to decide which of the 4 available groups should be used if there aren't any
available.
This is modeled in sysfs such that each LED appears to have its own
"rtl_hw_trigger". Instead, why not model one "rtl_hw_trigger" per LED
group? For example, symlink "rtl_hw_trigger" to a sysfs entry in the parent.
You can make the symlink appear or disappear when "realtek-switchport"
trigger is selected, or just leave it always on. When you change the
setting for one LED, it changes it for all the LEDs in the group. I
think it's more intuitive because it aligns more to how the LED
controller actually works.
Thus, "realtek-switchport" controls led{0,1,2}_sw_p_en_ctrl, and
"rtl_hw_trigger" only controls led_mode_ctrl. No need to intermingle
them with complicated logic.
But then there's yet another confusing point:
-
# echo 13 > /sys/class/leds/green:lan1_1000/rtl_hw_trigger
# cat /sys/class/leds/green:lan1_1000/rtl_hw_trigger
13
# echo realtek-switchport | tee /sys/class/leds/green:lan*_1000/trigger
# grep . /sys/class/leds/green:lan*_1000/trigger
/sys/class/leds/green:lan1_1000/trigger:none timer heartbeat default-on
netdev [realtek-switchport]
/sys/class/leds/green:lan2_1000/trigger:[none] timer heartbeat
default-on netdev realtek-switchport
...
The other ports don't get switched to realtek-switchport, and there is
no noticeable indication of an error.
Did you run this after rebooting? I'm not able to reproduce this on my
(mainline) image. When only one port has trigger flags "13", this results in log
messages in my quick test.
Yes, that's right after reboot (rtl838x-based TL-SG2008P). I see the
dmesg messages now. Still, I would expect the 'tee' or 'echo' command to
show an error. It's not obvious that the answer lies in dmesg.
+static ssize_t rtl_hw_trigger_show(struct device *dev, struct
device_attribute *attr, char *buf)
+{
+ struct led_classdev *cdev = dev_get_drvdata(dev);
+ struct switch_port_led *pled = to_switch_port_led(cdev);
+
+ return sprintf(buf, "%x\n", pled->trigger_flags);
+}
# grep . /sys/class/leds/green:lan*_1000/*rigger
rtl_hw_trigger:13
trigger:none timer heartbeat default-on netdev [realtek-switchport]
The "trigger flags" number is meaningless for sysfs. I suggest this
should show a text field with a selected choice, similar to how
"trigger" behaves:
rtl_hw_trigger:none
Re: gpio-mt7621 offset fix for 5.10 kernel series
On 10/18/22 15:55, Martin Blumenstingl wrote: Hello Peter, On Tue, Oct 18, 2022 at 9:34 PM Peter Naulls wrote: Looks like there was some code loss when the driver came from an earlier kernel series. Without this, my MT7621 board starts its GPIO offsets at 416 (why that number, I don't know): You should also explain the problem with this behavior (if there's any). Upstream kernel doc [0] mentions: * @base: identifies the first GPIO number handled by this chip; * or, if negative during registration, requests dynamic ID allocation. * DEPRECATION: providing anything non-negative and nailing the base * offset of GPIO chips is deprecated. Please pass -1 as base to * let gpiolib select the chip base in all possible cases. We want to * get rid of the static GPIO number space in the long run. I never used it but my understanding is that the recommended way for accessing GPIOs from userspace (in case that's what you need) should be done through libgpiod. Thanks for pointing me at this. Of course, I don't keep tabs on all the kernel development. I will say the following though: It looks a bit odd - the 416 is arbitrary at best, but I'm sure it comes from some calculation. All/most of the other ramips use the ramips GPIO driver instead, which does specify the base, although that's in the the DTS; there's no facility for that in the mt7621 setup at present. I ended up using named GPIO mappings set up in the DTS, which appears to be OK. I was chasing some additional GPIO issues vs what I had working on an earlier kernel series - it didn't immediately help, but it was an obvious inconsistency. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: gpio-mt7621 offset fix for 5.10 kernel series
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.--- Begin Message --- Hello Peter, On Tue, Oct 18, 2022 at 9:34 PM Peter Naulls wrote: > > > Looks like there was some code loss when the driver came from an earlier > kernel > series. Without this, my MT7621 board starts its GPIO offsets at 416 (why that > number, I don't know): You should also explain the problem with this behavior (if there's any). Upstream kernel doc [0] mentions: * @base: identifies the first GPIO number handled by this chip; * or, if negative during registration, requests dynamic ID allocation. * DEPRECATION: providing anything non-negative and nailing the base * offset of GPIO chips is deprecated. Please pass -1 as base to * let gpiolib select the chip base in all possible cases. We want to * get rid of the static GPIO number space in the long run. I never used it but my understanding is that the recommended way for accessing GPIOs from userspace (in case that's what you need) should be done through libgpiod. Best regards, Martin [0] https://elixir.bootlin.com/linux/v4.14.295/source/include/linux/gpio/driver.h#L48 --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
gpio-mt7621 offset fix for 5.10 kernel series
Looks like there was some code loss when the driver came from an earlier kernel series. Without this, my MT7621 board starts its GPIO offsets at 416 (why that number, I don't know): --- a/drivers/gpio/gpio-mt7621.c2022-10-18 15:03:42.596454871 -0400 +++ b/drivers/gpio/gpio-mt7621.c2022-10-18 13:51:23.628305673 -0400 @@ -234,6 +234,7 @@ return ret; } +rg->chip.base = rg->bank * MTK_BANK_WIDTH; rg->chip.of_gpio_n_cells = 2; rg->chip.of_xlate = mediatek_gpio_xlate; rg->chip.label = devm_kasprintf(dev, GFP_KERNEL, "%s-bank%d", I'm using 5.10 in the current OpenWrt 22.03. Before # ls -l /sys/class/gpio/gpiochip4* lrwxrwxrwx1 root root 0 Jan 1 1970 /sys/class/gpio/gpiochip416 -> ../../devices/platform/1e00.palmbus/1e000600.gpio/gpio6 lrwxrwxrwx1 root root 0 Jan 1 1970 /sys/class/gpio/gpiochip448 -> ../../devices/platform/1e00.palmbus/1e000600.gpio/gpio8 lrwxrwxrwx1 root root 0 Jan 1 1970 /sys/class/gpio/gpiochip480 -> ../../devices/platform/1e00.palmbus/1e000600.gpio/gpio0 After: # ls -l /sys/class/gpio/ --w---1 root root 4096 Jan 1 1970 export lrwxrwxrwx1 root root 0 Jan 1 1970 gpiochip0 -> ../../devices/platform/1e00.palmbus/1e000600.gpio/gpio/gpiochip0 lrwxrwxrwx1 root root 0 Jan 1 1970 gpiochip32 -> ../../devices/platform/1e00.palmbus/1e000600.gpio/gpio/gpiochip32 lrwxrwxrwx1 root root 0 Jan 1 1970 gpiochip64 -> ../../devices/platform/1e00.palmbus/1e000600.gpio/gpio/gpiochip64 --w---1 root root 4096 Jan 1 1970 unexport Which is consistent with what I had in 4.14 series. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] base-files: Don't enable ULA IPv6 addresses by default in new config
út 18. 10. 2022 v 16:43 odesílatel Oldřich Jedlička
napsal:
>
> Hi,
>
> pá 9. 9. 2022 v 11:21 odesílatel Torsten Duwe napsal:
> >
> > On Thu, 8 Sep 2022 19:51:06 +0200
> > Thibaut wrote:
> >
> > > The issue was random. The client had a GUA assigned, below is the ipv6
> > > routing table at the time of the issue:
> > >
> > > $ ip -6 route
> > > 2a0e:e701:11c2::/64 dev bond0 proto kernel metric 256 expires 7082sec
> > > pref medium
> > > fdc9:6d06:832a::/64 dev bond0 proto kernel metric 256 pref medium
> >
> > So AFAICS here lies the problem. Same metric, same preference.
> > The addresses below are usually tagged link local somewhere, but
> > I assume the ULA is not.
>
> When pinging a public IPv6 address the default route should be used.
> This should have nothing to do with the two routes above
> (2a03:b0c0:3:d0::160e:e001 IPv6 address has no match here).
>
> > > fe80::/64 dev bond0 proto kernel metric 256 pref medium
> > > fe80::/64 dev bond0.10 proto kernel metric 256 pref medium
> > > default via fe80::184f:a7ff:fe21:d230 dev bond0 proto ra metric 1024
> > > expires 1793sec mtu 1492 hoplimit 64 pref medium
>
> This default route over bond0 should be actually used during pinging
> of git.openwrt.org (2a03:b0c0:3:d0::160e:e001).
>
> > > For that matter, this setup only uses SLAAC (no DHCPv6 on LAN).
>
> When you are pinging global addresses, also global IPv6 address should
> be used independently of the presence of ULA. For your public IPv6
> prefix 2a0e:e701:11c2::/64 any ping outside should use the IPv6
> address of your computer having this prefix. I would be interested in
> which address is actually used during pinging. Please share your `ip
> -6 address` too. And if possible, also please share `tcpdump -i bond0
> -nv icmp6` while the computer is pinging. Important - all of this
> assumes that you are delegating your public IPv6 prefix from the
> router to all computers (I used to have a static IPv6 configuration on
> my OpenWrt router with option `ip6prefix` for that purpose).
>
> There is also a possibility that you mentioned - have NAT66 (ULA to
> public IPv6 prefix translation) on the router. This means that you
> could remove the public prefix delegation and just keep the ULA
> configured. All computers would use the ULA prefix when accessing
> public addresses. In this case you would need to change the firewall
> and add the following SNAT rule to the NFT firewall for the srcnat_wan
> chain:
>
> ip6 saddr fdc9:6d06:832a::/61 snat prefix to 2a0e:e701:11c2::/64
Sorry, typo here, prefix length should be 64 in both cases:
ip6 saddr fdc9:6d06:832a::/64 snat prefix to 2a0e:e701:11c2::/64
Oldrich.
> > >
> > > Disabling ULA « fixes » this issue.
>
> There is probably some different issue in your configuration, which
> causes this behaviour.
>
> Oldrich.
>
> > Sure. Above, it looks like a game of chance which address is used.
> >
> > From my understanding, router.lan would need to be told to do IPv6 NAT
> > if clients are to reach outside with their ULAs, right?
> >
> > If I get a vote, I'd enable ULA generation only iff an IPv6 NAT was also
> > configured, and, last but not least, I wouldn't randomise it. I'd go for
> > e.g. fd00:4f57:5254 ("OWRT"), like all AVR use 192.168.178.0/24 on v4.
> >
> > Torsten
> >
> >
> > ___
> > 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] base-files: Don't enable ULA IPv6 addresses by default in new config
Hi,
pá 9. 9. 2022 v 11:21 odesílatel Torsten Duwe napsal:
>
> On Thu, 8 Sep 2022 19:51:06 +0200
> Thibaut wrote:
>
> > The issue was random. The client had a GUA assigned, below is the ipv6
> > routing table at the time of the issue:
> >
> > $ ip -6 route
> > 2a0e:e701:11c2::/64 dev bond0 proto kernel metric 256 expires 7082sec pref
> > medium
> > fdc9:6d06:832a::/64 dev bond0 proto kernel metric 256 pref medium
>
> So AFAICS here lies the problem. Same metric, same preference.
> The addresses below are usually tagged link local somewhere, but
> I assume the ULA is not.
When pinging a public IPv6 address the default route should be used.
This should have nothing to do with the two routes above
(2a03:b0c0:3:d0::160e:e001 IPv6 address has no match here).
> > fe80::/64 dev bond0 proto kernel metric 256 pref medium
> > fe80::/64 dev bond0.10 proto kernel metric 256 pref medium
> > default via fe80::184f:a7ff:fe21:d230 dev bond0 proto ra metric 1024
> > expires 1793sec mtu 1492 hoplimit 64 pref medium
This default route over bond0 should be actually used during pinging
of git.openwrt.org (2a03:b0c0:3:d0::160e:e001).
> > For that matter, this setup only uses SLAAC (no DHCPv6 on LAN).
When you are pinging global addresses, also global IPv6 address should
be used independently of the presence of ULA. For your public IPv6
prefix 2a0e:e701:11c2::/64 any ping outside should use the IPv6
address of your computer having this prefix. I would be interested in
which address is actually used during pinging. Please share your `ip
-6 address` too. And if possible, also please share `tcpdump -i bond0
-nv icmp6` while the computer is pinging. Important - all of this
assumes that you are delegating your public IPv6 prefix from the
router to all computers (I used to have a static IPv6 configuration on
my OpenWrt router with option `ip6prefix` for that purpose).
There is also a possibility that you mentioned - have NAT66 (ULA to
public IPv6 prefix translation) on the router. This means that you
could remove the public prefix delegation and just keep the ULA
configured. All computers would use the ULA prefix when accessing
public addresses. In this case you would need to change the firewall
and add the following SNAT rule to the NFT firewall for the srcnat_wan
chain:
ip6 saddr fdc9:6d06:832a::/61 snat prefix to 2a0e:e701:11c2::/64
> >
> > Disabling ULA « fixes » this issue.
There is probably some different issue in your configuration, which
causes this behaviour.
Oldrich.
> Sure. Above, it looks like a game of chance which address is used.
>
> From my understanding, router.lan would need to be told to do IPv6 NAT
> if clients are to reach outside with their ULAs, right?
>
> If I get a vote, I'd enable ULA generation only iff an IPv6 NAT was also
> configured, and, last but not least, I wouldn't randomise it. I'd go for
> e.g. fd00:4f57:5254 ("OWRT"), like all AVR use 192.168.178.0/24 on v4.
>
> Torsten
>
>
> ___
> 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
SBOM Tool for OpenWRT to feed Dependency Track
Hi, We decided to publish our internal fork of the Timesys SBOM Tool we found on github. You find our version at: https://github.com/ads-tec/sbom-openwrt It takes a complete OpenWRT build tree as input and will generate a SBOM in CycloneDX JSON Format for the currently configured image. This SBOM can be fed into your personal dependency track instance. See https://dependencytrack.org/ if you don't know what this is. In my opinion Dependency Track is much more usable compared to uscan. However Dependency Tack currently heavily relies on valid CPE ID. Thus you will need to fix the CPE IDs in the OpenWRT package Makefiles - some are missing. I think it would be a great security benefit for the OpenWRT ecosystem if we get a best possible coverage of CPE IDs in the available Makefiles. I'll try to push our CPE ID additions upstream. Best regards, Steffen Pfendtner ads-tec Engineering GmbH Sitz: 72622 N?rtingen Registergericht Stuttgart HRB 762860 Gesch?ftsf?hrer: Dipl.-Ing. Ali Natour, Dipl.-Ing. Thomas-M?gerle ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
uboot-envtools: Don't preserve configs after sysupgrade
For devices with a NAND and a NOR chip, it was noticed that the order of
initialization can be different between various kernel versions (4.4 vs.
5.4). As result, the mtd index changes for the u-boot-env partition - but
the uboot-envtool still kept the old partition index.
And since some devices write (for example during sysupgrade) to the
u-boot-env, a unrelated partition would be overwritten. This would often
brick the device.
For example, a device with dualboot_datachk upgrade procedure with kernel A
(first intializes NOR and then NAND) which is upgrade to kernel B (first
initializes NAND and then NOR) would end up in a bricket state because the
device:
1. kernel A is (factory) installed on device
2. firstboot scripts initialize /etc/fw_env.config to point to mtd6
3. kernel B is installed on device via sysupgrade (no extra options)
* during upgrade some information is written to mtd6 (u-boot-env)
4. firstboot script will not do anything when kernel B booted
-> /etc/fw_env.config still points to mtd6 (now the "0:RPM" partition)
5. sysupgrade is started again
* some information should be written to u-boot-env but the upgrade
script will now overwrite some important information of "0:RPM" (mtd6)
6. boot fails because the secondary bootload is unable to load the iamge
from 0:RPM. u-boot will then never be started because the SBL caused
a panic before it was event tried to load it.
This scenario cannot happen when the /etc/fw_env.config is not preserved
and instead autogenerated after each firmware installation.
There might still be a good reason to restore the values from uci in case
there is no code to auto-generate the settings.
Fixes: 7f00e5ffc671 ("uboot-envtools: update to 2012.04.01")
Signed-off-by: Sven Eckelmann
---
The safest method to reproduce the problem without killing your system is
to use a board which usually doesn't use fw_setenv but has an accessible
u-boot-env.
1. flash the device with your test firmware
2. check that fw_printenv works
3. write bogus values in your u-boot-env configuration:
echo '/dev/mtd99 0x0 0x0001 0x0001 1' > /etc/fw_env.config
uci set ubootenv.@ubootenv[0].dev='/dev/mtd6'
uci commit ubootenv
4. sysupgrade the device
5. check if fw_printenv works again
diff --git a/package/boot/uboot-envtools/Makefile
b/package/boot/uboot-envtools/Makefile
index
6840b9c586be1b6f41b72b18138143bd695dbfe6..ca76f528f8f93be46268f8132f50f93bc33025ea
100644
--- a/package/boot/uboot-envtools/Makefile
+++ b/package/boot/uboot-envtools/Makefile
@@ -58,12 +58,6 @@ MAKE_FLAGS += \
no-dot-config-targets=envtools \
envtools
-define Package/uboot-envtools/conffiles
-/etc/config/ubootenv
-/etc/fw_env.config
-/etc/fw_sys.config
-endef
-
define Package/uboot-envtools/install
$(INSTALL_DIR) $(1)/usr/sbin
$(INSTALL_BIN) $(PKG_BUILD_DIR)/tools/env/fw_printenv $(1)/usr/sbin
diff --git a/package/boot/uboot-envtools/files/apm821xx
b/package/boot/uboot-envtools/files/apm821xx
index
e73aaab7a0d73a4856d24ae20a39458797c8beb1..06241449717769b1e531763b597b9b980d14150d
100644
--- a/package/boot/uboot-envtools/files/apm821xx
+++ b/package/boot/uboot-envtools/files/apm821xx
@@ -1,4 +1,4 @@
-[ -e /etc/config/ubootenv ] && exit 0
+rm -f /etc/fw_env.config
touch /etc/config/ubootenv
@@ -9,17 +9,19 @@ board=$(board_name)
case "$board" in
meraki,mr24)
+ ubootenv_clear_uci_config
ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x4000" "0x4000" "4"
ubootenv_add_uci_config "/dev/mtd2" "0x0" "0x4000" "0x4000" "4"
;;
meraki,mx60)
- ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x2" "0x2" "4"
+ ubootenv_set_uci_config "/dev/mtd1" "0x0" "0x2" "0x2" "4"
;;
netgear,wndap620|\
netgear,wndap660)
- ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x4000" "0x4000" "4"
+ ubootenv_set_uci_config "/dev/mtd1" "0x0" "0x4000" "0x4000" "4"
;;
wd,mybooklive)
+ ubootenv_clear_uci_config
ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x1000" "0x1000" "1"
ubootenv_add_uci_config "/dev/mtd1" "0x1000" "0x1000" "0x1000" "1"
;;
diff --git a/package/boot/uboot-envtools/files/ath79
b/package/boot/uboot-envtools/files/ath79
index
d9e504bf8949a5ef93e1641d01334fc61523bd68..194176527c84ed5c0418f3dc5940645a75f03c55
100644
--- a/package/boot/uboot-envtools/files/ath79
+++ b/package/boot/uboot-envtools/files/ath79
@@ -2,7 +2,7 @@
# Copyright (C) 2011-2014 OpenWrt.org
#
-[ -e /etc/config/ubootenv ] && exit 0
+rm -f /etc/fw_env.config
touch /etc/config/ubootenv
@@ -77,17 +77,17 @@ yuncore,xd3200|\
yuncore,xd4200|\
ziking,cpe46b|\
zyxel,nbg6616)
- ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x1" "0x1"
+ ubootenv_set_uci_config "/dev/mtd1" "0x0" "0x1" "0x1"
;;
buffalo,wzr-hp-ag300h)
- ubootenv_add_uci_config "/dev/mtd3" "0x0" "0x1" "0x1"
+ ubootenv_set_uci_config "/dev/mtd3" "0x0"
[openwrt] Patch notification: 1 patch updated
Hello, The following patch (submitted by you) has been updated in Patchwork: * openwrt: jail: ignore missing .dynamic sect - http://patchwork.ozlabs.org/project/openwrt/patch/mailman.24701.1665327047.4154159.openwrt-de...@lists.openwrt.org/ - for: OpenWrt development was: New now: Superseded This email is a notification only - you do not need to respond. Happy patchworking. -- This is an automated mail sent by the Patchwork system at patchwork.ozlabs.org. To stop receiving these notifications, edit your mail settings at: http://patchwork.ozlabs.org/mail/ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] bcm53xx: enable Broadcom 4366b1 firmware for Asus RT-AC88U
On some of the hardware revisions of Asus RT-AC88U, brcmfmac detects the 4366b1 wireless chip and tries to load the firmware file which doesn't exist because it's not included in the image. Therefore, include firmware for 4366b1 along with 4366c0. This way, all hardware revisions of the router will be supported by having brcmfmac use the firmware file for the wireless chip it detects. Signed-off-by: Arınç ÜNAL --- Hauke, please cherry-pick this to 22.03. Arınç --- target/linux/bcm53xx/image/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/bcm53xx/image/Makefile b/target/linux/bcm53xx/image/Makefile index d101ff95a7..ed0b755364 100644 --- a/target/linux/bcm53xx/image/Makefile +++ b/target/linux/bcm53xx/image/Makefile @@ -170,7 +170,7 @@ TARGET_DEVICES += asus_rt-ac87u define Device/asus_rt-ac88u $(call Device/asus) DEVICE_MODEL := RT-AC88U - DEVICE_PACKAGES := $(BRCMFMAC_4366C0) $(USB3_PACKAGES) + DEVICE_PACKAGES := $(BRCMFMAC_4366B1) $(BRCMFMAC_4366C0) $(USB3_PACKAGES) ASUS_PRODUCTID := RT-AC88U endef TARGET_DEVICES += asus_rt-ac88u -- 2.34.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
