On Thursday, 2 May 2024 09:25:03 CEST Sven Eckelmann wrote:
> On Monday, 29 April 2024 15:36:47 CEST Sven Eckelmann wrote:
> > On Monday, 29 April 2024 15:14:18 CEST Kalle Valo wrote:
> > > It's quite strange that they updated 2.5.0.1 branch first but my
> > > unde
On Monday, 29 April 2024 15:36:47 CEST Sven Eckelmann wrote:
> On Monday, 29 April 2024 15:14:18 CEST Kalle Valo wrote:
> > It's quite strange that they updated 2.5.0.1 branch first but my
> > understanding that there should be updates for the newer 2.7.0.1 branch
> > as
branches. It seem like that would be
up to 2.9.0.x - no idea why there is no (public) 2.10.x/2.11.x for the AP
SoCs.
Kind regards,
Sven
signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
open
t Qualcomm - simply because it is
not just a single person and I have no idea about the internal structures. But
it doesn't seem to be the highest priority (for the "internal team"?) to make
fixes available for everyone. I still hope that it is just delayed due to some
unfortunate c
to change the daemon->ubus pointer because various
functions are already checking it for NULL. It is also the behavior which
ubus_destroy() implements.
Fixes: d8b33dad0bb7 ("dnsmasq: add support for monitoring and modifying dns
lookup results via ubus")
Signed-off-by: Sven Eckelmann
---
the daemon->ubus pointer to NULL because
various functions are already it for NULL. It is also the behavior which
ubus_destroy() implements.
Fixes: d8b33dad0bb7 ("dnsmasq: add support for monitoring and modifying dns
lookup results via ubus")
Signed-off-by: Sven Eckelmann
---
package/net
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:
ot;)
Fixes: 54b275c8ed3a ("ipq40xx: add target")
Signed-off-by: Sven Eckelmann
---
package/boot/uboot-envtools/files/ipq40xx | 1 +
package/boot/uboot-envtools/files/ipq806x | 1 +
2 files changed, 2 insertions(+)
diff --git a/package/boot/uboot-envtools/files/ipq40xx
b/package/boot/
On Wednesday, 29 June 2022 21:37:43 CEST Christian Marangi wrote:
> On Wed, Jun 29, 2022 at 09:32:14PM +0200, Sven Eckelmann wrote:
> > On Wednesday, 29 June 2022 18:33:53 CEST Christian Marangi wrote:
> > [...]
> > > A node name change is required for the new
0% if you reference here the mtdparts from cmdline or something
else. If the former is the case then please perform a
"git grep 'partitions are passed via bootloader'".
But I am currently not 100% sure why cmdline is so special here.
Kind regards,
Sven
signature.asc
Description:
-- a/target/linux/generic/files/drivers/platform/mikrotik/rb_softconfig.c
> +++ b/target/linux/generic/files/drivers/platform/mikrotik/rb_softconfig.c
> @@ -59,20 +59,9 @@
> #define RB_SOFTCONFIG_VER "0.03"
> #define RB_SC_PR_PFX "[rb_softc
In my case that will
be counterproductive, as I already include "lzo" for other purpose and having
to include "lzo-rle" too results in unwanted "memory bloat". That's why I
think the kernel should not insist on a specific compressor by default.
Sven
__
Am Mittwoch, 1. Dezember 2021, 12:47:57 CET schrieb Rui Salvaterra:
> Hi, Sven,
>
> [patch snipped]
>
> Why not just include the lzo-lre module in the lzo module package? We
> already agreed they're basically inseparable. In fact, I remember I
> had sent a patch [1] a whil
Am Montag, 29. November 2021, 10:57:37 CET schrieb Rui Salvaterra:
> Hi, Sven,
>
> On Sun, 28 Nov 2021 at 01:40, Sven Roederer wrote:
> > Rui, not sure if to call it a bug. At the end there is a hardcoded default
> > algo in the module, that is used initially whe
openwrt-devel/2020-September/031430.html
* 419f149e482641ddc520f80a7ab2038f7e2ebc8a
Signed-off-by: Sven Roederer
---
.../pending-5.4/801-zram_default-algo.patch | 109 ++
1 file changed, 109 insertions(+)
create mode 100644 target/linux/generic/pending-5.4/801-zram_default-algo.patch
diff
nd have a patch ready, which checks for algos
before announcing them.
Sven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
to
cherry-pick it to fix netifd.
relevant commit is: https://git.op enwrt.org/?p=project/netifd.git;a=commit
;h=8f82742ca4f47f459284f3a07323d04da72ea 5f6
Best Sven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https
he
DT partitions for the nvmem-cells MUST match the ones in mtdparts
But you are right, this will definitely not solve situations when there is no
DT used. And didn't say that I needed a solution for this - I was (hopefully)
always referring to devices which use mtdparts (which can also be used wi
On Sunday, 10 October 2021 14:53:13 CEST Sven Eckelmann wrote:
[...]
> Since there are most likely more devices out there which use mtdparts, I
> would
> guess that there might already be a strategy out there which can be used to
> define the nvmem-provider for mtdparts define
he of_node for this partition
via bus_find_device_by_of_node because there is no such of_node for mtdparts
partitions.
Kind regards,
Sven
[1] https://github.com/openwrt/openwrt/pull/4041
[2]
https://github.com/openwrt/openwrt/commit/5ae2e786395c7f9db0167ebe875be5df9502d8d8
signature.asc
D
On Friday, 17 September 2021 18:25:35 CEST Sven Eckelmann wrote:
[...]
> Interestingly, the crash disappeared when I've changed
> baseEepHeader.nonLinearTxFir (offset 0xc2 in the BDF) from 1 to 0.
>
> The device itself was using firmware 10.4-3.6-00140 (the version currently in
>
in Kalle's ath10k-firmware repository.
Does anybody know more about it?
Kind regards,
Sven
bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=PlasmaCloud-PA1200.bin
Description: Binary data
signature.asc
Description: This is a digitally signed me
* SSH agent forwarding might cause security issues, locally and on the jump
machine (https://defn.io/2019/04/12/ssh-forwarding/). So allow to
completely disabling it.
* separate options for client and server
* keep it enabled by default
Signed-of-by: Sven Roederer
---
package/network
Am Sonntag, 20. Juni 2021, 17:11:08 CEST schrieb Hauke Mehrtens:
> On 6/20/21 4:30 PM, Sven Roederer wrote:
> >
> > The Rb750 is DSA, so it seems there is still something wrong. I'll retest
> > with current master soon, to rule out issues based on 21.02-rc3.
> >
>
to rule out issues based on 21.02-rc3.
Sven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Am Donnerstag, 17. Juni 2021, 21:22:34 CEST schrieb Hauke Mehrtens:
> In particular, make sure to read the regressions and known issues before
> upgrading:
> https://openwrt.org/releases/21.02/notes-21.02.0-rc3#known_issues
>
just let me highlight FS#3866 (no network in fail
Hauke,
might be worth to mention in the commitmessage that this closes FS#3814.
Best Sven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
hat the conversion-dialog might come up multiple times. This will
prevent confusion of the user, which might expect an endless loop when the
dialog comes up the 2nd time.
Sven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lis
forward, but 2 questions come up
instantly:
* Do we want such check / restriction?
* What will be the best limit for the pathlength?
Sven
uclibc++ build-log
make[5]: Entering directory '/mnt/hosts/strike/develop/sven/openwrt/freifunk
Hauke,
thanks for the pointer.
My comments in the original thread.
Sven
Am Sonntag, 16. Mai 2021, 23:34:04 CEST schrieb Hauke Mehrtens:
>
> I debugged a similar problem a week ago and added this patch to opkg:
> https://patchwork.ozlabs.org/project/openwrt/patch/20210502205912.23753
proto-ipip.
The "Unknown package 'luci-proto-ipip'." line is still incorrect, but "can not
find dependency ipip" is the key.
So maybe not the last change to the code, but a big improvement.
Sven
> >> Signed-off-by: Hauke Mehrtens
> >> ---
>
lays all kinds of errors too easily. At least:
> Earlier there actually was an "incompatible architecture" message that got
> displayed if you tried mvebu package to x86 etc.. Apparently now that
> message surfaces too easily.
Yeah, seems a bit unspecific. Reverting opkg to
>
Not sure what's all inside these options, but seems a good idea.
Probably then a more niversal way should be used than handling every option
individually.
Sven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
to create Config.build.
This addresses the same issue that's fixed in the previous commit for the
imagebuilder.
Signed-off-by: Sven Roederer
---
target/sdk/convert-config.pl | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/target/sdk/convert-config.pl b/target/sdk/convert
This is v4 of this series including the findings and comments of Baptiste
* use standard format of disabled config items for imagebuilder
* remove unneeded and no-op SED call for SDK
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
behavior is that after unpacking the imagebuilder acts like
these settings have their defaults, using intree folders. So unset the
build-time settings.
Signed-off-by: Sven Roederer
---
target/imagebuilder/Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git a/target/imagebuilder/Makefile
; > - if (/^CONFIG_([^=]+)=(.*)$/) {
> > + if (/^CONFIG_((BINARY)|(DOWNLOAD))_FOLDER=(.*)$/) {
> > + # We don't want to preserve the build setting of
> > + # BINARY_FOLDER and DOWNLOAD_FOLDER.
> > + $var = "$1_FOLDER";
> > +
> using the ImageBuilder], it seems cleaner to stick to the standard format,
> e.g. in case a .config file is copied around from an imagebuilder.
>
The intention to not use th normal "unset" message was to leave a pointer why
it's unset in contrast to the build-time file, in case so
Am Montag, 26. April 2021, 16:58:20 CEST schrieb Sven Roederer:
> Using the BINARY_FOLDER or DOWNLOAD_FOLDER options make them escape from the
> build-system to the system the archives run later.
> As the build-time path will usually not work on the other system, restore
> the int
it's worth to put a not on the pinout to the Wiki, including a photo
of the pcb?
Best Sven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Am Samstag, 1. Mai 2021, 15:14:35 CEST schrieb Hannu Nyman:
> Sven Roederer kirjoitti 30.4.2021 klo 22.43:
> > ...
> > Digging further I found installing online pulled librt in. Restarting from
> > scratch ...
> > Downloading librt and wall via wget and running `opkg
Am Samstag, 1. Mai 2021, 15:14:35 CEST schrieb Hannu Nyman:
> Sven Roederer kirjoitti 30.4.2021 klo 22.43:
> > ...
> > Digging further I found installing online pulled librt in. Restarting from
> > scratch ...
> > Downloading librt and wall via wget and running `opkg
even still applies to TPLink WebIf. But back in
the days there was a link in the length of the firmware filename to be
uploaded. The message was teh same "invalid firmware type".
Probably renaming the file is worth a try ...
Sven
Am Freitag, 30. April 2021, 14:23:12 CEST schrieb Hannu Nyman:
> Sven Roederer kirjoitti 30.4.2021 klo 1.44:
> > Am Donnerstag, 29. April 2021, 01:54:34 CEST schrieb Sven Roederer:
> >> Using a freshly installed OpenWrt 21.02 fails to install a package that
> >> has
&g
Hi,
there are reports about unstable ethernet-links for TPLink EAP2x5 devices in
the forum [1].
I can confirm that cherry-picking fbbad9a9a629b388626b477e6cd692c160f63fb3 to
21.02 fixes it. Can somebody cherry-pick?
Best Sven
1 -
https://forum.openwrt.org/t/eap225-v1-lan-port-link-speed
Adrian,
Am Sonntag, 25. April 2021, 21:09:40 CEST schrieb Adrian Schmutzler:
> Hi,
>
> > -Original Message-
> > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> > On Behalf Of Sven Roederer
> > Sent: Samstag, 24. April 20
Am Donnerstag, 29. April 2021, 01:54:34 CEST schrieb Sven Roederer:
>
> Using a freshly installed OpenWrt 21.02 fails to install a package that has
> been downloaded manually. I had seen this initially when using my own image
> where a package was missing. To fix I copied over with sc
mpatible with the architectures configured
> * opkg_install_cmd: Cannot install package wall.
As far as I can see opkd config looks fine ...
> root@OpenWrt:/tmp# opkg print-architecture
> arch all 1
> arch noarch 1
> arch mips_24kc 10
Any ideas?
I did not check on master yet,
commit for the
imagebuilder.
Signed-off-by: Sven Roederer
---
target/sdk/Makefile | 1 +
target/sdk/convert-config.pl | 8 +++-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/target/sdk/Makefile b/target/sdk/Makefile
index 0606621192..5330d14955 100644
--- a/target
Using the BINARY_FOLDER or DOWNLOAD_FOLDER options make them escape from the
build-system to the system the archives run later.
As the build-time path will usually not work on the other system, restore the
intree defaults.
___
openwrt-devel mailing
behavior is that after unpacking the imagebuilder acts like
these settings have their defaults, using intree folders. So unset the
build-time settings.
Signed-off-by: Sven Roederer
---
target/imagebuilder/Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git a/target/imagebuilder/Makefile
.config
for the imagebuilder and via Config.in and Config.build for the sdk.
The expected behavior is that after unpacking sdk and imagebuilder act like
these
settings have the default, using intree folders. So unset or filter out the
build-
time settings.
Signed-off-by: Sven Roederer
Also use xz compression, as we do for sdk and imagebuilder.
Signed-off-by: Sven Roederer
---
target/toolchain/Makefile | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/target/toolchain/Makefile b/target/toolchain/Makefile
index c3ba70db04..cf34a89e04 100644
--- a/target
Am Samstag, 17. April 2021, 16:45:01 CEST schrieb Sven Roederer:
> On my Ubuntu 16.04 based build-system I also have build-failures for meson
> using Python3.5.
Correction: it's a 18.04 LTS ...
Sven
___
openwrt-devel mailing list
openwrt
meson updates into the packages feed fixing these errors, not sure if
this is caused by the meson upgrade or the python-upgrade.
So it's indeed a tricky situation. But having the EOLed Python3.5 as minimum
requirement for an upcoming release seems non optimal.
Sven
__
gt; 1. https://git.openwrt.org/2a3dbded93775aeaf28fbebbd6aada07c9f588c1
>
probably as removing inside a release-branch without real need has the
potential to cause more trouble than we will gain.
Sven
___
openwrt-devel mailing list
open
Juhos")
> >
> > https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=7b564bfdcbef
> > 05f68d8a658caf832c6832705e1f
> >
> > Sven, Florian: any chance you know how that code:
> > /* align next block on a 4 byte boundary */
> > len = ALIGN(len,4) - b
came a fan of swanctl more and more. Happy to see that you
made swanctl-config integration to UCI.
So no worries in dropping ipsec-tool way, even it feels like a era is ending
..
Sven
Am Dienstag, 13. April 2021, 22:19:07 CEST schrieb Philip Prindeville:
> Hi all,
>
> Word is that strongs
else seen this?
I'll check to see which of the relevant 6 commit trigger this during the next
days.
Full command is:
> let size="$(stat -c%s /mnt/hosts/strike/develop/sven/openwrt/freifunk/
freifunk-berlin/openwrt/build_dir/target-mips_24kc_musl/linux-ath79_generic/
tmp/freifunk-berlin-
Makefile:116: recipe for target '_call_image' failed
make[2]: *** [_call_image] Error 1
Makefile:241: recipe for target 'image' failed
make[1]: *** [image] Error 2
Signed-off-by: Sven Roederer
---
target/imagebuilder/Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git a/target/imagebuilder
Happy easter all and thanks for branching 21.02.
Holidays and lockdown give me some time to keep-up with OpenWrt. During this I
found that 21.02 is still missing the kernel-CONFIG for RTC_DRV_JZ4740
Can someone cherry-pick 55ed4bf6d7bf80b705d015c3b73f772db485ba9c into 21.02 to
fix?
Best Sven
download.
Can you check please?
Sven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
from 19.07.5 to master, I'd expect new services to be in their default
> initial state. Restoring "old" rc.d would have everything new disabled.
> That's counter-intuitive for me.
I'm also in favor of not touching new services, which have no
Am Dienstag, 12. Januar 2021, 19:56:54 CET schrieb Hannu Nyman:
> Martin Schiller kirjoitti 12.1.2021 klo 9.25:
> > On 2021-01-11 23:07, Sven Roederer wrote:
> >> Restore the status of the system-services after sysupgrade.
> >> Create a file with the status of all known
Am Montag, 11. Januar 2021, 03:59:51 CET schrieb Alberto Bursi:
> On 10/01/21 22:40, Sven Roederer wrote:
> > Am Sonntag, 10. Januar 2021, 09:47:27 CET schrieb Andre Heider:
> >>> Same. I would personally like this as default sysupgrade procedure, as
> >>>
as:
/etc/init.d/ {enable|disable}
When upgrading with an generic image all system services are enabled by
default which is usually not expected and can cause trouble.
The default behavior can be flipped with the "-s" option of sysupgrade.
Signed-off-by: Sven Roederer
---
This v
rfering dhcp server (I can probably configure
> it otherwise, but I don't require that instance at all).
That's quite the situation we have here with our common images. Users during
initial setup getting some services disabled based on their choices. As the
services shall remain inside the image (reconfigur
witch looked like the way. I've choosen the
lazy one, based on "when the user is storing the packages-list, he is for sure
interested in the services".
But I'm happy to add a separate switch to sysupgrade. Any preference of the
letter? What about using "-s"?
Sven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
When saving the list of installed pkgs, also store the status of the
system services. The list is created in the etc/backup folder also
and formated as:
/etc/init.d/ {enable|disable}
This way it can be sourced after sysupgrade, to restore the previous
state.
Signed-off-by: Sven Roederer
the option 3 was already pushed to OpenWrt master.
Kind regards,
Sven
signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
or a final ACK or NACK by Jo-Philipp.
So probably this is now the best chance to get it also included into 20.xx .
Best Sven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
guessing and I did not check. Most of this tools are usually
installed on recent systems per defaul and checking for them will nore harm.
But Perl and Python might be interesting to exclude from the checks.
Is anyone aware, that these are real requirements for Imagebuilder?
Best Sven
Am Donnerstag, 31. Dezember 2020, 20:35:47 CET schrieb Paul Spooren:
>
> Merged and backported.
>
I think 4f3806364011aa3aef26fcab2e7b71837a777bcc needs to be backported too,
to make it work.
Sven
___
openwrt-devel mailing list
open
year to all.
When I made the change to not check for gcc, g++ I was also thinking of using
a common "ifndef" block.
I used atomic blocks, as I expect it's more straight-forward on later changes
and more consistent (copy and paste) for ot
Am Freitag, 2. Oktober 2020, 21:34:30 CET schrieb Sven Roederer:
> Am Sonntag, 19. April 2020, 11:32:03 CEST schrieb Bjørn Mork:
> > Sven Roederer writes:
> > > I was just building a master-branch for x86-generic and got following
> > > error:
> > >
> >
les or remove really
> optional stuff, but this patch is too much of forcing here.
>
To me it looked like kernel USB-support is present, even the OpenWrt USB-
support is not enabled I've choosen the hardcoded way. So I was able to test
the change and ask for comments, without long rewo
Am Sonntag, 6. Dezember 2020, 11:03:56 CET schrieb Baptiste Jonglez:
> Hi,
>
> On 06-12-20, Sven Roederer wrote:
> > Currently 8MB flash / 32MB RAM devices are fully supported in OpenWrt, as
> > they work quite well for basic usage (including full LuCI).
> > On
Am Sonntag, 6. Dezember 2020, 13:59:52 CET schrieb Adrian Schmutzler:
> > -Original Message-
> > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> > On Behalf Of Sven Roederer
> > Sent: Sonntag, 6. Dezember 2020 02:07
> > To: openwrt-devel
on this low-end hardware it's nearly impossible to add external drives, so
there seems no need for this partition-type.
this will safe some kernel-size
---
target/linux/ath79/tiny/config-default | 1 +
1 file changed, 1 insertion(+)
diff --git a/target/linux/ath79/tiny/config-default
From: adminuser
---
target/linux/ath79/image/tiny-tp-link.mk | 4
target/linux/ath79/image/tiny-ubnt.mk| 2 --
target/linux/ath79/image/tiny.mk | 1 -
target/linux/ath79/tiny/config-default | 5 +++--
4 files changed, 3 insertions(+), 9 deletions(-)
diff --git
WR1043v1; WR842v1/v2; WR710
Signed-off-by: Sven Roederer
---
target/linux/ath79/image/Makefile | 1 +
target/linux/ath79/image/common-tp-link.mk| 2 +
target/linux/ath79/image/tiny-tp-link.mk | 66 +
target/linux/ath79/image/tiny-ubnt.mk | 132
From: adminuser
this includes:
* CONFIG_AIO
* CONFIG_HAVE_IDE
* CONFIG_NVMEM
* CONFIG_DEBUG_FS
* CONFIG_DEBUG_KERNEL
* CONFIG_HAVE_DEBUG_KMEMLEAK
* CONFIG_HAVE_DEBUG_STACKOVERFLOW
* CONFIG_ISDN
* CONFIG_SND_DRIVERS
* CONFIG_STAGING
* CONFIG_HAVE_KVM
* CONFIG_VIRTIO_MENU
---
From: adminuser
---
target/linux/ath79/tiny/config-default | 1 +
1 file changed, 1 insertion(+)
diff --git a/target/linux/ath79/tiny/config-default
b/target/linux/ath79/tiny/config-default
index 5dcdf30af4..f686d284f6 100644
--- a/target/linux/ath79/tiny/config-default
+++
Currently 8MB flash / 32MB RAM devices are fully supported in OpenWrt, as they
work quite well for basic usage (including full LuCI).
On some projects with advanced features (e.g. Freifunk) the lack of RAM turns
them into unstable devices. Mostly caused by several OOM problems per day.
This
seems to have no sideeffects I would like to see this merged.
Best Sven
> Reference to mailing list discussion in
> http://lists.openwrt.org/pipermail/openwrt-devel/2020-November/032266.html
>
> Kernel documentation:
> https://www.kernel.org/doc/Documentation/sysctl/vm.txt
>
&
fixes "file no found" error on stripped down images, caused by prod.sh:43.
Signed-off-by: Sven Roederer
---
package/system/procd/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/package/system/procd/Makefile b/package/system/procd/Makefile
index
1
Data validation failed!
Cc: Russell Senior
Cc: Jonas Gorski
Signed-off-by: Sven Eckelmann
---
I've originally submitted another hack on top of the original hack to avoid
this additional padding when the JFFS2 post-padding mark was detected.
https://github.com/openwrt/openwrt/pull/3616
Bu
From: Sven Danner
Comfast CF-E538AC is a wall mounted access point with an additional
Ethernet LAN access port. It supports 802.11AC Wave2 MU-MIMO.
Serial port access for debricking requires simple soldering of 4 pins.
Device specifications:
* SoC: MT7620DA @ 580MHz
* RAM: 64MiB DDR2
On Tuesday, 24 November 2020 08:58:04 CET Sven Eckelmann wrote:
[...]
> Now to the actual question:
I will just add some extra info to the options shown below. Maybe it makes
then more sense why I've added two gluon developers to the Cc.
> What should the OpenMesh devices use as
devices)
2. CE01 factory + CE01 sysupgrade (like ar71xx)
3. CE01 sysupgrade (like ar71xx but avoid having two files with the same
content)
Kind regards,
Sven
[1] https://openwrt.org/docs/guide-user/installation/ar71xx.to.ath79
[2] Just as info: The sysupgrade-tar script is no
> I am not sure if those insertion locations are quite optimal, but so far the
> approach has worked
>
>
Hannu,
When you have the patches in place, why not sending as patch officially? The
location in the code is quite the same I would choose. In addition it solves
problems on low-re
nWrt.
The only code necessary in the dts is:
/ {
chosen {
/delete-property/ bootargs;
};
};
I hope this helps you.
Kind regards,
Sven
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7784cac697351f0cc0a4bb619594
Comfast CF-E538AC is an wall mounted access point with an
additional Ethernet LAN access port. It supports
802.11AC Wave2 MU-MIMO
Serial port access for debricking requires simple soldering of 4 pins.
Device specifications:
* SoC: MT7620DA @ 580MHz
* RAM: 64MiB DDR2
* Flash: 8iB SPI
* Wireless
Am Sonntag, 18. Oktober 2020, 18:59:19 CET schrieb Sven Roederer:
> > > fail ---
> > > root@gib-mir-einen-namen:~# cat /lib/upgrade/freifunk-berlin_freeup-
> > > ram.sh
> > > ffberlin_freeup_ram() {
> > >
> > >
Comfast CF-E538AC is an wall mounted access point with an
additional Ethernet LAN access port. It supports
802.11AC Wave2 MU-MIMO
Serial port access for debricking requires simple soldering of 4 pins.
Device specifications:
* SoC: MT7620DA @ 580MHz
* RAM: 64MiB DDR2
t;.
Fixes: b5516603dd90 ("mac80211: more wifi reconf related fixes")
Signed-off-by: Sven Eckelmann
---
package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.
Am Samstag, 17. Oktober 2020, 01:15:38 CEST schrieb Adrian Schmutzler:
> Hi Sven,
>
> > -Original Message-
> > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> > On Behalf Of Sven Roederer
> > Sent: Samstag, 17. Oktober 20
mount /dev: Resource busy
umount: can't unmount /tmp: Resource busy
[ 343.465535] reboot: Restarting system
Any idea what is causing this behavior?
Is my idea a totally wrong approach?
Thanks Sven.
___
openwrt-devel mailing list
openw
Am Dienstag, 29. September 2020, 09:35:20 CEST schrieb Paul Spooren:
> On Sun Sep 27, 2020 at 11:07 AM HST, Sven Roederer wrote:
> > The buildroot and SDK both require the compilers (gcc, g++) to be
> > installed on the host system, however the ImageBuilder uses precompil
Am Samstag, 3. Oktober 2020, 19:16:51 CEST schrieb Paul Oranje:
> > Op 21 sep. 2020, om 20:42 heeft Sven Roederer het
> > volgende geschreven:
> >
> > Fernando,
> >
> > I'm only talking on the boards having 32MB RAM. This includes 4MB / 8MB
> > flash
1 - 100 of 487 matches
Mail list logo
