Re: Using prebuilt binaries in SDK builds
Hey Peter - thanks for the follow up. >> When building a particular source package using the SDK, I need to rebuild >> any dependent packages from source as w > Perhaps an easy solution is to have a clean target variant that also > recursively cleans all the dependencies? I'm sorry, I'm not following. In this case, I'm looking for a way to save the artifacts that dependencies save in the staging_dir for future use, not to remove them. Am I missing something or did we misunderstand one another? Best Regards, Eric This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] bcm47xx: relocate LZMA loader #2
On 2/7/23 15:06, Rafał Miłecki wrote:
From: Rafał Miłecki
Increased size of the 5.15 kernel requires bumping BZ_TEXT_START again.
Without this CFE hangs at the:
Starting program at 0x80001000
This fixes booting 5.15 based mips74k images on:
1. BCM4706 (Luxul XWR-1750)
2. BCM5357B0 (Linksys E1000 V2.1)
3. BCM47186B0 (Luxul XWR-600)
It isn't needed but also doesn't break:
1. BCM5354 (Asus WL-500gP V2)
Ref: 4cd97e476089 ("bcm47xx: relocate LZMA loader")
Cc: Hauke Mehrtens
Signed-off-by: Rafał Miłecki
Acked-by: Hauke Mehrtens
Maybe we should increase this even more, then we do not have to change
this again next year.
Does setting BZ_TEXT_START to 0x80D0 also work?
I do not think this has any disadvantages.
---
target/linux/bcm47xx/image/lzma-loader/src/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/target/linux/bcm47xx/image/lzma-loader/src/Makefile
b/target/linux/bcm47xx/image/lzma-loader/src/Makefile
index a3e7ae1c92..44891a7ab0 100644
--- a/target/linux/bcm47xx/image/lzma-loader/src/Makefile
+++ b/target/linux/bcm47xx/image/lzma-loader/src/Makefile
@@ -18,8 +18,8 @@
#
TEXT_START := 0x80001000
-BZ_TEXT_START := 0x8070
-BZ_STACK_START := 0x8080
+BZ_TEXT_START := 0x8080
+BZ_STACK_START := 0x8090
OBJCOPY := $(CROSS_COMPILE)objcopy -O binary -R .reginfo -R .note -R .comment -R .mdebug -S
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] realtek: fix memory leak in netevent handler
The net_event_work struct is allocated, but only freed in a single case.
Move the allocation to the branch where it is actually needed, and free
it after the work has been done.
Fixes: 03e1d93e0779 ("realtek: add driver support for routing offload")
Signed-off-by: Jan Hoffmann
---
I noticed this issue due to increasing memory usage on a HPE 1920-16G.
While I haven't done any long-term testing with this patch yet, using
kmemleak on a HPE 1920-8G no longer shows any leaks in the realtek
drivers.
.../files-5.10/drivers/net/dsa/rtl83xx/common.c | 17 +
.../files-5.15/drivers/net/dsa/rtl83xx/common.c | 17 +
2 files changed, 18 insertions(+), 16 deletions(-)
diff --git a/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/common.c
b/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/common.c
index 15e6ed092696..d2d677230010 100644
--- a/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/common.c
+++ b/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/common.c
@@ -1286,6 +1286,8 @@ static void rtl83xx_net_event_work_do(struct work_struct
*work)
struct rtl838x_switch_priv *priv = net_work->priv;
rtl83xx_l3_nexthop_update(priv, net_work->gw_addr, net_work->mac);
+
+ kfree(net_work);
}
static int rtl83xx_netevent_event(struct notifier_block *this,
@@ -1299,13 +1301,6 @@ static int rtl83xx_netevent_event(struct notifier_block
*this,
priv = container_of(this, struct rtl838x_switch_priv, ne_nb);
- net_work = kzalloc(sizeof(*net_work), GFP_ATOMIC);
- if (!net_work)
- return NOTIFY_BAD;
-
- INIT_WORK(&net_work->work, rtl83xx_net_event_work_do);
- net_work->priv = priv;
-
switch (event) {
case NETEVENT_NEIGH_UPDATE:
if (n->tbl != &arp_tbl)
@@ -1314,10 +1309,16 @@ static int rtl83xx_netevent_event(struct notifier_block
*this,
port = rtl83xx_port_dev_lower_find(dev, priv);
if (port < 0 || !(n->nud_state & NUD_VALID)) {
pr_debug("%s: Neigbour invalid, not updating\n",
__func__);
- kfree(net_work);
return NOTIFY_DONE;
}
+ net_work = kzalloc(sizeof(*net_work), GFP_ATOMIC);
+ if (!net_work)
+ return NOTIFY_BAD;
+
+ INIT_WORK(&net_work->work, rtl83xx_net_event_work_do);
+ net_work->priv = priv;
+
net_work->mac = ether_addr_to_u64(n->ha);
net_work->gw_addr = *(__be32 *) n->primary_key;
diff --git a/target/linux/realtek/files-5.15/drivers/net/dsa/rtl83xx/common.c
b/target/linux/realtek/files-5.15/drivers/net/dsa/rtl83xx/common.c
index 1fa92ae220e0..3216d7eb835f 100644
--- a/target/linux/realtek/files-5.15/drivers/net/dsa/rtl83xx/common.c
+++ b/target/linux/realtek/files-5.15/drivers/net/dsa/rtl83xx/common.c
@@ -1282,6 +1282,8 @@ static void rtl83xx_net_event_work_do(struct work_struct
*work)
struct rtl838x_switch_priv *priv = net_work->priv;
rtl83xx_l3_nexthop_update(priv, net_work->gw_addr, net_work->mac);
+
+ kfree(net_work);
}
static int rtl83xx_netevent_event(struct notifier_block *this,
@@ -1295,13 +1297,6 @@ static int rtl83xx_netevent_event(struct notifier_block
*this,
priv = container_of(this, struct rtl838x_switch_priv, ne_nb);
- net_work = kzalloc(sizeof(*net_work), GFP_ATOMIC);
- if (!net_work)
- return NOTIFY_BAD;
-
- INIT_WORK(&net_work->work, rtl83xx_net_event_work_do);
- net_work->priv = priv;
-
switch (event) {
case NETEVENT_NEIGH_UPDATE:
if (n->tbl != &arp_tbl)
@@ -1310,10 +1305,16 @@ static int rtl83xx_netevent_event(struct notifier_block
*this,
port = rtl83xx_port_dev_lower_find(dev, priv);
if (port < 0 || !(n->nud_state & NUD_VALID)) {
pr_debug("%s: Neigbour invalid, not updating\n",
__func__);
- kfree(net_work);
return NOTIFY_DONE;
}
+ net_work = kzalloc(sizeof(*net_work), GFP_ATOMIC);
+ if (!net_work)
+ return NOTIFY_BAD;
+
+ INIT_WORK(&net_work->work, rtl83xx_net_event_work_do);
+ net_work->priv = priv;
+
net_work->mac = ether_addr_to_u64(n->ha);
net_work->gw_addr = *(__be32 *) n->primary_key;
--
2.39.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Using prebuilt binaries in SDK builds
On 2/7/23 18:35, Eric Montellese wrote: Hello all, As I'm sure those on this list are aware, OpenWrt is used extensively in the commercial router world. That would be an understatement, we do for one. At NETGEAR, I am working to find a satisfactory solution to an annoying little corporate problem -- but I think the solution to that problem may be of value to the greater open-source community. The situation is this: When building a particular source package using the SDK, I need to rebuild any dependent packages from source as w Perhaps an easy solution is to have a clean target variant that also recursively cleans all the dependencies? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ipq40xx: add PCIe magic hack to improve VRX518 compatibility
On Sun, 5 Feb 2023 at 01:10, Jan Hoffmann wrote: > > > Am 02.02.23 um 11:54 schrieb Robert Marko: > > On Tue, 31 Jan 2023 at 23:52, Jan Hoffmann wrote: > >> > >> Hi Robert, > >> > >> > >> On 2023-01-30 at 00:08, Robert Marko wrote: > >>> Shouldn't it be possible for the modem driver itself to be fixed > >>> instead of faking > >>> the PCI details? > >> > >> This hack is definitely far from ideal, but I'm not sure if there is a > >> better way to fix this. > >> > >> Here are a few more details about the issue: > >> > >> On the affected devices (so far, three users reported it on the VRX518 > >> thread in the forum [0]), the function call to turn on the "EMA" > >> hardware unit in the vrx518_tc driver [1] fails with the error mentioned > >> in the commit message. > >> > >> I don't have any details about it, but this EMA unit is part of the data > >> path (it is also referenced in the ltq-atm and ltq-ptm data path drivers > >> for older Lantiq modems). If the EMA unit is not running, then at least > >> the transmit data path doesn't work, and any packets the driver writes > >> to the TX ring are not actually sent out by the device. > >> > >> This is also reproducible on non-affected devices by calling tc_clkoff > >> instead of tc_clkon in the vrx518_tc driver (i.e. disabling the hardware > >> unit). The same issue also occurs on affected devices running vendor > >> firmware, if the "magic" in the PCIe driver is disabled in the device > >> tree. So this is not just a bug in the data path driver. > > > > I get the issue, however, I am failing to see how faking the PCI ID for the > > root adaptor is magically solving that? > > If that works, why can't you just patch the driver to stop looking for > > the ancient > > Lantiq ID? > > As far as I can see, the magic values don't appear anywhere in the DSL > drivers. So it doesn't seem like there is an easy fix like that. > > To me this looks like whatever access to these values is being done, > seems to happen in hardware (or firmware). Maybe there are some > revisions or variants of the modem that don't like to cooperate with > non-Lantiq SoCs. > > But in the end, I don't know with certainty what exactly is happening > here, as about the only public information on these modems are the > open-source drivers (including the magic hack in the PCIe driver which > in its original form contains comments like "do some magic" without > really explaining what it actually does). Ok, I am now getting the issue, it's probably in the damn firmware. I still really dont like the hack that we are gonna need to carry forever. I would like for somebody else to chime in as well. Regards, Robert > > Regards, > Jan > > > > > > Regards, > > Robert > >> > >> > >> Regards, > >> Jan > >> > >> > >>> > >>> Especially considering that now modem support is not self-contained > >>> and will require > >>> patching the DWC Qualcomm PCI driver forever. > >>> > >>> Regards, > >>> Robert > >> > >> > >> [0] > >> https://forum.openwrt.org/t/adding-support-for-vrx518-and-maybe-vrx320/55160 > >> [1] > >> https://gitlab.com/prpl-foundation/intel/vrx518_tc_drv/-/blob/ugw-8.5.2/dcdp/tc_main.c#L112 > > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: snapshots mvebu/cortexa9 possible regression in initramfs boot after acd8e94d20
Stijn Segers [2023-02-06 11:38:40]: Hi, > "Petr Štetiar" schreef op 6 februari 2023 11:26:35 CET: > >Hi, > > > >I've just noticed, that Omnia fails to boot latest initramfs snapshots[1]: > > > > ## Loading kernel from FIT Image at 0100 ... > > Using 'config-1' configuration > > Trying 'kernel-1' kernel subimage > > Description: ARM OpenWrt Linux-5.15.91 > > ...snip... > > Verifying Hash Integrity ... crc32+ sha1+ OK > > ## Loading fdt from FIT Image at 0100 ... > > Using 'config-1' configuration > > Trying 'fdt-1' fdt subimage > > Description: ARM OpenWrt cznic_turris-omnia device tree blob > > ...snip... > > Verifying Hash Integrity ... crc32+ sha1+ OK > > Booting using the fdt blob at 0x1543900 > > Uncompressing Kernel Image > > Loading Device Tree to 0fff8000, end 0dbe ... OK > > > > Starting kernel ... > > > >acd8e94d20 seems to be the last working revision[2], so 5.15.90 booted fine, > >5.15.91 didn't, so maybe thats the culprit? > > > FWIW, a backported 5.15.91 boots fine here on a WRT1200AC with 22.03. FYI I've reported issue with initramfs image as we don't flash devices during daily automatic runtime testing. Anyway it seems, that Georgi is observing similar symptomps on his device[1], so likely 8bc72ea7be3976 might be the real culprit here. 1. https://github.com/openwrt/openwrt/commit/8bc72ea7be3976711dacc09f0fdab061d6e5152a#commitcomment-99705611 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
