Re: [OpenWrt-Devel] [PATCH 19.07] ramips: mt7621: ubnt-erx: allow sysupgrade from master
m...@adrianschmutzler.de [2020-01-21 00:26:41]: Hi, > Note that I changed somewhat between 100 and 150 devices when reorganizing > board names in ramips between master and 19.07. and I thank you for that, it names makes more sense now. > So, unless you have a specific reason to deal with this particular device, It's one of my testing devices, and I sometimes check master -> 19.07 -> master sysupgrade, to probe different codepaths and to check, that the upgrade to the next release still works. Thanks for review. -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Lantiq xrx200: PTM issues
Ok, I think I've got it: The "sk_wmem_alloc" is decremented in sock_wfree() which is called by kfree_skb. But in ptm_hard_start_xmit() of the ifxmips_ptm_vdsl.c, the skb only gets freed immediately, if the skb_headroom is to small or the skb is cloned. In this case the skb is copied to a new one and the original skb gets freed. Otherwise the skb only gets freed after a complete round through the TX descriptor table. My suggestion would be, to always copy the skb. - Martin On 2020-01-20 13:45, Martin Schiller wrote: Update: I've found out now that the ENOBUFS is set by __ip_append_data, because sk_wmem_alloc "overflows". Martin On 2020-01-20 07:09, Martin Schiller wrote: Hi! I have discovered the following problem: If you have established a PPPoE session via VDSL / PTM connection incl. VLAN tagging and send data with a relatively small send buffer (SO_SNDBUF), then an ENOBUFS always comes back. We first noticed this with stagnating data transfers over an OpenVPN connection. Also with iputils-ping, since by default the send buffer is relatively small. You can also force this with busybox ping by using echo "5000"> / proc / sys / net / core / wmem_default minimizes the system default value. Then you send pings with a packet size of e.g. 4000 bytes and the second package is already in the pants: root @ OpenWrt: ~ # ping -s4000 10.200.1.142 PING 10.200.1.142 (10.200.1.142): 4000 data bytes 4008 bytes from 10.200.1.142: seq = 0 ttl = 63 time = 20.519 ms ping: sendto: No buffer space available root @ OpenWrt: ~ # So it should be easily reproducible for everyone. Traffic that is only routed through the router is not affected. The manpage of sendto says: --- ENOBUFS The output queue for a network interface was full. This generally indicates that the interface has stopped sending, but may be caused by transient congestion. (Normally, this does not occur in Linux. Packets are just silently dropped when a device queue overflows.) --- But all former packets have already been transmitted. This issue seems to be in there since lede-17.01. I can't reproduce it with owrt-15.05. Does anyone have any idea how to solve the problem? Martin ___ 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: [OpenWrt-Devel] Migration in ath79 for swapped ethernet
Hi Adrian, David, Chuanhong,
On 07.09.2019 12:15, m...@adrianschmutzler.de wrote:
Hi,
> However, this will obviously swap eth0/eth1 on EVERY upgrade, not just
when coming from ar71xx.
> So, does anyone have an idea how to limit this to run only when updated
from ar71xx?
I was thinking about the same. As we have no information about the
previously installed platform, i was thinking about abusing the wmac path we
already use to migrate the WiFi configuration.
However, i think this is not the most elegant way to solve this issue.
I have to think about that. I recently thought one could just check whether the
lan/wan assignment matches the one expected for ar71xx, but that would
obviously also catch cases were the user modified it to be like this.
> Despite, while having the abstraction of "rename_all_eth", I wonder
whether it would be possible and desirable to do all renames in one step:
> sed -i -e 's/eth0/ethX/' -e 's/eth1/eth0/' -e 's/ethX/eth1/' $file or
> even sed -i -e 's/eth0/eth1/' -e 's/eth0/eth1/' $file depending on
> how sed handles this internally. These options would mean less flash writes
(although this might not be too important here).
A rewrite with sed is not sufficient, as we will possible rewrite uci section
names, possibly referenced elsewhere. We have to loop thru all interface
values and lists, rewriting each occurrence.
Actually, I could well live with that. What kind of references are you
referring to?
If just someone really named a section with ethX, it will be renamed
consistently throught all uci files (unless they are stored in another
location).
Only in case someone uses a section name with ethX and refers to it e.g. in a
custom script, this will be a problem.
And this is where I think we do not have to account for every tiny possibility.
If someone upgrades to another architecture, I think it's fair to expect him to
check whether his custom scripts still work. We do not have to overdo it.
But that's just my point of view at the moment.
I'm in the middle of migrating some devices from soon-to-be-obsolete
ar71xx to ath79 target and was wondering about status of the eth0/eth1
vs. LAN/WAN assignment issue.
I'm aware of the 8dde11d521 ("ath79: dts: drop "simple-mfd" for gmacs in
SoC dtsi") [0] and following changes but that "fixed" the problem only
for devices which were following already reversed (I wouldn't call it
wrong or incorrect, I also prefer to have LAN on eth0 interface) SOC's
GMACx <> ethx assignment/register under ar71xx target - e.g. LAN on eth0
which is in fact SOC's GMAC1 and WAN on eth1 which is SOC's GMAC0. Good
explanation of that inverted assignment can be found in Jeff's patch
here: [1].
I have a feeling that the idea with migration script got abandoned
(Adrian?), so I was wondering if there is any other way we could
preserve ar71xx LAN/WAN <> ethX assignment in ath79?
For example, I have a QCA9531 based device with PHY4 (connected directly
to GMAC0) labeled as LAN (and registered as eth0 in kernel) and PHY3
(connected to GMAC1 over internal switch) labeled as WAN. On ath79, due
to change introduced in 8dde11d521, LAN and WAN order gets swapped (as
expected) but partially reverting above change (adding back "simple-mfd"
to eth1 in device's DTS, see below) brings back the "old" order of
interfaces.
{
compatible = "qca,ar9330-eth", "syscon", "simple-mfd";
mtd-mac-address = < 0x6>;
};
But it doesn't seem as a proper fix to me (maybe I'm wrong?) thus the
question about any other, better approach?
[0] https://github.com/openwrt/openwrt/commit/8dde11d521
[1]
https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg48526.html
--
Cheers,
Piotr
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 19.07] ramips: mt7621: ubnt-erx: allow sysupgrade from master
Hi Petr, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Petr Štetiar > Sent: Montag, 20. Januar 2020 20:40 > To: openwrt-devel@lists.openwrt.org > Cc: Petr Štetiar > Subject: [OpenWrt-Devel] [PATCH 19.07] ramips: mt7621: ubnt-erx: allow > sysupgrade from master > > Currently it's not possible to downgrade from master: > > Device ubiquiti,edgerouterx not supported by this image Supported > devices: ubnt-erx > > So fix it by adding a DTS based device name from master into > SUPPORTED_DEVICES list. Note that I changed somewhat between 100 and 150 devices when reorganizing board names in ramips between master and 19.07. So, unless you have a specific reason to deal with this particular device, there are more to come. ;-) I thus personally would not start to actively support "downgrading". On the other side, there is no downside to adding downgrade support for this particular device, so feel free to go ... Best Adrian > > Signed-off-by: Petr Štetiar > --- > target/linux/ramips/image/mt7621.mk | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/target/linux/ramips/image/mt7621.mk > b/target/linux/ramips/image/mt7621.mk > index 53a264f527a6..a874731a 100644 > --- a/target/linux/ramips/image/mt7621.mk > +++ b/target/linux/ramips/image/mt7621.mk > @@ -483,6 +483,7 @@ define Device/ubnt-erx >KERNEL_INITRAMFS := $$(KERNEL) | ubnt-erx-factory-image > $(KDIR)/tmp/$$(KERNEL_INITRAMFS_PREFIX)-factory.tar >IMAGE/sysupgrade.bin := sysupgrade-tar | append-metadata >DEVICE_TITLE := Ubiquiti EdgeRouter X > + SUPPORTED_DEVICES += ubiquiti_edgerouterx > endef > TARGET_DEVICES += ubnt-erx > > @@ -491,6 +492,7 @@ define Device/ubnt-erx-sfp >DTS := UBNT-ERX-SFP >DEVICE_TITLE := Ubiquiti EdgeRouter X-SFP >DEVICE_PACKAGES += kmod-i2c-algo-pca kmod-gpio-pca953x kmod-i2c- > gpio-custom > + SUPPORTED_DEVICES += ubiquiti_edgerouterx-sfp > endef > TARGET_DEVICES += ubnt-erx-sfp > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] procd: show process's exit code
ondrej.vot...@cvut.cz [2020-01-20 10:53:05]:
Ahoj,
this comment(if it's really needed and I doubt that) should go into commit
description, self-explaining code is prefered, everybody knows how to use man
pages already or knows how to use `git blame`.
> + /*
> + According to man waitpid(2) exit codes might be:
> + 0 -- everything is OK
> + SIGNALLED -- 1 - 64 - and since we want the same behavior as SHELL, we
> add 128
Why is having same behavior as shell desirable? Having answer to that question
in the commit description would probably help more.
> + @see http://tldp.org/LDP/abs/html/exitcodes.html
> + 256 - 65536 -- regular exit, strip the bottom byte with WEXITSTATUS
> macro.
> + @see man waitpid(2)
> + */
> + in->exit_code = WIFEXITED(ret) ? WEXITSTATUS(ret) : WIFSIGNALED(ret) ?
> 128 + WTERMSIG(ret) : 1;
I'm having hard time reviewing this line, probably something like bellow
(untested) would work as well:
static int process_wait_result(int status)
{
int ret;
ret = WEXITSTATUS(status);
if (WIFSIGNALED(status))
ret = 128 + WTERMSIG(status);
return ret;
}
in->exit_code = process_wait_result(ret);
-- ynezz
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2 1/2] ath79: WNDR3700v2: add dash before version in device name
Adapt Netgear WNDR3700v2 device identification string to ath79 naming
scheme by changing from 'wndr3700v2' to 'wndr3700-v2' (affects config,
makefile, init scripts and device tree definition).
Signed-off-by: Michal Cieslakiewicz
---
...etgear_wndr3700v2.dts => ar7161_netgear_wndr3700-v2.dts} | 4 ++--
.../linux/ath79/generic/base-files/etc/board.d/02_network | 4 ++--
.../base-files/etc/hotplug.d/firmware/10-ath9k-eeprom | 4 ++--
target/linux/ath79/image/generic.mk | 6 +++---
4 files changed, 9 insertions(+), 9 deletions(-)
rename target/linux/ath79/dts/{ar7161_netgear_wndr3700v2.dts =>
ar7161_netgear_wndr3700-v2.dts} (85%)
diff --git a/target/linux/ath79/dts/ar7161_netgear_wndr3700v2.dts
b/target/linux/ath79/dts/ar7161_netgear_wndr3700-v2.dts
similarity index 85%
rename from target/linux/ath79/dts/ar7161_netgear_wndr3700v2.dts
rename to target/linux/ath79/dts/ar7161_netgear_wndr3700-v2.dts
index 76ef300a81..f3d27f2bdf 100644
--- a/target/linux/ath79/dts/ar7161_netgear_wndr3700v2.dts
+++ b/target/linux/ath79/dts/ar7161_netgear_wndr3700-v2.dts
@@ -4,8 +4,8 @@
#include "ar7161_netgear_wndr3700.dtsi"
/ {
- compatible = "netgear,wndr3700v2", "qca,ar7161";
- model = "Netgear WNDR3700v2";
+ compatible = "netgear,wndr3700-v2", "qca,ar7161";
+ model = "Netgear WNDR3700 v2";
};
{
diff --git a/target/linux/ath79/generic/base-files/etc/board.d/02_network
b/target/linux/ath79/generic/base-files/etc/board.d/02_network
index a96b504d5a..4c3305a304 100755
--- a/target/linux/ath79/generic/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/generic/base-files/etc/board.d/02_network
@@ -178,7 +178,7 @@ ath79_setup_interfaces()
"0@eth0" "2:lan" "3:lan" "4:lan" "1:wan"
;;
netgear,wndr3700|\
- netgear,wndr3700v2|\
+ netgear,wndr3700-v2|\
netgear,wndr3800|\
netgear,wndr3800ch)
ucidef_set_interface_wan "eth1"
@@ -379,7 +379,7 @@ ath79_setup_macs()
label_mac=$wan_mac
;;
netgear,wndr3700|\
- netgear,wndr3700v2|\
+ netgear,wndr3700-v2|\
netgear,wndr3800)
lan_mac=$(macaddr_setbit_la "$(mtd_get_mac_binary art 0x0)")
;;
diff --git
a/target/linux/ath79/generic/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
b/target/linux/ath79/generic/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
index 4158116256..0e6d63495d 100644
---
a/target/linux/ath79/generic/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
+++
b/target/linux/ath79/generic/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
@@ -109,7 +109,7 @@ case "$FIRMWARE" in
case $board in
buffalo,wzr-hp-ag300h|\
netgear,wndr3700|\
- netgear,wndr3700v2|\
+ netgear,wndr3700-v2|\
netgear,wndr3800|\
netgear,wndr3800ch)
caldata_extract "art" 0x1000 0xeb8
@@ -127,7 +127,7 @@ case "$FIRMWARE" in
case $board in
buffalo,wzr-hp-ag300h|\
netgear,wndr3700|\
- netgear,wndr3700v2|\
+ netgear,wndr3700-v2|\
netgear,wndr3800|\
netgear,wndr3800ch)
caldata_extract "art" 0x5000 0xeb8
diff --git a/target/linux/ath79/image/generic.mk
b/target/linux/ath79/image/generic.mk
index 800e1c7a7d..ae7bf26e27 100644
--- a/target/linux/ath79/image/generic.mk
+++ b/target/linux/ath79/image/generic.mk
@@ -780,7 +780,7 @@ define Device/netgear_wndr3700
endef
TARGET_DEVICES += netgear_wndr3700
-define Device/netgear_wndr3700v2
+define Device/netgear_wndr3700-v2
$(Device/netgear_wndr3x00)
DEVICE_MODEL := WNDR3700
DEVICE_VARIANT := v2
@@ -788,9 +788,9 @@ define Device/netgear_wndr3700v2
NETGEAR_BOARD_ID := WNDR3700v2
NETGEAR_HW_ID := 29763654+16+64
IMAGE_SIZE := 15872k
- SUPPORTED_DEVICES += wndr3700
+ SUPPORTED_DEVICES += wndr3700 netgear,wndr3700v2
endef
-TARGET_DEVICES += netgear_wndr3700v2
+TARGET_DEVICES += netgear_wndr3700-v2
define Device/netgear_wndr3800
$(Device/netgear_wndr3x00)
--
2.25.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2 2/2] ath79: uboot-envtools: add Netgear WNDR3700v2
Add Netgear WNDR3700v2 to the list of supported boards. Signed-off-by: Michal Cieslakiewicz --- package/boot/uboot-envtools/files/ath79 | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/package/boot/uboot-envtools/files/ath79 b/package/boot/uboot-envtools/files/ath79 index aafced98db..66f7dc6a64 100644 --- a/package/boot/uboot-envtools/files/ath79 +++ b/package/boot/uboot-envtools/files/ath79 @@ -44,7 +44,8 @@ yuncore,xd4200) buffalo,wzr-hp-ag300h) ubootenv_add_uci_config "/dev/mtd3" "0x0" "0x1" "0x1" ;; -netgear,wndr3700) +netgear,wndr3700|\ +netgear,wndr3700-v2) ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x2" "0x1" ;; netgear,wndr3700-v4|\ -- 2.25.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2 0/2] ath79: update device naming for Netgear WNDR3700v2
This patch changes device string to 'wndr3700-v2' (adds dash before
variant) making it compatible with naming convention for ath79 target.
Then board, under its new name, is added to uboot-envtools.
Changes v1->v2:
* SUPPORTED_DEVICES fixed to allow sysupgrading from older ath79 builds
Patch list (2):
ath79: WNDR3700v2: add dash before version in device name
ath79: uboot-envtools: add Netgear WNDR3700v2
package/boot/uboot-envtools/files/ath79 | 3 ++-
...etgear_wndr3700v2.dts => ar7161_netgear_wndr3700-v2.dts} | 4 ++--
.../linux/ath79/generic/base-files/etc/board.d/02_network | 4 ++--
.../base-files/etc/hotplug.d/firmware/10-ath9k-eeprom | 4 ++--
target/linux/ath79/image/generic.mk | 6 +++---
5 files changed, 11 insertions(+), 10 deletions(-)
rename target/linux/ath79/dts/{ar7161_netgear_wndr3700v2.dts =>
ar7161_netgear_wndr3700-v2.dts} (85%)
--
2.25.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ath79: fix SUPPORTED_DEVICES for WNDR4300 and WNDR3700v4
Kernel partition increase to 4 MiBs for Netgear WNDR3700v4 and WNDR4300 routers breaks sysupgrade image compatibility with ar71xx builds. Therefore, SUPPORTED_DEVICES variable has to be removed for both devices from target makefile. Signed-off-by: Michal Cieslakiewicz --- target/linux/ath79/image/nand.mk | 2 -- 1 file changed, 2 deletions(-) diff --git a/target/linux/ath79/image/nand.mk b/target/linux/ath79/image/nand.mk index f6929cd88e..95ddca26b0 100644 --- a/target/linux/ath79/image/nand.mk +++ b/target/linux/ath79/image/nand.mk @@ -138,7 +138,6 @@ define Device/netgear_wndr3700-v4 NETGEAR_KERNEL_MAGIC := 0x33373033 NETGEAR_BOARD_ID := WNDR3700v4 NETGEAR_HW_ID := 29763948+128+128 - SUPPORTED_DEVICES += wndr3700v4 $(Device/netgear_ath79_nand) endef TARGET_DEVICES += netgear_wndr3700-v4 @@ -149,7 +148,6 @@ define Device/netgear_wndr4300 NETGEAR_KERNEL_MAGIC := 0x33373033 NETGEAR_BOARD_ID := WNDR4300 NETGEAR_HW_ID := 29763948+0+128+128+2x2+3x3 - SUPPORTED_DEVICES += wndr4300 $(Device/netgear_ath79_nand) endef TARGET_DEVICES += netgear_wndr4300 -- 2.25.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] dnsmasq: Ignore carrier status for bridge interfaces
dnsmasq sometimes does not listen for DHCP at bootup on lan (see bug FS#1765).
This occurs because netifd can incorrectly indicate carrier down on an
interface through devstatus after issuing a carrier up hotplug event.
This patch ignores carrier status for bridge interfaces, as this does not
reflect media state so is not a useful check.
Signed-off-by: Reuben Dowle
---
package/network/services/dnsmasq/files/dnsmasq.init | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/package/network/services/dnsmasq/files/dnsmasq.init
b/package/network/services/dnsmasq/files/dnsmasq.init
index ae02f32..dd9874b
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -104,9 +104,12 @@ dhcp_check() {
# If there's no carrier yet, skip this interface.
# The init script will be called again once the link is up
-case "$(devstatus "$ifname" | jsonfilter -e @.carrier)" in
-false) return 1;;
-esac
+local carrier
+local type
+eval $(devstatus "$ifname" | jsonfilter -e "carrier=@.carrier" -e
"type=@.type")
+if [ "$carrier" = "false" -a "$type" != "bridge" ]; then
+return 1
+fi
udhcpc -n -q -s /bin/true -t 1 -i "$ifname" >&- && rv=1 || rv=0
--
2.7.4
The information in this email communication (inclusive of attachments) is
confidential to 4RF Limited and the intended recipient(s). If you are not the
intended recipient(s), please note that any use, disclosure, distribution or
copying of this information or any part thereof is strictly prohibited and that
the author accepts no liability for the consequences of any action taken on the
basis of the information provided. If you have received this email in error,
please notify the sender immediately by return email and then delete all
instances of this email from your system. 4RF Limited will not accept
responsibility for any consequences associated with the use of this email
(including, but not limited to, damages sustained as a result of any viruses
and/or any action or lack of action taken in reliance on it).
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH][libubox] blobmsg: blobmsg_parse and blobmsg_parse_array oob read fixes
Hello,
I have checked v2 of the patch, and can confirm that it fixes the out
of bounds reads.
I have also fuzzed blobmsg_parse and blobmsg_parse_array for an hour
with LibFuzzer, to check that there are no more similar shallow issues
and no new crashes were found.
Thank you for the help!
Regards,
Juraj
On Mon, Jan 20, 2020 at 12:09 PM Petr Štetiar wrote:
>
> Juraj Vijtiuk [2020-01-14 22:11:18]:
>
> Hi,
>
> I just sent v2 for review[2], can you check it please?
>
> > > > @@ -191,7 +197,11 @@ int blobmsg_parse(const struct blobmsg_policy
> > > > *policy, int policy_len,
> > > > }
> > > >
> > > > __blob_for_each_attr(attr, data, len) {
> > > > + if (len < sizeof(struct blob_attr) + sizeof(struct
> > > > blobmsg_hdr))
> > > > + return -1;
> > >
> > > If there is such problem, then this should be probably fixed directly in
> > > __blob_for_each_attr so we possibly protect other __blob_for_each_attr
> > > users[1].
> >
> > Can you maybe provide a patch? I'd be happy to test it and let you
> > know what the results are.
>
> Seems like I need more time on this, to come up with some meaningful solution
> (it's blob related function, but it would need to check blobmsg etc.), I've
> just prepared some common helper functions which should help. I don't want to
> block this changes just because of that. I'll try to add you to the Cc: in
> that follow up patch.
>
> 1. https://patchwork.ozlabs.org/patch/1225878/
>
> -- ynezz
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/2] ath79: update device naming for Netgear WNDR3700v2
> > What is the motivation for this? > > The router was originally marketed as "WNDR3700v2" and that is both > in the packaging and also in the printed label in the router itself. > The "v2" is not a typical separate version number like many 6.1, 3.21 > type of revisions next to the serial number, but it has been part of > the device name. > Hello Hannu, My patch changes the way it is defined in OpenWrt - 'wndr3700v2' is a sort of naming artifact, all other routers in ath79 target use dash for version separation - even Netgear ones like WNR612v2, WNDR4300v2 and so on. And yes, it 'breaks' smooth downgrade path to ar71xx, but please be aware that when changing branches it is always better to begin with clean/default device configuration. Best regards Michal ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 19.07] ramips: mt7621: ubnt-erx: allow sysupgrade from master
Currently it's not possible to downgrade from master: Device ubiquiti,edgerouterx not supported by this image Supported devices: ubnt-erx So fix it by adding a DTS based device name from master into SUPPORTED_DEVICES list. Signed-off-by: Petr Štetiar --- target/linux/ramips/image/mt7621.mk | 2 ++ 1 file changed, 2 insertions(+) diff --git a/target/linux/ramips/image/mt7621.mk b/target/linux/ramips/image/mt7621.mk index 53a264f527a6..a874731a 100644 --- a/target/linux/ramips/image/mt7621.mk +++ b/target/linux/ramips/image/mt7621.mk @@ -483,6 +483,7 @@ define Device/ubnt-erx KERNEL_INITRAMFS := $$(KERNEL) | ubnt-erx-factory-image $(KDIR)/tmp/$$(KERNEL_INITRAMFS_PREFIX)-factory.tar IMAGE/sysupgrade.bin := sysupgrade-tar | append-metadata DEVICE_TITLE := Ubiquiti EdgeRouter X + SUPPORTED_DEVICES += ubiquiti_edgerouterx endef TARGET_DEVICES += ubnt-erx @@ -491,6 +492,7 @@ define Device/ubnt-erx-sfp DTS := UBNT-ERX-SFP DEVICE_TITLE := Ubiquiti EdgeRouter X-SFP DEVICE_PACKAGES += kmod-i2c-algo-pca kmod-gpio-pca953x kmod-i2c-gpio-custom + SUPPORTED_DEVICES += ubiquiti_edgerouterx-sfp endef TARGET_DEVICES += ubnt-erx-sfp ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/2] ath79: WNDR3700v2: add dash before version in device name
On Sun, 19 Jan 2020 16:42:12 +0100 wrote: > Hi, > > > - SUPPORTED_DEVICES += wndr3700 > > + SUPPORTED_DEVICES += wndr3700 wndr3700v2 > > That would have to be > > SUPPORTED_DEVICES += wndr3700 netgear,wndr3700v2 > > Best > > Adrian Thanks! I'll issue v2 soon with that one fixed. Best regards Michal ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [19.07] ramips: add kmod-mt7615e module to Netgear R6350 image
Op maandag 20 januari 2020 om 20:00 schreef Adrian Schmutzler : Hi, -Original Message- From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of Stijn Segers Sent: Montag, 20. Januar 2020 19:50 To: openwrt-devel@lists.openwrt.org Subject: [OpenWrt-Devel] [PATCH] [19.07] ramips: add kmod-mt7615e module to Netgear R6350 image MT7615E support wasn't present in OpenWrt's mt76 version prior to 19.07 release, but it is now, so add the module to the image. what about cherry-picking https://github.com/openwrt/openwrt/commit/9861fa7abab97cb928aaa6cd5732a413d973ac95 instead? Bah! Just like with the Xiaomi, you're all too right about that. Should have checked master first... Stijn Best Adrian Signed-off-by: Stijn Segers --- target/linux/ramips/image/mt7621.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/ramips/image/mt7621.mk b/target/linux/ramips/image/mt7621.mk index 53a264f527..fd3a8e558e 100644 --- a/target/linux/ramips/image/mt7621.mk +++ b/target/linux/ramips/image/mt7621.mk @@ -374,7 +374,7 @@ define Device/netgear_r6350 IMAGE/rootfs.bin := append-ubi | check-size (IMAGE_SIZE) DEVICE_TITLE := Netgear R6350 DEVICE_PACKAGES := \ - kmod-mt7603 kmod-usb3 kmod-usb-ledtrig-usbport wpad-basic + kmod-mt7603 kmod-mt7615e kmod-usb3 kmod-usb-ledtrig-usbport wpad-basic endef TARGET_DEVICES += netgear_r6350 -- 2.20.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: [OpenWrt-Devel] [PATCH] [19.07] ramips: add kmod-mt7615e module to Netgear R6350 image
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On > Behalf Of Stijn Segers > Sent: Montag, 20. Januar 2020 19:50 > To: openwrt-devel@lists.openwrt.org > Subject: [OpenWrt-Devel] [PATCH] [19.07] ramips: add kmod-mt7615e module to > Netgear R6350 image > > MT7615E support wasn't present in OpenWrt's mt76 version prior to 19.07 > release, but it is now, so add the module to the image. what about cherry-picking https://github.com/openwrt/openwrt/commit/9861fa7abab97cb928aaa6cd5732a413d973ac95 instead? Best Adrian > > Signed-off-by: Stijn Segers > --- > target/linux/ramips/image/mt7621.mk | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/target/linux/ramips/image/mt7621.mk > b/target/linux/ramips/image/mt7621.mk > index 53a264f527..fd3a8e558e 100644 > --- a/target/linux/ramips/image/mt7621.mk > +++ b/target/linux/ramips/image/mt7621.mk > @@ -374,7 +374,7 @@ define Device/netgear_r6350 >IMAGE/rootfs.bin := append-ubi | check-size (IMAGE_SIZE) >DEVICE_TITLE := Netgear R6350 >DEVICE_PACKAGES := \ > - kmod-mt7603 kmod-usb3 kmod-usb-ledtrig-usbport wpad-basic > + kmod-mt7603 kmod-mt7615e kmod-usb3 kmod-usb-ledtrig-usbport > wpad-basic > endef > TARGET_DEVICES += netgear_r6350 > > -- > 2.20.1 > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [19.07] ramips: add kmod-mt7615e module to Netgear R6350 image
MT7615E support wasn't present in OpenWrt's mt76 version prior to 19.07 release, but it is now, so add the module to the image. Signed-off-by: Stijn Segers --- target/linux/ramips/image/mt7621.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/ramips/image/mt7621.mk b/target/linux/ramips/image/mt7621.mk index 53a264f527..fd3a8e558e 100644 --- a/target/linux/ramips/image/mt7621.mk +++ b/target/linux/ramips/image/mt7621.mk @@ -374,7 +374,7 @@ define Device/netgear_r6350 IMAGE/rootfs.bin := append-ubi | check-size (IMAGE_SIZE) DEVICE_TITLE := Netgear R6350 DEVICE_PACKAGES := \ - kmod-mt7603 kmod-usb3 kmod-usb-ledtrig-usbport wpad-basic + kmod-mt7603 kmod-mt7615e kmod-usb3 kmod-usb-ledtrig-usbport wpad-basic endef TARGET_DEVICES += netgear_r6350 -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] hostapd: start hostapd/wpa_supplicant for all wiphy devices
c888e17e06 ("hostapd: manage instances via procd instead of pidfile")
added procd support for managing hostapd and wpa_supplicant daemons
but at the same time limited wiphy names to 'phy*'.
This brings back initial behaviour (introduced in 60fb4c92b6 ("hostapd:
add ubus reload") and makes procd manage daemons for any wiphy device
found in '/sys/class/ieee80211'.
CC: Felix Fietkau
CC: Daniel Golle
Signed-off-by: Piotr Dymacz
---
package/network/services/hostapd/Makefile | 2 +-
package/network/services/hostapd/files/hostapd.hotplug | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/package/network/services/hostapd/Makefile
b/package/network/services/hostapd/Makefile
index 2642a263dc..1b6434674a 100644
--- a/package/network/services/hostapd/Makefile
+++ b/package/network/services/hostapd/Makefile
@@ -7,7 +7,7 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=hostapd
-PKG_RELEASE:=6
+PKG_RELEASE:=7
PKG_SOURCE_URL:=http://w1.fi/hostap.git
PKG_SOURCE_PROTO:=git
diff --git a/package/network/services/hostapd/files/hostapd.hotplug
b/package/network/services/hostapd/files/hostapd.hotplug
index c319d42c1a..2c936fde75 100644
--- a/package/network/services/hostapd/files/hostapd.hotplug
+++ b/package/network/services/hostapd/files/hostapd.hotplug
@@ -21,7 +21,7 @@ service_data() {
procd_open_service hostapd
-for phy in phy*; do
+for phy in *; do
[ -d "$phy" ] || continue
mkdir -p /var/run/wpa_supplicant-$phy /var/run/hostapd-$phy
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 2/4] ath79: WNDR4300: increase kernel partition to 4M
Hi,
can you comment on/take care of
https://github.com/openwrt/openwrt/commit/4e6af8b9efcfc51e217d793239487dd8af1f410e#commitcomment-36881083
Best
Adrian
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
> Behalf Of Michal Cieslakiewicz
> Sent: Sonntag, 22. Dezember 2019 21:53
> To: openwrt-devel@lists.openwrt.org
> Cc: Adrian Schmutzler ; David Bauer bauer.net>
> Subject: [OpenWrt-Devel] [PATCH v2 2/4] ath79: WNDR4300: increase kernel
> partition to 4M
>
> Increase kernel partition from 2 MiB to 4 MiB for Netgear WNDR routers
> with NAND flash. Change affects following devices:
> * Netgear WNDR3700 v4
> * Netgear WNDR4300
>
> Signed-off-by: Michal Cieslakiewicz
> ---
> target/linux/ath79/dts/ar9344_netgear_wndr.dtsi | 10 +-
> target/linux/ath79/image/nand.mk| 2 +-
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/target/linux/ath79/dts/ar9344_netgear_wndr.dtsi
> b/target/linux/ath79/dts/ar9344_netgear_wndr.dtsi
> index 38dd052f5f..dd212c0d88 100644
> --- a/target/linux/ath79/dts/ar9344_netgear_wndr.dtsi
> +++ b/target/linux/ath79/dts/ar9344_netgear_wndr.dtsi
> @@ -106,9 +106,9 @@
> #address-cells = <1>;
> #size-cells = <1>;
>
> - ubi@8c {
> + ubi@ac {
> label = "ubi";
> - reg = <0x0 0x770>;
> + reg = <0x0 0x750>;
> };
> };
> };
> @@ -167,12 +167,12 @@
>
> kernel@6c {
> label = "kernel";
> - reg = <0x6c 0x20>;
> + reg = <0x6c 0x40>;
> };
>
> - ubipart0: partition@8c {
> + ubipart0: partition@ac {
> label = "ubipart0";
> - reg = <0x8c 0x170>;
> + reg = <0xac 0x150>;
> };
>
> partition@6c {
> diff --git a/target/linux/ath79/image/nand.mk
> b/target/linux/ath79/image/nand.mk
> index c6a1441ed9..5f893e0044 100644
> --- a/target/linux/ath79/image/nand.mk
> +++ b/target/linux/ath79/image/nand.mk
> @@ -111,7 +111,7 @@ TARGET_DEVICES += glinet_gl-ar750s-nor
> define Device/netgear_ath79_nand
>DEVICE_VENDOR := NETGEAR
>DEVICE_PACKAGES := kmod-usb2 kmod-usb-ledtrig-usbport
> - KERNEL_SIZE := 2048k
> + KERNEL_SIZE := 4096k
>BLOCKSIZE := 128k
>PAGESIZE := 2048
>IMAGE_SIZE := 25600k
> --
> 2.24.1
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ath10k-firmware: fix mirror hash
Fixes: 641a93f0f226 ("ath10k-firmware: update wave 1 firmware to
10.2.4-1.0-00047")
Signed-off-by: DENG Qingfang
---
package/firmware/ath10k-firmware/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/package/firmware/ath10k-firmware/Makefile
b/package/firmware/ath10k-firmware/Makefile
index 394580549b..9f1e7e676b 100644
--- a/package/firmware/ath10k-firmware/Makefile
+++ b/package/firmware/ath10k-firmware/Makefile
@@ -10,7 +10,7 @@ include $(TOPDIR)/rules.mk
PKG_NAME:=ath10k-firmware
PKG_SOURCE_DATE:=2019-10-03
PKG_SOURCE_VERSION:=d622d160e9f552ead68d9ae81b715422892dc2ef
-PKG_MIRROR_HASH:=9d56a9942b7be7effdeed6d0688a9bdcfae76a2921a630714c3e2d8390ea8934
+PKG_MIRROR_HASH:=2e504e071c3f896d629c4cfffe7ff4b5f1acdb4fecd3f01e8ff8c73e87a67cc7
PKG_RELEASE:=1
PKG_SOURCE_PROTO:=git
--
2.24.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] mvebu: use SOC to derive DEVICE_DTS
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
> Behalf Of Tomasz Maciej Nowak
> Sent: Montag, 20. Januar 2020 16:08
> To: Adrian Schmutzler ; openwrt-
> de...@lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] [PATCH 2/2] mvebu: use SOC to derive
> DEVICE_DTS
>
> W dniu 18.01.2020 o 02:21, Adrian Schmutzler pisze:
> > This introduces the SOC variable to mvebu target to derive some of
> > the DEVICE_DTS variables based on the SOC prefix and the device
> > definition name.
> >
> > Since DTS names and compatible are inconsistent also in the kernel
> > for this target, the scheme cannot be applied to all devices, though.
> >
> > While at it, change the DTS name of the armada-3720-udpu to lower-case,
> > which is the common practice for DTS file names.
>
> Well, this (uDPU change) will be reverted anyway, when kernel 5.4 will be
> introduced, since in upstream it's upper case. So it makes no sense.
thanks for the info, I actually didn't check kernel here.
Although I dislike this inconsistency and wonder how it got accepted into
kernel, you're right that it makes no sense to have it lower-case in OpenWrt
then and I will change it back.
Best
Adrian
>
> For the rest
> Acked-by: Tomasz Maciej Nowak
>
> >
> > Signed-off-by: Adrian Schmutzler
> > ---
> > .../{armada-3720-uDPU.dts => armada-3720-udpu.dts} | 0
> > target/linux/mvebu/image/Makefile | 1 +
> > target/linux/mvebu/image/cortex-a53.mk | 10 +-
> > target/linux/mvebu/image/cortex-a9.mk | 6 +++---
> > .../patches-4.19/530-add_armada-3820-uDPU-dts.patch| 2 +-
> > 5 files changed, 10 insertions(+), 9 deletions(-)
> > rename target/linux/mvebu/files-4.19/arch/arm64/boot/dts/marvell/{armada-
> 3720-uDPU.dts => armada-3720-udpu.dts} (100%)
> >
> > diff --git a/target/linux/mvebu/files-
> 4.19/arch/arm64/boot/dts/marvell/armada-3720-uDPU.dts
> b/target/linux/mvebu/files-4.19/arch/arm64/boot/dts/marvell/armada-3720-
> udpu.dts
> > similarity index 100%
> > rename from target/linux/mvebu/files-
> 4.19/arch/arm64/boot/dts/marvell/armada-3720-uDPU.dts
> > rename to target/linux/mvebu/files-
> 4.19/arch/arm64/boot/dts/marvell/armada-3720-udpu.dts
> > diff --git a/target/linux/mvebu/image/Makefile
> b/target/linux/mvebu/image/Makefile
> > index 6dd7bde7ae..c08b113b36 100644
> > --- a/target/linux/mvebu/image/Makefile
> > +++ b/target/linux/mvebu/image/Makefile
> > @@ -77,6 +77,7 @@ endef
> >
> > define Device/Default
> >PROFILES := Default
> > + DEVICE_DTS = $$(SOC)-$(lastword $(subst _, ,$(1)))
> >BOARD_NAME = $$(DEVICE_DTS)
> >KERNEL_NAME := zImage
> >KERNEL := kernel-bin | append-dtb | uImage none
> > diff --git a/target/linux/mvebu/image/cortex-a53.mk
> b/target/linux/mvebu/image/cortex-a53.mk
> > index e58a3c42b9..c9d06ddbad 100644
> > --- a/target/linux/mvebu/image/cortex-a53.mk
> > +++ b/target/linux/mvebu/image/cortex-a53.mk
> > @@ -6,7 +6,7 @@ define Device/globalscale_espressobin
> >DEVICE_ALT0_VENDOR := Marvell
> >DEVICE_ALT0_MODEL := Armada 3700 Community Board
> >DEVICE_ALT0_VARIANT := Non-eMMC
> > - DEVICE_DTS := armada-3720-espressobin
> > + SOC := armada-3720
> > endef
> > TARGET_DEVICES += globalscale_espressobin
> >
> > @@ -18,7 +18,7 @@ define Device/globalscale_espressobin-emmc
> >DEVICE_ALT0_VENDOR := Marvell
> >DEVICE_ALT0_MODEL := Armada 3700 Community Board
> >DEVICE_ALT0_VARIANT := eMMC
> > - DEVICE_DTS := armada-3720-espressobin-emmc
> > + SOC := armada-3720
> > endef
> > TARGET_DEVICES += globalscale_espressobin-emmc
> >
> > @@ -30,7 +30,7 @@ define Device/globalscale_espressobin-v7
> >DEVICE_ALT0_VENDOR := Marvell
> >DEVICE_ALT0_MODEL := Armada 3700 Community Board
> >DEVICE_ALT0_VARIANT := V7 Non-eMMC
> > - DEVICE_DTS := armada-3720-espressobin-v7
> > + SOC := armada-3720
> > endef
> > TARGET_DEVICES += globalscale_espressobin-v7
> >
> > @@ -42,7 +42,7 @@ define Device/globalscale_espressobin-v7-emmc
> >DEVICE_ALT0_VENDOR := Marvell
> >DEVICE_ALT0_MODEL := Armada 3700 Community Board
> >DEVICE_ALT0_VARIANT := V7 eMMC
> > - DEVICE_DTS := armada-3720-espressobin-v7-emmc
> > + SOC := armada-3720
> > endef
> > TARGET_DEVICES += globalscale_espressobin-v7-emmc
> >
> > @@ -58,7 +58,7 @@ define Device/methode_udpu
> >$(call Device/Default-arm64)
> >DEVICE_VENDOR := Methode
> >DEVICE_MODEL := micro-DPU (uDPU)
> > - DEVICE_DTS := armada-3720-uDPU
> > + SOC := armada-3720
> >KERNEL_LOADADDR := 0x0008
> >KERNEL_INITRAMFS := kernel-bin | gzip | fit gzip
> $$(DTS_DIR)/$$(DEVICE_DTS).dtb
> >KERNEL_INITRAMFS_SUFFIX := .itb
> > diff --git a/target/linux/mvebu/image/cortex-a9.mk
> b/target/linux/mvebu/image/cortex-a9.mk
> > index 389082e426..79253049c7 100644
> > --- a/target/linux/mvebu/image/cortex-a9.mk
> > +++ b/target/linux/mvebu/image/cortex-a9.mk
> > @@ -93,7 +93,7 @@ define
Re: [OpenWrt-Devel] [RFC] commit message in YAML format for new devices
Hi Paul,
Hi Martin,
On Sun, Jan 12, 2020 at 10:13:42PM -1000, Paul Spooren wrote:
> Hi,
>
> On 1/12/20 1:05 PM, Martin Blumenstingl wrote:
> > Hi Paul,
> >
> > On Sun, Jan 12, 2020 at 10:47 PM Paul Spooren wrote:
> > > Hi all,
> > >
> > > some time ago I created a (now outdated) device overview[0] based on
> > > YAML meta data. This approach could simplify maintaining an device
> > > overview and device specific pages[1].
> > >
> > > All commits adding new devices already include most relevant information
> > > for creating the overview. However it would be convenient if developers
> > > would format their commit messages in a generic format, therefore I'd
> > > propose the following:
> > >
> > > Every commit message for newly added devices must contain a number of
> > > hardware information and steps for an initial installation.
> > > The hardware information should contain at least the following
> > > information, maybe more:
> > >
> > > SoC, flash, ram, wifi, LEDs, buttons, USB, serial, vendor, model, device
> > > tree ID, Ethernet ports
> > can we automate this somehow?
> > the device tree files already contain most of that information.
>
> If you have a tool to extract such data or ideas on how to create such,
> that'd be great.
>
> As an alternative I could also create a shell script that extracts data on a
> running machine, but that might miss some details.
I think that's the better idea, because device-tree doesn't necessarily
cover everything. at runtime we can access /sys/devices/... to get most
relevant info. some things (like the type of the flash chip) are more
tricky apparently, I do this to extract (NOR) flash-chip from dmesg for
example:
for fc in $(for fp in /sys/class/mtd/mtd*/device; do basename $(readlink $fp);
done | grep -v mtd | sort -u); do dmesg | grep -o "${fc}:.*bytes.*"; done
(works only straight after boot, once the logbuffer run full this info
is no longer available)
some things, such as the number of USB ports is really tricky, because
many times there are USB hub chips involved and simply not all ports of
the hub are exposed...
Just my 2 cents...
Cheers
Daniel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] mvebu: use SOC to derive DEVICE_DTS
W dniu 18.01.2020 o 02:21, Adrian Schmutzler pisze:
> This introduces the SOC variable to mvebu target to derive some of
> the DEVICE_DTS variables based on the SOC prefix and the device
> definition name.
>
> Since DTS names and compatible are inconsistent also in the kernel
> for this target, the scheme cannot be applied to all devices, though.
>
> While at it, change the DTS name of the armada-3720-udpu to lower-case,
> which is the common practice for DTS file names.
Well, this (uDPU change) will be reverted anyway, when kernel 5.4 will be
introduced, since in upstream it's upper case. So it makes no sense.
For the rest
Acked-by: Tomasz Maciej Nowak
>
> Signed-off-by: Adrian Schmutzler
> ---
> .../{armada-3720-uDPU.dts => armada-3720-udpu.dts} | 0
> target/linux/mvebu/image/Makefile | 1 +
> target/linux/mvebu/image/cortex-a53.mk | 10 +-
> target/linux/mvebu/image/cortex-a9.mk | 6 +++---
> .../patches-4.19/530-add_armada-3820-uDPU-dts.patch| 2 +-
> 5 files changed, 10 insertions(+), 9 deletions(-)
> rename
> target/linux/mvebu/files-4.19/arch/arm64/boot/dts/marvell/{armada-3720-uDPU.dts
> => armada-3720-udpu.dts} (100%)
>
> diff --git
> a/target/linux/mvebu/files-4.19/arch/arm64/boot/dts/marvell/armada-3720-uDPU.dts
>
> b/target/linux/mvebu/files-4.19/arch/arm64/boot/dts/marvell/armada-3720-udpu.dts
> similarity index 100%
> rename from
> target/linux/mvebu/files-4.19/arch/arm64/boot/dts/marvell/armada-3720-uDPU.dts
> rename to
> target/linux/mvebu/files-4.19/arch/arm64/boot/dts/marvell/armada-3720-udpu.dts
> diff --git a/target/linux/mvebu/image/Makefile
> b/target/linux/mvebu/image/Makefile
> index 6dd7bde7ae..c08b113b36 100644
> --- a/target/linux/mvebu/image/Makefile
> +++ b/target/linux/mvebu/image/Makefile
> @@ -77,6 +77,7 @@ endef
>
> define Device/Default
>PROFILES := Default
> + DEVICE_DTS = $$(SOC)-$(lastword $(subst _, ,$(1)))
>BOARD_NAME = $$(DEVICE_DTS)
>KERNEL_NAME := zImage
>KERNEL := kernel-bin | append-dtb | uImage none
> diff --git a/target/linux/mvebu/image/cortex-a53.mk
> b/target/linux/mvebu/image/cortex-a53.mk
> index e58a3c42b9..c9d06ddbad 100644
> --- a/target/linux/mvebu/image/cortex-a53.mk
> +++ b/target/linux/mvebu/image/cortex-a53.mk
> @@ -6,7 +6,7 @@ define Device/globalscale_espressobin
>DEVICE_ALT0_VENDOR := Marvell
>DEVICE_ALT0_MODEL := Armada 3700 Community Board
>DEVICE_ALT0_VARIANT := Non-eMMC
> - DEVICE_DTS := armada-3720-espressobin
> + SOC := armada-3720
> endef
> TARGET_DEVICES += globalscale_espressobin
>
> @@ -18,7 +18,7 @@ define Device/globalscale_espressobin-emmc
>DEVICE_ALT0_VENDOR := Marvell
>DEVICE_ALT0_MODEL := Armada 3700 Community Board
>DEVICE_ALT0_VARIANT := eMMC
> - DEVICE_DTS := armada-3720-espressobin-emmc
> + SOC := armada-3720
> endef
> TARGET_DEVICES += globalscale_espressobin-emmc
>
> @@ -30,7 +30,7 @@ define Device/globalscale_espressobin-v7
>DEVICE_ALT0_VENDOR := Marvell
>DEVICE_ALT0_MODEL := Armada 3700 Community Board
>DEVICE_ALT0_VARIANT := V7 Non-eMMC
> - DEVICE_DTS := armada-3720-espressobin-v7
> + SOC := armada-3720
> endef
> TARGET_DEVICES += globalscale_espressobin-v7
>
> @@ -42,7 +42,7 @@ define Device/globalscale_espressobin-v7-emmc
>DEVICE_ALT0_VENDOR := Marvell
>DEVICE_ALT0_MODEL := Armada 3700 Community Board
>DEVICE_ALT0_VARIANT := V7 eMMC
> - DEVICE_DTS := armada-3720-espressobin-v7-emmc
> + SOC := armada-3720
> endef
> TARGET_DEVICES += globalscale_espressobin-v7-emmc
>
> @@ -58,7 +58,7 @@ define Device/methode_udpu
>$(call Device/Default-arm64)
>DEVICE_VENDOR := Methode
>DEVICE_MODEL := micro-DPU (uDPU)
> - DEVICE_DTS := armada-3720-uDPU
> + SOC := armada-3720
>KERNEL_LOADADDR := 0x0008
>KERNEL_INITRAMFS := kernel-bin | gzip | fit gzip
> $$(DTS_DIR)/$$(DEVICE_DTS).dtb
>KERNEL_INITRAMFS_SUFFIX := .itb
> diff --git a/target/linux/mvebu/image/cortex-a9.mk
> b/target/linux/mvebu/image/cortex-a9.mk
> index 389082e426..79253049c7 100644
> --- a/target/linux/mvebu/image/cortex-a9.mk
> +++ b/target/linux/mvebu/image/cortex-a9.mk
> @@ -93,7 +93,7 @@ define Device/plathome_openblocks-ax3-4
>DEVICE_VENDOR := Plat'Home
>DEVICE_MODEL := OpenBlocks AX3
>DEVICE_VARIANT := 4 ports
> - DEVICE_DTS := armada-xp-openblocks-ax3-4
> + SOC := armada-xp
>SUPPORTED_DEVICES += openblocks-ax3-4
>BLOCKSIZE := 128k
>PAGESIZE := 1
> @@ -193,7 +193,7 @@ define Device/globalscale_mirabox
>$(Device/NAND-512K)
>DEVICE_VENDOR := Globalscale
>DEVICE_MODEL := Mirabox
> - DEVICE_DTS := armada-370-mirabox
> + SOC := armada-370
>SUPPORTED_DEVICES += mirabox
> endef
> TARGET_DEVICES += globalscale_mirabox
> @@ -212,7 +212,7 @@ define Device/cznic_turris-omnia
>IMAGE/$$(IMAGE_PREFIX)-sysupgrade.img.gz := boot-img | sdcard-img | gzip |
> append-metadata
>
Re: [OpenWrt-Devel] [PATCH] mvebu: split base-files across subtargets
W dniu 18.01.2020 o 02:21, Adrian Schmutzler pisze:
> For the mvebu target in particular, there is a lot of files in
> base-files that are only relevant for one subtarget. Improve
> overview and reduce size per subtarget by moving/splitting
> base-files depending on the subtarget they belong to.
>
> While at it, consolidate 01_leds by using the model part of
> the board name as variable.
>
> Signed-off-by: Adrian Schmutzler
Acked-by: Tomasz Maciej Nowak
> ---
> .../mvebu/base-files/etc/board.d/01_leds | 55 -
> .../mvebu/base-files/lib/upgrade/platform.sh | 52
> .../base-files/etc/board.d/02_network | 31 ++
> .../base-files/lib/preinit/82_uDPU| 0
> .../base-files/lib/upgrade/platform.sh| 52
> .../base-files/lib/upgrade/uDPU.sh| 0
> .../base-files/etc/board.d/02_network | 30 ++
> .../base-files/lib/upgrade/platform.sh| 37
> .../cortexa9/base-files/etc/board.d/01_leds | 40 +
> .../base-files/etc/board.d/02_network | 24 +---
> .../base-files/etc/init.d/bootcount | 0
> .../base-files/etc/uci-defaults/03_wireless | 0
> .../base-files/etc/uci-defaults/04_mambafan | 0
> .../base-files/lib/preinit/06_set_iface_mac | 0
> .../base-files/lib/preinit/81_linksys_syscfg | 0
> .../base-files/lib/upgrade/linksys.sh | 0
> .../base-files/lib/upgrade/platform.sh| 59 +++
> 17 files changed, 251 insertions(+), 129 deletions(-)
> delete mode 100755 target/linux/mvebu/base-files/etc/board.d/01_leds
> delete mode 100755 target/linux/mvebu/base-files/lib/upgrade/platform.sh
> create mode 100755
> target/linux/mvebu/cortexa53/base-files/etc/board.d/02_network
> rename target/linux/mvebu/{ => cortexa53}/base-files/lib/preinit/82_uDPU
> (100%)
> create mode 100755
> target/linux/mvebu/cortexa53/base-files/lib/upgrade/platform.sh
> rename target/linux/mvebu/{ => cortexa53}/base-files/lib/upgrade/uDPU.sh
> (100%)
> create mode 100755
> target/linux/mvebu/cortexa72/base-files/etc/board.d/02_network
> create mode 100755
> target/linux/mvebu/cortexa72/base-files/lib/upgrade/platform.sh
> create mode 100755 target/linux/mvebu/cortexa9/base-files/etc/board.d/01_leds
> rename target/linux/mvebu/{ => cortexa9}/base-files/etc/board.d/02_network
> (66%)
> rename target/linux/mvebu/{ => cortexa9}/base-files/etc/init.d/bootcount
> (100%)
> rename target/linux/mvebu/{ =>
> cortexa9}/base-files/etc/uci-defaults/03_wireless (100%)
> rename target/linux/mvebu/{ =>
> cortexa9}/base-files/etc/uci-defaults/04_mambafan (100%)
> rename target/linux/mvebu/{ =>
> cortexa9}/base-files/lib/preinit/06_set_iface_mac (100%)
> rename target/linux/mvebu/{ =>
> cortexa9}/base-files/lib/preinit/81_linksys_syscfg (100%)
> rename target/linux/mvebu/{ => cortexa9}/base-files/lib/upgrade/linksys.sh
> (100%)
> create mode 100755
> target/linux/mvebu/cortexa9/base-files/lib/upgrade/platform.sh
>
> diff --git a/target/linux/mvebu/base-files/etc/board.d/01_leds
> b/target/linux/mvebu/base-files/etc/board.d/01_leds
> deleted file mode 100755
> index 14313ee664..00
> --- a/target/linux/mvebu/base-files/etc/board.d/01_leds
> +++ /dev/null
> @@ -1,55 +0,0 @@
> -#!/bin/sh
> -#
> -# Copyright (C) 2014-2016 OpenWrt.org
> -# Copyright (C) 2016 LEDE-Project.org
> -#
> -
> -. /lib/functions/uci-defaults.sh
> -
> -board_config_update
> -
> -board=$(board_name)
> -
> -case "$board" in
> -linksys,caiman)
> - ucidef_set_led_netdev "wan" "WAN" "pca963x:caiman:white:wan" "eth1"
> - ucidef_set_led_usbport "usb1" "USB 1" "pca963x:caiman:white:usb2"
> "usb1-port1"
> - ucidef_set_led_usbport "usb2" "USB 2" "pca963x:caiman:white:usb3_1"
> "usb2-port1" "usb3-port1"
> - ucidef_set_led_usbport "usb2_ss" "USB 2 SS"
> "pca963x:caiman:white:usb3_2" "usb3-port1"
> - ;;
> -linksys,cobra)
> - ucidef_set_led_netdev "wan" "WAN" "pca963x:cobra:white:wan" "eth1"
> - ucidef_set_led_usbport "usb1" "USB 1" "pca963x:cobra:white:usb2"
> "usb1-port1"
> - ucidef_set_led_usbport "usb2" "USB 2" "pca963x:cobra:white:usb3_1"
> "usb2-port1" "usb3-port1"
> - ucidef_set_led_usbport "usb2_ss" "USB 2 SS"
> "pca963x:cobra:white:usb3_2" "usb3-port1"
> - ;;
> -linksys,mamba)
> - ucidef_set_led_netdev "wan" "WAN" "mamba:white:wan" "eth1"
> - ucidef_set_led_usbport "usb1" "USB 1" "mamba:white:usb2" "usb1-port1"
> - ucidef_set_led_usbport "usb2" "USB 2" "mamba:white:usb3_1" "usb2-port1"
> "usb3-port1"
> - ucidef_set_led_usbport "usb2_ss" "USB 2 SS" "mamba:white:usb3_2"
> "usb3-port2"
> - ;;
> -linksys,rango)
> - ucidef_set_led_netdev "wan" "WAN" "pca963x:rango:white:wan" "eth1"
> - ucidef_set_led_usbport "usb1" "USB 1" "pca963x:rango:white:usb2"
> "usb1-port1"
> - ucidef_set_led_usbport "usb2" "USB 2" "pca963x:rango:white:usb3_1"
> "usb2-port1" "usb3-port1"
> -
Re: [OpenWrt-Devel] [PATCH 1/2] mvebu: move subtarget image Makefile switch to parent Makefile
W dniu 18.01.2020 o 02:21, Adrian Schmutzler pisze: > This moves the if conditions for choosing which image Makefiles > are used to the parent image/Makefile. It seems more convenient > to have "codeflow" in the parent while the subtarget-specific > files only contain the definitions. > > Signed-off-by: Adrian Schmutzler Acked-by: Tomasz Maciej Nowak > --- > target/linux/mvebu/image/Makefile | 8 > target/linux/mvebu/image/cortex-a53.mk | 4 > target/linux/mvebu/image/cortex-a72.mk | 4 > target/linux/mvebu/image/cortex-a9.mk | 4 > 4 files changed, 8 insertions(+), 12 deletions(-) > > diff --git a/target/linux/mvebu/image/Makefile > b/target/linux/mvebu/image/Makefile > index ce1344a547..6dd7bde7ae 100644 > --- a/target/linux/mvebu/image/Makefile > +++ b/target/linux/mvebu/image/Makefile > @@ -116,8 +116,16 @@ define Device/NAND-512K >PAGESIZE := 4096 > endef > > +ifeq ($(SUBTARGET),cortexa9) > include cortex-a9.mk > +endif > + > +ifeq ($(SUBTARGET),cortexa53) > include cortex-a53.mk > +endif > + > +ifeq ($(SUBTARGET),cortexa72) > include cortex-a72.mk > +endif > > $(eval $(call BuildImage)) > diff --git a/target/linux/mvebu/image/cortex-a53.mk > b/target/linux/mvebu/image/cortex-a53.mk > index f5313429af..e58a3c42b9 100644 > --- a/target/linux/mvebu/image/cortex-a53.mk > +++ b/target/linux/mvebu/image/cortex-a53.mk > @@ -1,5 +1,3 @@ > -ifeq ($(SUBTARGET),cortexa53) > - > define Device/globalscale_espressobin >$(call Device/Default-arm64) >DEVICE_VENDOR := Marvell > @@ -73,5 +71,3 @@ define Device/methode_udpu >BOOT_SCRIPT := udpu > endef > TARGET_DEVICES += methode_udpu > - > -endif > diff --git a/target/linux/mvebu/image/cortex-a72.mk > b/target/linux/mvebu/image/cortex-a72.mk > index 5e619804e8..6abee2d8b9 100644 > --- a/target/linux/mvebu/image/cortex-a72.mk > +++ b/target/linux/mvebu/image/cortex-a72.mk > @@ -1,5 +1,3 @@ > -ifeq ($(SUBTARGET),cortexa72) > - > define Device/marvell_macchiatobin >$(call Device/Default-arm64) >DEVICE_VENDOR := SolidRun > @@ -29,5 +27,3 @@ define Device/marvell_armada7040-db >IMAGE/sdcard.img.gz := boot-img-ext4 | sdcard-img-ext4 | gzip | > append-metadata > endef > TARGET_DEVICES += marvell_armada7040-db > - > -endif > diff --git a/target/linux/mvebu/image/cortex-a9.mk > b/target/linux/mvebu/image/cortex-a9.mk > index c2ada75c2d..389082e426 100644 > --- a/target/linux/mvebu/image/cortex-a9.mk > +++ b/target/linux/mvebu/image/cortex-a9.mk > @@ -6,8 +6,6 @@ > # See /LICENSE for more information. > # > > -ifeq ($(SUBTARGET),cortexa9) > - > define Device/linksys >$(Device/NAND-128K) >DEVICE_VENDOR := Linksys > @@ -218,5 +216,3 @@ define Device/cznic_turris-omnia >SUPPORTED_DEVICES += armada-385-turris-omnia > endef > TARGET_DEVICES += cznic_turris-omnia > - > -endif > -- TMN ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2] kernel: replace SUBDIRS with M in package recipes
The SUBDIRS variable has been removed in kernel 5.4, and was deprecated since the beginnig of kernel git history in favour of M or KBUILD_EXTMOD. Signed-off-by: Tomasz Maciej Nowak --- v1 -> v2 fix commit title package/kernel/acx-mac80211/Makefile| 2 +- package/kernel/ath10k-ct/Makefile | 2 +- package/kernel/broadcom-wl/Makefile | 8 package/kernel/button-hotplug/Makefile | 2 +- package/kernel/gpio-button-hotplug/Makefile | 2 +- package/kernel/gpio-nct5104d/Makefile | 2 +- package/kernel/hwmon-gsc/Makefile | 2 +- package/kernel/i2c-gpio-custom/Makefile | 2 +- package/kernel/kmod-sched-cake/Makefile | 2 +- package/kernel/leds-apu2/Makefile | 2 +- package/kernel/mt76/Makefile| 2 +- package/kernel/mwlwifi/Makefile | 2 +- package/kernel/nat46/Makefile | 2 +- package/kernel/rtc-rv5c386a/Makefile| 2 +- package/kernel/rtl8812au-ct/Makefile| 2 +- package/kernel/spi-gpio-custom/Makefile | 2 +- package/kernel/trelay/Makefile | 2 +- package/kernel/w1-gpio-custom/Makefile | 2 +- 18 files changed, 21 insertions(+), 21 deletions(-) diff --git a/package/kernel/acx-mac80211/Makefile b/package/kernel/acx-mac80211/Makefile index 195802f5f5..a04b9e28ba 100644 --- a/package/kernel/acx-mac80211/Makefile +++ b/package/kernel/acx-mac80211/Makefile @@ -181,7 +181,7 @@ PKG_EXTRA_CFLAGS:= \ define Build/Compile $(MAKE) -C "$(LINUX_DIR)" \ $(KERNEL_MAKE_FLAGS) \ - SUBDIRS="$(PKG_BUILD_DIR)" \ + M="$(PKG_BUILD_DIR)" \ $(PKG_EXTRA_KCONFIG) \ EXTRA_CFLAGS="$(PKG_EXTRA_CFLAGS) -DCONFIG_ACX_MAC80211_VERSION=\"KERNEL_VERSION(4,2,0)\"" \ LINUXINCLUDE="-I$(STAGING_DIR)/usr/include/mac80211-backport/uapi -I$(STAGING_DIR)/usr/include/mac80211-backport \ diff --git a/package/kernel/ath10k-ct/Makefile b/package/kernel/ath10k-ct/Makefile index c29d28f41a..c2f383862c 100644 --- a/package/kernel/ath10k-ct/Makefile +++ b/package/kernel/ath10k-ct/Makefile @@ -112,7 +112,7 @@ endif define Build/Compile +$(MAKE) $(CT_MAKEDEFS) $(PKG_JOBS) -C "$(LINUX_DIR)" \ $(KERNEL_MAKE_FLAGS) \ - SUBDIRS="$(PKG_BUILD_DIR)/ath10k$(CT_KVER)" \ + M="$(PKG_BUILD_DIR)/ath10k$(CT_KVER)" \ NOSTDINC_FLAGS="$(NOSTDINC_FLAGS)" \ modules endef diff --git a/package/kernel/broadcom-wl/Makefile b/package/kernel/broadcom-wl/Makefile index 140107df17..9e91cfea20 100644 --- a/package/kernel/broadcom-wl/Makefile +++ b/package/kernel/broadcom-wl/Makefile @@ -102,7 +102,7 @@ endef MAKE_KMOD := $(MAKE) -C "$(LINUX_DIR)" \ $(KERNEL_MAKE_FLAGS) \ PATH="$(TARGET_PATH)" \ - SUBDIRS="$(PKG_BUILD_DIR)/kmod" \ + M="$(PKG_BUILD_DIR)/kmod" \ define Build/Prepare $(call Build/Prepare/Default) @@ -113,18 +113,18 @@ endef define Build/Compile # Compile glue driver $(MAKE_KMOD) -C "$(LINUX_DIR)" \ - SUBDIRS="$(PKG_BUILD_DIR)/glue" \ + M="$(PKG_BUILD_DIR)/glue" \ modules # Compile the kernel part $(MAKE_KMOD) \ - SUBDIRS="$(PKG_BUILD_DIR)/driver" \ + M="$(PKG_BUILD_DIR)/driver" \ MODFLAGS="-DMODULE -mlong-calls" \ KBUILD_EXTRA_SYMBOLS="$(PKG_BUILD_DIR)/glue/Module.symvers" \ modules $(MAKE_KMOD) \ - SUBDIRS="$(PKG_BUILD_DIR)/driver-mini" \ + M="$(PKG_BUILD_DIR)/driver-mini" \ MODFLAGS="-DMODULE -mlong-calls" \ BUILD_TYPE="wl_apsta_mini" \ KBUILD_EXTRA_SYMBOLS="$(PKG_BUILD_DIR)/glue/Module.symvers" \ diff --git a/package/kernel/button-hotplug/Makefile b/package/kernel/button-hotplug/Makefile index 2554ae61dd..55412e5685 100644 --- a/package/kernel/button-hotplug/Makefile +++ b/package/kernel/button-hotplug/Makefile @@ -37,7 +37,7 @@ EXTRA_CFLAGS:= \ MAKE_OPTS:= \ $(KERNEL_MAKE_FLAGS) \ - SUBDIRS="$(PKG_BUILD_DIR)" \ + M="$(PKG_BUILD_DIR)" \ EXTRA_CFLAGS="$(EXTRA_CFLAGS)" \ $(EXTRA_KCONFIG) diff --git a/package/kernel/gpio-button-hotplug/Makefile b/package/kernel/gpio-button-hotplug/Makefile index ffbc19756c..09f9c00e99 100644 --- a/package/kernel/gpio-button-hotplug/Makefile +++ b/package/kernel/gpio-button-hotplug/Makefile @@ -34,7 +34,7 @@ endef MAKE_OPTS:= \ $(KERNEL_MAKE_FLAGS) \ - SUBDIRS="$(PKG_BUILD_DIR)" + M="$(PKG_BUILD_DIR)" define Build/Compile $(MAKE) -C "$(LINUX_DIR)" \ diff --git a/package/kernel/gpio-nct5104d/Makefile b/package/kernel/gpio-nct5104d/Makefile index 33352388cf..e85639c94a 100644 --- a/package/kernel/gpio-nct5104d/Makefile +++ b/package/kernel/gpio-nct5104d/Makefile @@ -38,7 +38,7 @@ EXTRA_CFLAGS:= \ MAKE_OPTS:= \
[OpenWrt-Devel] [PATCH] kernel: replace SUBDIRS wih M in package recipes
The SUBDIRS variable has been removed in kernel 5.4, and was deprecated since the beginnig of kernel git history in favour of M or KBUILD_EXTMOD. Signed-off-by: Tomasz Maciej Nowak --- package/kernel/acx-mac80211/Makefile| 2 +- package/kernel/ath10k-ct/Makefile | 2 +- package/kernel/broadcom-wl/Makefile | 8 package/kernel/button-hotplug/Makefile | 2 +- package/kernel/gpio-button-hotplug/Makefile | 2 +- package/kernel/gpio-nct5104d/Makefile | 2 +- package/kernel/hwmon-gsc/Makefile | 2 +- package/kernel/i2c-gpio-custom/Makefile | 2 +- package/kernel/kmod-sched-cake/Makefile | 2 +- package/kernel/leds-apu2/Makefile | 2 +- package/kernel/mt76/Makefile| 2 +- package/kernel/mwlwifi/Makefile | 2 +- package/kernel/nat46/Makefile | 2 +- package/kernel/rtc-rv5c386a/Makefile| 2 +- package/kernel/rtl8812au-ct/Makefile| 2 +- package/kernel/spi-gpio-custom/Makefile | 2 +- package/kernel/trelay/Makefile | 2 +- package/kernel/w1-gpio-custom/Makefile | 2 +- 18 files changed, 21 insertions(+), 21 deletions(-) diff --git a/package/kernel/acx-mac80211/Makefile b/package/kernel/acx-mac80211/Makefile index 195802f5f5..a04b9e28ba 100644 --- a/package/kernel/acx-mac80211/Makefile +++ b/package/kernel/acx-mac80211/Makefile @@ -181,7 +181,7 @@ PKG_EXTRA_CFLAGS:= \ define Build/Compile $(MAKE) -C "$(LINUX_DIR)" \ $(KERNEL_MAKE_FLAGS) \ - SUBDIRS="$(PKG_BUILD_DIR)" \ + M="$(PKG_BUILD_DIR)" \ $(PKG_EXTRA_KCONFIG) \ EXTRA_CFLAGS="$(PKG_EXTRA_CFLAGS) -DCONFIG_ACX_MAC80211_VERSION=\"KERNEL_VERSION(4,2,0)\"" \ LINUXINCLUDE="-I$(STAGING_DIR)/usr/include/mac80211-backport/uapi -I$(STAGING_DIR)/usr/include/mac80211-backport \ diff --git a/package/kernel/ath10k-ct/Makefile b/package/kernel/ath10k-ct/Makefile index c29d28f41a..c2f383862c 100644 --- a/package/kernel/ath10k-ct/Makefile +++ b/package/kernel/ath10k-ct/Makefile @@ -112,7 +112,7 @@ endif define Build/Compile +$(MAKE) $(CT_MAKEDEFS) $(PKG_JOBS) -C "$(LINUX_DIR)" \ $(KERNEL_MAKE_FLAGS) \ - SUBDIRS="$(PKG_BUILD_DIR)/ath10k$(CT_KVER)" \ + M="$(PKG_BUILD_DIR)/ath10k$(CT_KVER)" \ NOSTDINC_FLAGS="$(NOSTDINC_FLAGS)" \ modules endef diff --git a/package/kernel/broadcom-wl/Makefile b/package/kernel/broadcom-wl/Makefile index 140107df17..9e91cfea20 100644 --- a/package/kernel/broadcom-wl/Makefile +++ b/package/kernel/broadcom-wl/Makefile @@ -102,7 +102,7 @@ endef MAKE_KMOD := $(MAKE) -C "$(LINUX_DIR)" \ $(KERNEL_MAKE_FLAGS) \ PATH="$(TARGET_PATH)" \ - SUBDIRS="$(PKG_BUILD_DIR)/kmod" \ + M="$(PKG_BUILD_DIR)/kmod" \ define Build/Prepare $(call Build/Prepare/Default) @@ -113,18 +113,18 @@ endef define Build/Compile # Compile glue driver $(MAKE_KMOD) -C "$(LINUX_DIR)" \ - SUBDIRS="$(PKG_BUILD_DIR)/glue" \ + M="$(PKG_BUILD_DIR)/glue" \ modules # Compile the kernel part $(MAKE_KMOD) \ - SUBDIRS="$(PKG_BUILD_DIR)/driver" \ + M="$(PKG_BUILD_DIR)/driver" \ MODFLAGS="-DMODULE -mlong-calls" \ KBUILD_EXTRA_SYMBOLS="$(PKG_BUILD_DIR)/glue/Module.symvers" \ modules $(MAKE_KMOD) \ - SUBDIRS="$(PKG_BUILD_DIR)/driver-mini" \ + M="$(PKG_BUILD_DIR)/driver-mini" \ MODFLAGS="-DMODULE -mlong-calls" \ BUILD_TYPE="wl_apsta_mini" \ KBUILD_EXTRA_SYMBOLS="$(PKG_BUILD_DIR)/glue/Module.symvers" \ diff --git a/package/kernel/button-hotplug/Makefile b/package/kernel/button-hotplug/Makefile index 2554ae61dd..55412e5685 100644 --- a/package/kernel/button-hotplug/Makefile +++ b/package/kernel/button-hotplug/Makefile @@ -37,7 +37,7 @@ EXTRA_CFLAGS:= \ MAKE_OPTS:= \ $(KERNEL_MAKE_FLAGS) \ - SUBDIRS="$(PKG_BUILD_DIR)" \ + M="$(PKG_BUILD_DIR)" \ EXTRA_CFLAGS="$(EXTRA_CFLAGS)" \ $(EXTRA_KCONFIG) diff --git a/package/kernel/gpio-button-hotplug/Makefile b/package/kernel/gpio-button-hotplug/Makefile index ffbc19756c..09f9c00e99 100644 --- a/package/kernel/gpio-button-hotplug/Makefile +++ b/package/kernel/gpio-button-hotplug/Makefile @@ -34,7 +34,7 @@ endef MAKE_OPTS:= \ $(KERNEL_MAKE_FLAGS) \ - SUBDIRS="$(PKG_BUILD_DIR)" + M="$(PKG_BUILD_DIR)" define Build/Compile $(MAKE) -C "$(LINUX_DIR)" \ diff --git a/package/kernel/gpio-nct5104d/Makefile b/package/kernel/gpio-nct5104d/Makefile index 33352388cf..e85639c94a 100644 --- a/package/kernel/gpio-nct5104d/Makefile +++ b/package/kernel/gpio-nct5104d/Makefile @@ -38,7 +38,7 @@ EXTRA_CFLAGS:= \ MAKE_OPTS:= \ $(KERNEL_MAKE_FLAGS) \ -
Re: [OpenWrt-Devel] Lantiq xrx200: PTM issues
Update: I've found out now that the ENOBUFS is set by __ip_append_data, because sk_wmem_alloc "overflows". Martin On 2020-01-20 07:09, Martin Schiller wrote: Hi! I have discovered the following problem: If you have established a PPPoE session via VDSL / PTM connection incl. VLAN tagging and send data with a relatively small send buffer (SO_SNDBUF), then an ENOBUFS always comes back. We first noticed this with stagnating data transfers over an OpenVPN connection. Also with iputils-ping, since by default the send buffer is relatively small. You can also force this with busybox ping by using echo "5000"> / proc / sys / net / core / wmem_default minimizes the system default value. Then you send pings with a packet size of e.g. 4000 bytes and the second package is already in the pants: root @ OpenWrt: ~ # ping -s4000 10.200.1.142 PING 10.200.1.142 (10.200.1.142): 4000 data bytes 4008 bytes from 10.200.1.142: seq = 0 ttl = 63 time = 20.519 ms ping: sendto: No buffer space available root @ OpenWrt: ~ # So it should be easily reproducible for everyone. Traffic that is only routed through the router is not affected. The manpage of sendto says: --- ENOBUFS The output queue for a network interface was full. This generally indicates that the interface has stopped sending, but may be caused by transient congestion. (Normally, this does not occur in Linux. Packets are just silently dropped when a device queue overflows.) --- But all former packets have already been transmitted. This issue seems to be in there since lede-17.01. I can't reproduce it with owrt-15.05. Does anyone have any idea how to solve the problem? Martin ___ 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-Devel] [RFC] commit message in YAML format for new devices
Hi all, I looked a bit into parsing the DeviceTree files but it's a bit of a pain. Tools like dts2yaml and dtc exists, however the output is not really useful: A lot of auto detection prevents the parser from knowing flash & storage sizes or number of USB ports. Therefore I decided to create a simple shell script to get all relevant information. I'd add it to ./scripts/, maybe there is a simple way with Makefile integration as well like Petr suggested. Next mail will contain some patch. If anybody wants to continue the DeviceTree approach, dts2yaml creates links pointing to files outside the OpenWrt sources, meaning the Python YAML libs fails to read it due to missing anchors. Converting dtb files via dtc works however, just be aware that you have to convert it from dtb to dts first and in a second run from dts to yaml. Single step is not supported. Best, Paul On 1/13/20 3:03 AM, Thomas Endt wrote: -Ursprüngliche Nachricht- Von: openwrt-devel Im Auftrag von Paul Spooren Gesendet: Sonntag, 12. Januar 2020 22:47 An: 'OpenWrt Development List' Betreff: [OpenWrt-Devel] [RFC] commit message in YAML format for new devices An illustrative commit therefore: soc: Qualcomm IPQ4029 ram_mb: 512 flash: If there is manual user input, you need to validate and normalize the input data. Example: - soc: Qualcomm IPQ4029 - soc: IPQ4029 - soc: qUaLcOmMm IPQ4029 We want uniform naming and spelling. If all this is created via script, ok, no problem, the script can handle that. If you want users to deliver acceptable yaml files, you should create a "yaml-generator" where you can easily chose in dropdown lists which SoC, what RAM chip, . The current dataentries do already have dropdowns for several features, however, SoC + Wireless hardware are freetext, no dropdowns. Having that automated would be a gain. Regards, Thomas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH][libubox] blobmsg: blobmsg_parse and blobmsg_parse_array oob read fixes
Juraj Vijtiuk [2020-01-14 22:11:18]:
Hi,
I just sent v2 for review[2], can you check it please?
> > > @@ -191,7 +197,11 @@ int blobmsg_parse(const struct blobmsg_policy
> > > *policy, int policy_len,
> > > }
> > >
> > > __blob_for_each_attr(attr, data, len) {
> > > + if (len < sizeof(struct blob_attr) + sizeof(struct
> > > blobmsg_hdr))
> > > + return -1;
> >
> > If there is such problem, then this should be probably fixed directly in
> > __blob_for_each_attr so we possibly protect other __blob_for_each_attr
> > users[1].
>
> Can you maybe provide a patch? I'd be happy to test it and let you
> know what the results are.
Seems like I need more time on this, to come up with some meaningful solution
(it's blob related function, but it would need to check blobmsg etc.), I've
just prepared some common helper functions which should help. I don't want to
block this changes just because of that. I'll try to add you to the Cc: in
that follow up patch.
1. https://patchwork.ozlabs.org/patch/1225878/
-- ynezz
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH libubox v2] blobmsg: blobmsg_parse and blobmsg_parse_array oob read fixes
From: Juraj Vijtiuk
Fix out of bounds read in blobmsg_parse and blobmsg_check_name. The
out of bounds read happens because blob_attr and blobmsg_hdr have
flexible array members, whose size is 0 in the corresponding sizeofs.
For example the __blob_for_each_attr macro checks whether rem >=
sizeof(struct blob_attr). However, what LibFuzzer discovered was,
if the input data was only 4 bytes, the data would be casted to blob_attr,
and later on blob_data(attr) would be called even though attr->data was empty.
The same issue could appear with data larger than 4 bytes, where data
wasn't empty, but contained only the start of the blobmsg_hdr struct,
and blobmsg_hdr name was empty. The bugs were discovered by fuzzing
blobmsg_parse and blobmsg_array_parse with LibFuzzer.
CC: Luka Perkov
Signed-off-by: Juraj Vijtiuk
[fixed from, refactored some checks, added fuzz inputs, updated test results]
Signed-off-by: Petr Štetiar
---
blobmsg.c | 40 ++
tests/cram/test_blob_parse.t | 4 ++
tests/cram/test_blobmsg_parse.t | 32 --
...h-a3585b70f1c7ffbdec10f6dadc964336118485c4 | Bin 0 -> 4 bytes
...h-b3585b70f1c7ffbdec10f6dadc964336118485c4 | Bin 0 -> 6 bytes
5 files changed, 56 insertions(+), 20 deletions(-)
create mode 100644
tests/fuzz/corpus/crash-a3585b70f1c7ffbdec10f6dadc964336118485c4
create mode 100644
tests/fuzz/corpus/crash-b3585b70f1c7ffbdec10f6dadc964336118485c4
diff --git a/blobmsg.c b/blobmsg.c
index 3e34821cc928..762078436f9b 100644
--- a/blobmsg.c
+++ b/blobmsg.c
@@ -30,16 +30,38 @@ bool blobmsg_check_attr(const struct blob_attr *attr, bool
name)
return blobmsg_check_attr_len(attr, name, blob_raw_len(attr));
}
+static const struct blobmsg_hdr* blobmsg_hdr_from_blob(const struct blob_attr
*attr, size_t len)
+{
+ if (len < sizeof(struct blob_attr) + sizeof(struct blobmsg_hdr))
+ return NULL;
+
+ return blob_data(attr);
+}
+
+static bool blobmsg_hdr_valid_namelen(const struct blobmsg_hdr *hdr, size_t
len)
+{
+ if (len < sizeof(struct blob_attr) + sizeof(struct blobmsg_hdr) +
blobmsg_namelen(hdr) + 1)
+ return false;
+
+ return true;
+}
+
static bool blobmsg_check_name(const struct blob_attr *attr, size_t len, bool
name)
{
char *limit = (char *) attr + len;
const struct blobmsg_hdr *hdr;
- hdr = blob_data(attr);
+ hdr = blobmsg_hdr_from_blob(attr, len);
+ if (!hdr)
+ return false;
+
if (name && !hdr->namelen)
return false;
- if ((char *) hdr->name + blobmsg_namelen(hdr) > limit)
+ if (name && !blobmsg_hdr_valid_namelen(hdr, len))
+ return false;
+
+ if ((char *) hdr->name + blobmsg_namelen(hdr) + 1 > limit)
return false;
if (blobmsg_namelen(hdr) > (blob_len(attr) - sizeof(struct
blobmsg_hdr)))
@@ -73,9 +95,6 @@ bool blobmsg_check_attr_len(const struct blob_attr *attr,
bool name, size_t len)
size_t data_len;
int id;
- if (len < sizeof(struct blob_attr))
- return false;
-
if (!blobmsg_check_name(attr, len, name))
return false;
@@ -170,11 +189,10 @@ int blobmsg_parse_array(const struct blobmsg_policy
*policy, int policy_len,
return 0;
}
-
int blobmsg_parse(const struct blobmsg_policy *policy, int policy_len,
struct blob_attr **tb, void *data, unsigned int len)
{
- struct blobmsg_hdr *hdr;
+ const struct blobmsg_hdr *hdr;
struct blob_attr *attr;
uint8_t *pslen;
int i;
@@ -191,7 +209,13 @@ int blobmsg_parse(const struct blobmsg_policy *policy, int
policy_len,
}
__blob_for_each_attr(attr, data, len) {
- hdr = blob_data(attr);
+ hdr = blobmsg_hdr_from_blob(attr, len);
+ if (!hdr)
+ return -1;
+
+ if (!blobmsg_hdr_valid_namelen(hdr, len))
+ return -1;
+
for (i = 0; i < policy_len; i++) {
if (!policy[i].name)
continue;
diff --git a/tests/cram/test_blob_parse.t b/tests/cram/test_blob_parse.t
index 1fd60bc71122..b6cbbaa811b7 100644
--- a/tests/cram/test_blob_parse.t
+++ b/tests/cram/test_blob_parse.t
@@ -68,6 +68,10 @@ check that blob_parse is producing expected results:
cannot parse cert crash-813f3e68661da09c26d4a87dbb9d5099e92be50f
cannot parse cert crash-98595faa58ba01d85ba4fd0b109cd3d490b45795
cannot parse cert crash-98595faa58ba01d85ba4fd0b109cd3d490b45795
+ cannot parse cert crash-a3585b70f1c7ffbdec10f6dadc964336118485c4
+ cannot parse cert crash-a3585b70f1c7ffbdec10f6dadc964336118485c4
+ cannot parse cert crash-b3585b70f1c7ffbdec10f6dadc964336118485c4
+ cannot parse cert crash-b3585b70f1c7ffbdec10f6dadc964336118485c4
cannot parse cert
[OpenWrt-Devel] [PATCH] procd: show process's exit code
From: Ondřej Votava
Adds feature to show process's exit code when
ubus service list is called.
Signed-off-by: Ondřej Votava
---
service/instance.c | 12
service/instance.h | 1 +
2 files changed, 13 insertions(+)
diff --git a/service/instance.c b/service/instance.c
index abd1f34..c360343 100644
--- a/service/instance.c
+++ b/service/instance.c
@@ -574,6 +574,15 @@ instance_exit(struct uloop_process *p, int ret)
DEBUG(2, "Instance %s::%s exit with error code %d after %ld seconds\n",
in->srv->name, in->name, ret, runtime);
+ /*
+ According to man waitpid(2) exit codes might be:
+ 0 -- everything is OK
+ SIGNALLED -- 1 - 64 - and since we want the same behavior as SHELL, we
add 128
+ @see http://tldp.org/LDP/abs/html/exitcodes.html
+ 256 - 65536 -- regular exit, strip the bottom byte with WEXITSTATUS
macro.
+ @see man waitpid(2)
+ */
+ in->exit_code = WIFEXITED(ret) ? WEXITSTATUS(ret) : WIFSIGNALED(ret) ?
128 + WTERMSIG(ret) : 1;
uloop_timeout_cancel(>timeout);
service_event("instance.stop", in->srv->name, in->name);
@@ -1091,6 +1100,7 @@ instance_init(struct service_instance *in, struct service
*s, struct blob_attr *
in->proc.cb = instance_exit;
in->term_timeout = 5;
in->syslog_facility = LOG_DAEMON;
+ in->exit_code = 0;
in->_stdout.fd.fd = -2;
in->_stdout.stream.string_data = true;
@@ -1124,6 +1134,8 @@ void instance_dump(struct blob_buf *b, struct
service_instance *in, int verbose)
if (in->command)
blobmsg_add_blob(b, in->command);
blobmsg_add_u32(b, "term_timeout", in->term_timeout);
+ if (!in->proc.pending)
+ blobmsg_add_u32(b, "exit_code", in->exit_code);
if (!avl_is_empty(>errors.avl)) {
struct blobmsg_list_node *var;
diff --git a/service/instance.h b/service/instance.h
index 42cc4be..05a2fc3 100644
--- a/service/instance.h
+++ b/service/instance.h
@@ -62,6 +62,7 @@ struct service_instance {
char *seccomp;
char *pidfile;
int syslog_facility;
+ int exit_code;
uint32_t term_timeout;
uint32_t respawn_timeout;
--
2.21.0 (Apple Git-122.2)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Releases [Was: Re: OpenWrt 20.X release plans]
On 20/01/20 10:01, Petr Štetiar wrote: Hauke Mehrtens [2020-01-19 18:17:10]: Hi, Does someone else other than jow know how to setup built bot for a new branch? Is this documented somewhere? It should be documented and at least 3 persons should be able (and willing) to do that. There is documentation on making new releases in the wiki/site (most instructions are in "tag new version" and "build release images") https://openwrt.org/docs/guide-developer/releases/release-process I don't know how correct it is, if someone of you core developers want to integrate it with better info, please do so. -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Releases [Was: Re: OpenWrt 20.X release plans]
Hauke Mehrtens [2020-01-19 18:17:10]: Hi, > Someone has to take care of the release and this person would then > announce that he wants to tag and build the next RC some days before so > that people can prepare. The person can change in the release process. Ok, fine with me, it should be written down (made clear), that the release timeline, number of RCs depends on the "release manager". This brings another topic to the table, how are we going to pickup the "release manager" if we can't find a volunteer? :-) Round-robin or random choice from the list of available (if needed to be) candidates? > Does someone else other than jow know how to setup built bot for a new > branch? Is this documented somewhere? It should be documented and at least 3 persons should be able (and willing) to do that. > From my point of view the delays were not caused by someone saying that > we should wait till something is fixed, but that nobody did the next > step and nothing happened. I was rather referencing delay between the branch and first RC. IIRC we've branched in the middle of the LuCI Lua refactoring (service side -> JS client), so waiting for LuCI getting into releasable state. Don't take me wrong, it's fine with me, we just should take such possible release blockers into the account in the future as well and either find a way of handling them or just live with the fact, that this delay migh resurface in the future again. > I would also only list the big problems you listed as real showstoppers, > but it would be nice if more people also get informed about the other > bugs too. I hope, that this is going to be improve with the defragmented tooling (FlySpray merged into something else). We can then have a release (or next RC) milestones, assigning issues as release blockers (done by the release manager only). > I added some support status to this wiki page: > https://openwrt.org/docs/guide-developer/security#support_status I hope this > is ok It makes it clear, explicit, so I like it. > I would prefer if we make separate votes at least for the topics which > are separate, you can start them at the same time, but I think it is > easier to have separate discussions. Ok, noted. -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
