Re: 22.03 packages not building since 10 days
Am 22. Juli 2023 08:27:53 UTC schrieb "Petr Štetiar" : >Sebastian Kemper [2023-07-20 20:54:33]: > >Hi, > >> Can a kind soul please check the build bots for 22.03 packages? We pushed >> some security fixes about a week ago for pjsip and were hoping they'd be >> packaged by now. > >thanks for the report, should be fixed now. > >Cheers, > >Petr Than you Petr! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
22.03 packages not building since 10 days
Hi all, Can a kind soul please check the build bots for 22.03 packages? We pushed some security fixes about a week ago for pjsip and were hoping they'd be packaged by now. Thanks! Seb ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] build: revert 54070a1 (all kernels are >= 5.10)
Commit 54070a1 was added to allow building proper SDKs with kernels < 5.10. Now that all targets use at least kernel 5.10 it can be reverted. Signed-off-by: Sebastian Kemper --- include/kernel-defaults.mk | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/include/kernel-defaults.mk b/include/kernel-defaults.mk index 2e21392016..6687a58d1a 100644 --- a/include/kernel-defaults.mk +++ b/include/kernel-defaults.mk @@ -153,17 +153,12 @@ define Kernel/CopyImage } endef -# Always add "modules" so a proper Module.symvers file is written that -# also contains symbols from the kernel modules. Without these symbols -# external packages that depend on exported symbols from kernel modules -# will fail to build. define Kernel/CompileImage/Default rm -f $(TARGET_DIR)/init - +$(KERNEL_MAKE) $(KERNEL_MAKEOPTS_IMAGE) $(if $(KERNELNAME),$(KERNELNAME),all) modules + +$(KERNEL_MAKE) $(KERNEL_MAKEOPTS_IMAGE) $(if $(KERNELNAME),$(KERNELNAME),all) $(call Kernel/CopyImage) endef -# Here as well, always add "modules", see comment above. ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),) define Kernel/CompileImage/Initramfs $(call Kernel/Configure/Initramfs) @@ -185,7 +180,7 @@ endif # ?$(if $(CONFIG_TARGET_INITRAMFS_COMPRESSION_LZ4),) $(if $(CONFIG_TARGET_INITRAMFS_COMPRESSION_ZSTD),$(STAGING_DIR_HOST)/bin/zstd -T0 -f -o $(KERNEL_BUILD_DIR)/initrd.cpio.zstd $(KERNEL_BUILD_DIR)/initrd.cpio) endif - +$(KERNEL_MAKE) $(KERNEL_MAKEOPTS_IMAGE) $(if $(KERNELNAME),$(KERNELNAME),all) modules + +$(KERNEL_MAKE) $(KERNEL_MAKEOPTS_IMAGE) $(if $(KERNELNAME),$(KERNELNAME),all) $(call Kernel/CopyImage,-initramfs) endef else -- 2.30.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] nls.mk: clean up INTL flags
gettext (libintl-stub) was removed in commit [1], so the libintl-stub lib and include directories aren't existing anymore. This commit cleans up the INTL flags for the BUILD_NLS=n case. [1] e6f569406ffe1d9e35b9b9ea36f38cdd5837728d Signed-off-by: Sebastian Kemper --- include/nls.mk | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/include/nls.mk b/include/nls.mk index 163e480932..665ccb565d 100644 --- a/include/nls.mk +++ b/include/nls.mk @@ -15,7 +15,7 @@ else ICONV_PREFIX:=$(STAGING_DIR)/usr/lib/libiconv-stub ICONV_FULL:= - INTL_PREFIX:=$(STAGING_DIR)/usr/lib/libintl-stub + INTL_PREFIX:= INTL_FULL:= endif @@ -28,9 +28,15 @@ ICONV_CPPFLAGS:=-I$(ICONV_PREFIX)/include ICONV_LDFLAGS:=-L$(ICONV_PREFIX)/lib -Wl,-rpath-link=$(ICONV_PREFIX)/lib INTL_DEPENDS:=+BUILD_NLS:libintl-full -INTL_CFLAGS:=-I$(INTL_PREFIX)/include -INTL_CPPFLAGS:=-I$(INTL_PREFIX)/include -INTL_LDFLAGS:=-L$(INTL_PREFIX)/lib -Wl,-rpath-link=$(INTL_PREFIX)/lib +ifeq ($(CONFIG_BUILD_NLS),y) + INTL_CFLAGS:=-I$(INTL_PREFIX)/include + INTL_CPPFLAGS:=-I$(INTL_PREFIX)/include + INTL_LDFLAGS:=-L$(INTL_PREFIX)/lib -Wl,-rpath-link=$(INTL_PREFIX)/lib +else + INTL_CFLAGS:= + INTL_CPPFLAGS:= + INTL_LDFLAGS:= +endif TARGET_CFLAGS += $(ICONV_CFLAGS) $(INTL_CFLAGS) TARGET_CPPFLAGS += $(ICONV_CPPFLAGS) $(INTL_CPPFLAGS) -- 2.30.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC] Stop providing binary package updates for release builds?
Am Sun, Dec 12, 2021 at 08:42:52PM +0100 schrieb Jo-Philipp Wich:
>
> In my opinion, there is a fundamental decision to be made on whether we would
> like to pursue the goal of (also) being a binary distribution for
> routers/embedded appliances or if we simply concentrate on the build-from-
> source aspect and leave the binary package business to forks or other
> downstream distributions projects.
>
> Given that maintaining binary package distributions is hard and boring work we
> need to decide whether we want to fully and properly pursue this goal or
> rather not at all and focus on always porting master to the latest minor
> Kernel version and finding the optimal compilation flags for each SoC
> revision.
>
> I am interested in hearing you thoughts and comments on this matter.
Hi Jo,
I'm not exactly sure you mean to "only" stop uploading package updates
for release builds or if you'd at the same time also consider removing
the upgrade mechanism itself ("opkg") from the target images. The latter
would majorly increase the workload of testing new packages.
But I'm also opposed to just stopping to upload release package updates as
it is such a nice feature to have. Obviously it's really handy. Yes,
you can shoot yourself (and others) in the foot, but tell me one linux
distribution with strict gun control laws :).
Regarding "forks or other downstream distributions". Would be glad to
hear your personal choice of these, the ones you run on your own
routers. :)
If this notion made it into OpenWrt infra I can only _hope_ that a fork
gets made (again) :)
You can tell I write this half-jokingly, because I really don't think
anybody would seriously consider this.
Good night,
Seb
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: bugs.openwrt.org: please help with my user
Am Mon, Aug 30, 2021 at 12:45:31PM +0200 schrieb Sebastian Kemper: > Hi all, > > Sorry to have to bring this up. Can anybody please check my OpenWrt > Flyspray account(s)? I tried to oauth with Github (my user there is > "micmac1"). But then I got two errors from Flyspray: > > 1. "Email address has already been taken" > 2. "This username has already been taken, please choose a different name" > > When I click Login -> Password Lost and I enter my username (I tried > micmac and micmac1) then I get the following message: > > "This user is unknown in this Flyspray instance." > > Maybe I'm wrong about my username and it's a different one which I > forgot? Can you please check with my mail address and let me know the > username? Preferably I'd like to be able to login via Github oauth. > > Thanks! > Seb Hello all, It's sorted out. Thanks for your help! Kind regards, Seb ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
bugs.openwrt.org: please help with my user
Hi all, Sorry to have to bring this up. Can anybody please check my OpenWrt Flyspray account(s)? I tried to oauth with Github (my user there is "micmac1"). But then I got two errors from Flyspray: 1. "Email address has already been taken" 2. "This username has already been taken, please choose a different name" When I click Login -> Password Lost and I enter my username (I tried micmac and micmac1) then I get the following message: "This user is unknown in this Flyspray instance." Maybe I'm wrong about my username and it's a different one which I forgot? Can you please check with my mail address and let me know the username? Preferably I'd like to be able to login via Github oauth. Thanks! Seb ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] prereq-build: require python3-distutils
Am Mon, Aug 23, 2021 at 11:12:00PM +0200 schrieb Hauke Mehrtens: > Hi Andre, > > I will backport this to 21.02 in the next days. I want to wait if there are > more problems showing up in master. > > Hauke Hello Hauke, all, Were there any problems showing up? Or is this good to go into 21.02? Kind regards, Sebastian > > On 8/23/21 10:47 PM, Andre Heider wrote: > > Hi Hauke, > > > > thanks for merging the patch! > > > > Can we also get this cherry-picked to the 21.02 branch, please? > > > > Jeffery makes some good points as to why here: > > https://github.com/openwrt/packages/pull/16304#issuecomment-904097018 > > > > I too can see that package backports could get unnecessarily painful in > > the future without this in 21.02. > > > > Thanks, > > Andre > > > > On 10/08/2021 12:22, Andre Heider wrote: > > > Debian and Ubuntu ship a python3-minimal package which does not include > > > the distutils module. This is not supported by upstream and can be > > > considered a broken python distribution. > > > > > > In practice, many scripts depend on said module, and this is a reoccuring > > > pain point for building various OpenWrt packages. > > > > > > Require and check for said module, enough time has been wasted on this. > > > > > > A list of just the most recent issues: > > > https://github.com/openwrt/packages/pull/16304 > > > https://github.com/openwrt/packages/pull/16027 > > > https://github.com/openwrt/packages/pull/15443 > > > https://github.com/openwrt/packages/pull/14394 > > > https://github.com/openwrt/packages/pull/12909 > > > https://github.com/openwrt/packages/issues/12443 > > > https://github.com/openwrt/packages/pull/11035 > > > https://github.com/openwrt/packages/issues/10993 > > > > > > Signed-off-by: Andre Heider > > > --- > > > include/prereq-build.mk | 4 > > > 1 file changed, 4 insertions(+) > > > > > > diff --git a/include/prereq-build.mk b/include/prereq-build.mk > > > index 8fbf6f22c4..922e7c544b 100644 > > > --- a/include/prereq-build.mk > > > +++ b/include/prereq-build.mk > > > @@ -170,6 +170,10 @@ $(eval $(call SetupHostCommand,python3,Please > > > install Python >= 3.6, \ > > > python3.6 -V 2>&1 | grep 'Python 3', \ > > > python3 -V 2>&1 | grep -E 'Python 3\.[6-9]\.?')) > > > +$(eval $(call TestHostCommand,python3-distutils, \ > > > + Please install the Python3 distutils module, \ > > > + $(STAGING_DIR_HOST)/bin/python3 -c 'import distutils')) > > > + > > > $(eval $(call SetupHostCommand,git,Please install Git (git-core) > > > >= 1.7.12.2, \ > > > git --exec-path | xargs -I % -- grep -q -- --recursive > > > %/git-submodule)) > > > > > > pub RSA 4096/0910B515 2018-07-15 Hauke Mehrtens > sub RSA 2048/24EF3BAE 2018-07-15 > sub RSA 2048/9CB2EBC7 2018-07-15 > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] build: fix regression for kernels < 5.10
On Tue, Apr 13, 2021 at 03:09:24PM +0200, Felix Fietkau wrote:
>
> On 2021-04-13 14:22, Sebastian Kemper wrote:
> > This fixes a regression introduced with commit
> > 5ed1e5140a80558ab47fd70410ae3242bed5becf ("build: build kernel image
> > before building modules/packages").
> >
> > Before this commit the make target would always include "modules",
> > resulting in a MODPOST and a complete Module.symvers file. Since this
> > commit a MODPOST of the kernel modules is not guaranteed for kernels <
> > 5.10. This results in some broken SDKs in which external packages that
> > depend on exported symbols from kernel modules fail to compile.
> Why is it not enough to do this in the CompileModules step?
Because Module.symvers gets regenerated during CompileImage as well.
>
> > Adding "modules" back to the calls to the CompileImage defines fixes the
> > regression. For kernels > 5.10 this is not needed, but it doesn't cause
> > any harm either.
> Why is >5.10 not affected? Can we backport the fix? I'd like to avoid
> adding extra unnecessary build step that slow down running make
> target/install.
>
You added 5ed1e5140a80558ab47fd70410ae3242bed5becf because of changes in
this area. I imagine one would need to look there.
I don't see adding "modules" back slowing anything down, because the
modules are already built when CompileImage is run. "modules" just makes
sure on kernels < 5.10 that MODPOST is run and the Module.symvers file
is complete.
> > Tested with kernels 5.4.x and 5.10.x.
> >
> > Signed-off-by: Sebastian Kemper
> > ---
> > include/kernel-defaults.mk | 9 +++--
> > 1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/kernel-defaults.mk b/include/kernel-defaults.mk
> > index 4b0b136a03..1b3b4497a2 100644
> > --- a/include/kernel-defaults.mk
> > +++ b/include/kernel-defaults.mk
> > @@ -147,12 +147,17 @@ define Kernel/CopyImage
> > }
> > endef
> >
> > +# Always add "modules" so a proper Module.symvers file is written that
> > +# also contains symbols from the kernel modules. Without these symbols
> > +# external packages that depend on exported symbols from kernel modules
> > +# will fail to build.
> > define Kernel/CompileImage/Default
> > rm -f $(TARGET_DIR)/init
> > - +$(KERNEL_MAKE) $(KERNEL_MAKEOPTS_IMAGE) $(if
> > $(KERNELNAME),$(KERNELNAME),all)
> > + +$(KERNEL_MAKE) $(KERNEL_MAKEOPTS_IMAGE) $(if
> > $(KERNELNAME),$(KERNELNAME),all) modules
> > $(call Kernel/CopyImage)
> > endef
> >
> > +# Here as well, always add "modules", see comment above.
> > ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),)
> > define Kernel/CompileImage/Initramfs
> > $(call Kernel/Configure/Initramfs)
> > @@ -173,7 +178,7 @@ endif
> > # ?$(if $(CONFIG_TARGET_INITRAMFS_COMPRESSION_LZ4),)
> > $(if
> > $(CONFIG_TARGET_INITRAMFS_COMPRESSION_ZSTD),$(STAGING_DIR_HOST)/bin/zstd
> > -T0 -f -o $(KERNEL_BUILD_DIR)/initrd.cpio.zstd
> > $(KERNEL_BUILD_DIR)/initrd.cpio)
> > endif
> > - +$(KERNEL_MAKE) $(KERNEL_MAKEOPTS_IMAGE) $(if
> > $(KERNELNAME),$(KERNELNAME),all)
> > + +$(KERNEL_MAKE) $(KERNEL_MAKEOPTS_IMAGE) $(if
> > $(KERNELNAME),$(KERNELNAME),all) modules
> Why do this for initramfs as well?
Again, because Module.symvers is regenerated. And whatever
Module.symvers file is the last one to be generated will make its way
into the SDK.
>
> - Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] build: fix regression for kernels < 5.10
This fixes a regression introduced with commit
5ed1e5140a80558ab47fd70410ae3242bed5becf ("build: build kernel image
before building modules/packages").
Before this commit the make target would always include "modules",
resulting in a MODPOST and a complete Module.symvers file. Since this
commit a MODPOST of the kernel modules is not guaranteed for kernels <
5.10. This results in some broken SDKs in which external packages that
depend on exported symbols from kernel modules fail to compile.
Adding "modules" back to the calls to the CompileImage defines fixes the
regression. For kernels > 5.10 this is not needed, but it doesn't cause
any harm either.
Tested with kernels 5.4.x and 5.10.x.
Signed-off-by: Sebastian Kemper
---
include/kernel-defaults.mk | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/include/kernel-defaults.mk b/include/kernel-defaults.mk
index 4b0b136a03..1b3b4497a2 100644
--- a/include/kernel-defaults.mk
+++ b/include/kernel-defaults.mk
@@ -147,12 +147,17 @@ define Kernel/CopyImage
}
endef
+# Always add "modules" so a proper Module.symvers file is written that
+# also contains symbols from the kernel modules. Without these symbols
+# external packages that depend on exported symbols from kernel modules
+# will fail to build.
define Kernel/CompileImage/Default
rm -f $(TARGET_DIR)/init
- +$(KERNEL_MAKE) $(KERNEL_MAKEOPTS_IMAGE) $(if
$(KERNELNAME),$(KERNELNAME),all)
+ +$(KERNEL_MAKE) $(KERNEL_MAKEOPTS_IMAGE) $(if
$(KERNELNAME),$(KERNELNAME),all) modules
$(call Kernel/CopyImage)
endef
+# Here as well, always add "modules", see comment above.
ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),)
define Kernel/CompileImage/Initramfs
$(call Kernel/Configure/Initramfs)
@@ -173,7 +178,7 @@ endif
# ?$(if $(CONFIG_TARGET_INITRAMFS_COMPRESSION_LZ4),)
$(if
$(CONFIG_TARGET_INITRAMFS_COMPRESSION_ZSTD),$(STAGING_DIR_HOST)/bin/zstd -T0 -f
-o $(KERNEL_BUILD_DIR)/initrd.cpio.zstd $(KERNEL_BUILD_DIR)/initrd.cpio)
endif
- +$(KERNEL_MAKE) $(KERNEL_MAKEOPTS_IMAGE) $(if
$(KERNELNAME),$(KERNELNAME),all)
+ +$(KERNEL_MAKE) $(KERNEL_MAKEOPTS_IMAGE) $(if
$(KERNELNAME),$(KERNELNAME),all) modules
$(call Kernel/CopyImage,-initramfs)
endef
else
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Incomplete Module.symvers file in some SDKs
On Mon, Apr 12, 2021 at 01:37:59PM +0200, Sebastian Kemper wrote:
> What set this off was commit 5ed1e5140a80558ab47fd70410ae3242bed5becf
> ("build: build kernel image before building modules/packages"). Before
> this commit the make target would always include "modules", resulting in
> a MODPOST and a complete Module.symvers file. Since this commit a
> MODPOST of the kernel modules is not guaranteed, which may result in a
> broken SDK.
>
> I think that the first line that the commit changed was probably enough.
> Adding "modules" back to the other two lines will probably fix this
> problem without causing any headache. Probably a comment should be added
> to make people aware that "modules" is there for a reason.
I tried this:
diff --git a/include/kernel-defaults.mk b/include/kernel-defaults.mk
index 4b0b136a03..1b3b4497a2 100644
--- a/include/kernel-defaults.mk
+++ b/include/kernel-defaults.mk
@@ -147,12 +147,17 @@ define Kernel/CopyImage
}
endef
+# Always add "modules" so a proper Module.symvers file is written that
+# also contains symbols from the kernel modules. Without these symbols
+# external packages that depend on exported symbols from kernel modules
+# will fail to build.
define Kernel/CompileImage/Default
rm -f $(TARGET_DIR)/init
- +$(KERNEL_MAKE) $(KERNEL_MAKEOPTS_IMAGE) $(if
$(KERNELNAME),$(KERNELNAME),all)
+ +$(KERNEL_MAKE) $(KERNEL_MAKEOPTS_IMAGE) $(if
$(KERNELNAME),$(KERNELNAME),all) modules
$(call Kernel/CopyImage)
endef
+# Here as well, always add "modules", see comment above.
ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),)
define Kernel/CompileImage/Initramfs
$(call Kernel/Configure/Initramfs)
@@ -173,7 +178,7 @@ endif
# ?$(if $(CONFIG_TARGET_INITRAMFS_COMPRESSION_LZ4),)
$(if
$(CONFIG_TARGET_INITRAMFS_COMPRESSION_ZSTD),$(STAGING_DIR_HOST)/bin/zstd -T0 -f
-o $(KERNEL_BUILD_DIR)/initrd.cpio.zstd $(KERNEL_BUILD_DIR)/initrd.cpio)
endif
- +$(KERNEL_MAKE) $(KERNEL_MAKEOPTS_IMAGE) $(if
$(KERNELNAME),$(KERNELNAME),all)
+ +$(KERNEL_MAKE) $(KERNEL_MAKEOPTS_IMAGE) $(if
$(KERNELNAME),$(KERNELNAME),all) modules
$(call Kernel/CopyImage,-initramfs)
endef
else
With this change a "make -j2 V=s" resulted in a proper Module.symvers file.
Kind regards,
Sebastian
>
> I checked openwrt-21.02, but the commit in question was not applied
> there, so 21.02 is fine.
>
> Any thoughts?
>
> Kind regards,
> Sebastian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Incomplete Module.symvers file in some SDKs
Hi all,
Some SDKs have a Module.symvers file in
build_dir/target-*/linux-*/linux-5.4.*/ that is missing exported symbols
from kernel modules:
openwrt-sdk-mpc85xx-p1010_gcc-8.4.0_musl.Linux-x86_64
openwrt-sdk-apm821xx-nand_gcc-8.4.0_musl.Linux-x86_64
openwrt-sdk-kirkwood_gcc-8.4.0_musl_eabi.Linux-x86_64
openwrt-sdk-oxnas-ox820_gcc-8.4.0_musl_eabi.Linux-x86_64
openwrt-sdk-mvebu-cortexa9_gcc-8.4.0_musl_eabi.Linux-x86_64
openwrt-sdk-mediatek-mt7629_gcc-8.4.0_musl_eabi.Linux-x86_64
openwrt-sdk-armvirt-32_gcc-8.4.0_musl_eabi.Linux-x86_64
openwrt-sdk-armvirt-64_gcc-8.4.0_musl.Linux-x86_64
Any external kernel module package that depends on any exported symbol
from a linux kernel module will fail to build in these SDKs. For
instance the dahdi-linux package depends on symbols from the kernel's
"echo" module fails:
ERROR: "oslec_create"
[/builder/shared-workdir/build/sdk/build_dir/target-arm_mpcore_musl_eabi/linux-oxnas_ox820/dahdi-linux-3.1.0/drivers/dahdi/dahdi_echocan_oslec.ko]
undefined!
ERROR: "oslec_free"
[/builder/shared-workdir/build/sdk/build_dir/target-arm_mpcore_musl_eabi/linux-oxnas_ox820/dahdi-linux-3.1.0/drivers/dahdi/dahdi_echocan_oslec.ko]
undefined!
This problem is visible on the build bots (some packages are failing to
build) as well as in the CIs used for the external feeds (Github Actions).
The reason for the incomplete Module.symvers file is that when either
Kernel/CompileImage/Default or Kernel/CompileImage/Initramfs (see
include/kernel-defaults.mk) is called and KERNELNAME is given, the make
target may be of the sort which does not prompt the Linux kernel to
MODPOST the modules. For instance when building the
openwrt-sdk-ath79-generic_gcc-8.4.0_musl.Linux-x86_64 sdk KERNELNAME is
not set and the resulting call is this one:
make -C
/home/sk/tmp/openwrt/build_dir/target-mips_24kc_musl/linux-ath79_generic/linux-5.4.109
all
This is visible in the output:
MODPOST 59 modules
The Module.symvers file is complete.
Using the openwrt-sdk-apm821xx-nand_gcc-8.4.0_musl.Linux-x86_64 sdk on
the other hand results in this call (KERNELNAME is uImage).
make -C
/home/sk/tmp/openwrt/build_dir/target-powerpc_464fp_musl/linux-apm821xx_nand/linux-5.4.98
uImage
No MODPOST occurs for the Linux kernel modules. The resulting
Module.symvers file is incomplete.
What set this off was commit 5ed1e5140a80558ab47fd70410ae3242bed5becf
("build: build kernel image before building modules/packages"). Before
this commit the make target would always include "modules", resulting in
a MODPOST and a complete Module.symvers file. Since this commit a
MODPOST of the kernel modules is not guaranteed, which may result in a
broken SDK.
I think that the first line that the commit changed was probably enough.
Adding "modules" back to the other two lines will probably fix this
problem without causing any headache. Probably a comment should be added
to make people aware that "modules" is there for a reason.
I checked openwrt-21.02, but the commit in question was not applied
there, so 21.02 is fine.
Any thoughts?
Kind regards,
Sebastian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] build: prevent dupes in autotools.mk
autotools.mk does not have any protection currently that would prevent it from being sourced multiple times. Note that both package.mk and host-build.mk source autotools.mk. So any package Makefile that includes both will cause hooks to be added twice (at least twice). This is fixed by declaring a new variable, __autotools_inc, and only continuing if this variable doesn't equal 1. The same is done by rules.mk already. Also, this commit does away with an ifneq that checks PKG_FIXUP (instead of HOST_FIXUP) for patch-libtool before adding to the host pre-configure hook. This does not make sense. The second ifneq is amended. The current one manually does what the define patch_libtool_host is already doing. It can just use the define. Signed-off-by: Sebastian Kemper --- include/autotools.mk | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/include/autotools.mk b/include/autotools.mk index 4b48b38992..3f029567e3 100644 --- a/include/autotools.mk +++ b/include/autotools.mk @@ -2,6 +2,9 @@ # # Copyright (C) 2007-2020 OpenWrt.org +ifneq ($(__autotools_inc),1) +__autotools_inc=1 + autoconf_bool = $(patsubst %,$(if $($(1)),--enable,--disable)-%,$(2)) # delete *.la-files from staging_dir - we can not yet remove respective lines within all package @@ -152,12 +155,8 @@ define patch_libtool_host $(HOST_BUILD_DIR))) endef -ifneq ($(filter patch-libtool,$(PKG_FIXUP)),) - Hooks/HostConfigure/Pre += patch_libtool_host -endif - ifneq ($(filter patch-libtool,$(HOST_FIXUP)),) - Hooks/HostConfigure/Pre += $(strip $(call patch_libtool,$(HOST_BUILD_DIR))) + Hooks/HostConfigure/Pre += patch_libtool_host endif ifneq ($(filter libtool,$(HOST_FIXUP)),) @@ -177,3 +176,5 @@ ifneq ($(filter autoreconf,$(HOST_FIXUP)),) Hooks/HostConfigure/Pre += autoreconf_host endif endif + +endif #__autotools_inc -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] toolchain/autoconf-lean: add check for ssize_t
This was provided by the old static config.site files and is required by some software, i.e. freeswitch. Signed-off-by: Sebastian Kemper --- toolchain/autoconf-lean/patches/120-add-extra-checks.patch | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/toolchain/autoconf-lean/patches/120-add-extra-checks.patch b/toolchain/autoconf-lean/patches/120-add-extra-checks.patch index 7e81525daf..382e6e5ad1 100644 --- a/toolchain/autoconf-lean/patches/120-add-extra-checks.patch +++ b/toolchain/autoconf-lean/patches/120-add-extra-checks.patch @@ -29,7 +29,7 @@ # Checks for typedefs, structures, and compiler characteristics. AC_TYPE_GETGROUPS -@@ -217,6 +222,16 @@ AC_FUNC_STRTOLD +@@ -217,6 +222,17 @@ AC_FUNC_STRTOLD AC_FUNC_UTIME_NULL AC_FUNC_VPRINTF @@ -42,6 +42,7 @@ +AC_CHECK_SIZEOF(unsigned long long) +AC_CHECK_SIZEOF(off_t) +AC_CHECK_SIZEOF(size_t) ++AC_CHECK_SIZEOF(ssize_t) + # Functions list scraped from musl 0.9.4 x86_64 AC_CHECK_FUNCS([ \ -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[INFRA]: build bot /tmp dir not writable
Hi all, Since a few days at least it seems there is some issue on the build bots. include/toplevel.mk runs this: export GNU_HOST_NAME:=$(shell $(TOPDIR)/scripts/config.guess) The result is used in include/host-build.mk and include/package-defaults.mk. But currently this sometimes doesn't work. Example in [1]. At the top it's visible that config.guess fails to run properly: config.guess: cannot create a temporary directory in /tmp config.guess: cannot create a temporary directory in /tmp config.guess: cannot create a temporary directory in /tmp Hence GNU_HOST_NAME is not set properly, causing other issues. I checked a few logs and found that this seems to only happen on these hosts: HOSTNAME=7475f09a818a HOSTNAME=fafab0b55569 Can you please check if maybe /tmp is full or permissions are wrong? Please keep me in CC as I'm not subsribed. Thanks! Sebastian [1] https://buildbot.openwrt.org/master/images/builders/lantiq%2Fxrx200/builds/680/steps/pkgbuild/logs/stdio ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v4] build: create $(PKG_SYMVERS_DIR) if non-existent
Commit 5d76065 moved the creation of the symvers directory to include/kernel-build.mk. This is fine when building from scratch. But when unpacking an SDK the directory doesn't exist and because the kernel won't be built (again) this directory will not be created by the build system, causing build failure if make tries to copy files into it. This moves the creation of the symvers directory back into include/kernel.mk so that the directory is created in any case. Signed-off-by: Sebastian Kemper --- include/kernel-build.mk | 1 - include/kernel.mk | 1 + 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/include/kernel-build.mk b/include/kernel-build.mk index a698deec3c..22f7c4c7c7 100644 --- a/include/kernel-build.mk +++ b/include/kernel-build.mk @@ -136,7 +136,6 @@ define BuildKernel $(LINUX_DIR)/.modules: export PKG_CONFIG_LIBDIR=$$(STAGING_DIR_HOST)/lib/pkgconfig $(LINUX_DIR)/.modules: $(STAMP_CONFIGURED) $(LINUX_DIR)/.config FORCE $(Kernel/CompileModules) - mkdir -p $(PKG_SYMVERS_DIR) touch $$@ $(LINUX_DIR)/.image: export STAGING_PREFIX=$$(STAGING_DIR_HOST) diff --git a/include/kernel.mk b/include/kernel.mk index 1ae9c6be29..1466048b0c 100644 --- a/include/kernel.mk +++ b/include/kernel.mk @@ -149,6 +149,7 @@ define collect_module_symvers grep -F realdir $(PKG_BUILD_DIR)/subdir/Module.symvers >> $(PKG_BUILD_DIR)/Module.symvers.tmp; \ done; \ sort -u $(PKG_BUILD_DIR)/Module.symvers.tmp > $(PKG_BUILD_DIR)/Module.symvers; \ + mkdir -p $(PKG_SYMVERS_DIR); \ mv $(PKG_BUILD_DIR)/Module.symvers $(PKG_SYMVERS_DIR)/$(PKG_NAME).symvers endef -- 2.26.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v3] build: create $(PKG_SYMVERS_DIR) if non-existent
On Wed, Nov 18, 2020 at 10:28:12PM +0100, Sebastian Kemper wrote: > diff --git a/include/kernel.mk b/include/kernel.mk > index 1ae9c6be29..d48b68f515 100644 > --- a/include/kernel.mk > +++ b/include/kernel.mk > @@ -149,6 +149,7 @@ define collect_module_symvers > grep -F realdir > $(PKG_BUILD_DIR)/subdir/Module.symvers >> > $(PKG_BUILD_DIR)/Module.symvers.tmp; \ > done; \ > sort -u $(PKG_BUILD_DIR)/Module.symvers.tmp > > $(PKG_BUILD_DIR)/Module.symvers; \ > + mkdir -p $(PKG_SYMVERS_DIR) > mv $(PKG_BUILD_DIR)/Module.symvers > $(PKG_SYMVERS_DIR)/$(PKG_NAME).symvers > endef Whoopsie, I just realized that this is all sort of linked together with backslashes. I don't think this is needed except for the for loop. But I'll send a v5 that keeps this fashion as is. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v3] build: create $(PKG_SYMVERS_DIR) if non-existent
Commit 5d76065 moved the creation of the symvers directory to include/kernel-build.mk. This is fine when building from scratch. But when unpacking an SDK the directory doesn't exist and because the kernel won't be built (again) this directory will not be created by the build system, causing build failure if make tries to copy files into it. This moves the creation of the symvers directory back into include/kernel.mk so that the directory is created in any case. Signed-off-by: Sebastian Kemper --- include/kernel-build.mk | 1 - include/kernel.mk | 1 + 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/include/kernel-build.mk b/include/kernel-build.mk index a698deec3c..22f7c4c7c7 100644 --- a/include/kernel-build.mk +++ b/include/kernel-build.mk @@ -136,7 +136,6 @@ define BuildKernel $(LINUX_DIR)/.modules: export PKG_CONFIG_LIBDIR=$$(STAGING_DIR_HOST)/lib/pkgconfig $(LINUX_DIR)/.modules: $(STAMP_CONFIGURED) $(LINUX_DIR)/.config FORCE $(Kernel/CompileModules) - mkdir -p $(PKG_SYMVERS_DIR) touch $$@ $(LINUX_DIR)/.image: export STAGING_PREFIX=$$(STAGING_DIR_HOST) diff --git a/include/kernel.mk b/include/kernel.mk index 1ae9c6be29..d48b68f515 100644 --- a/include/kernel.mk +++ b/include/kernel.mk @@ -149,6 +149,7 @@ define collect_module_symvers grep -F realdir $(PKG_BUILD_DIR)/subdir/Module.symvers >> $(PKG_BUILD_DIR)/Module.symvers.tmp; \ done; \ sort -u $(PKG_BUILD_DIR)/Module.symvers.tmp > $(PKG_BUILD_DIR)/Module.symvers; \ + mkdir -p $(PKG_SYMVERS_DIR) mv $(PKG_BUILD_DIR)/Module.symvers $(PKG_SYMVERS_DIR)/$(PKG_NAME).symvers endef -- 2.26.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] build: create $(PKG_SYMVERS_DIR) if non-existent
On Tue, Nov 17, 2020 at 11:53:29AM -1000, Paul Spooren wrote: > On Tue Nov 17, 2020 at 11:36 AM HST, Sebastian Kemper wrote: > > Commit 5d76065 moved the creation of the symvers directory to > > include/kernel-build.mk. This is fine when building from scratch. But > > when unpacking an SDK the directory doesn't exist and because the kernel > > won't be built (again) this directory will not be created by the build > > system, causing build failure if make tries to copy files into it. > > > > Signed-off-by: Sebastian Kemper > > Could you please provide an example when that fails? E.g. what package > makes the SDK copy things there? Hi Paul, All kernel module packages I suppose. Look at the failures on the build bots these days, since the mentioned commit hit master. I.e. [1] fails and then there is follow-up breakage. Or download an SDK, unpack it, install cryptodev-linux and try to package it. It'll fail, obviously, because the build bots are using the SDK and so are you :) Kind regards, Seb [1] https://downloads.openwrt.org/snapshots/faillogs/aarch64_cortex-a53/base/cryptodev-linux/compile.txt > > > --- > > include/kernel.mk | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/include/kernel.mk b/include/kernel.mk > > index 1ae9c6be29..e803ff44e7 100644 > > --- a/include/kernel.mk > > +++ b/include/kernel.mk > > @@ -140,6 +140,7 @@ endif > > PKG_EXTMOD_SUBDIRS ?= . > > > > PKG_SYMVERS_DIR = $(KERNEL_BUILD_DIR)/symvers > > +$(shell mkdir -p $(PKG_SYMVERS_DIR)) > > > > define collect_module_symvers > > for subdir in $(PKG_EXTMOD_SUBDIRS); do \ > > -- > > 2.26.2 > > > > > > ___ > > openwrt-devel mailing list > > openwrt-devel@lists.openwrt.org > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2] build: create $(PKG_SYMVERS_DIR) if non-existent
Commit 5d76065 moved the creation of the symvers directory to include/kernel-build.mk. This is fine when building from scratch. But when unpacking an SDK the directory doesn't exist and because the kernel won't be built (again) this directory will not be created by the build system, causing build failure if make tries to copy files into it. This moves the creation of the symvers directory back into include/kernel.mk so that the directory is created in any case. Signed-off-by: Sebastian Kemper --- include/kernel-build.mk | 1 - include/kernel.mk | 1 + 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/include/kernel-build.mk b/include/kernel-build.mk index a698deec3c..22f7c4c7c7 100644 --- a/include/kernel-build.mk +++ b/include/kernel-build.mk @@ -136,7 +136,6 @@ define BuildKernel $(LINUX_DIR)/.modules: export PKG_CONFIG_LIBDIR=$$(STAGING_DIR_HOST)/lib/pkgconfig $(LINUX_DIR)/.modules: $(STAMP_CONFIGURED) $(LINUX_DIR)/.config FORCE $(Kernel/CompileModules) - mkdir -p $(PKG_SYMVERS_DIR) touch $$@ $(LINUX_DIR)/.image: export STAGING_PREFIX=$$(STAGING_DIR_HOST) diff --git a/include/kernel.mk b/include/kernel.mk index 1ae9c6be29..e803ff44e7 100644 --- a/include/kernel.mk +++ b/include/kernel.mk @@ -140,6 +140,7 @@ endif PKG_EXTMOD_SUBDIRS ?= . PKG_SYMVERS_DIR = $(KERNEL_BUILD_DIR)/symvers +$(shell mkdir -p $(PKG_SYMVERS_DIR)) define collect_module_symvers for subdir in $(PKG_EXTMOD_SUBDIRS); do \ -- 2.26.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] build: create $(PKG_SYMVERS_DIR) if non-existent
Commit 5d76065 moved the creation of the symvers directory to include/kernel-build.mk. This is fine when building from scratch. But when unpacking an SDK the directory doesn't exist and because the kernel won't be built (again) this directory will not be created by the build system, causing build failure if make tries to copy files into it. Signed-off-by: Sebastian Kemper --- include/kernel.mk | 1 + 1 file changed, 1 insertion(+) diff --git a/include/kernel.mk b/include/kernel.mk index 1ae9c6be29..e803ff44e7 100644 --- a/include/kernel.mk +++ b/include/kernel.mk @@ -140,6 +140,7 @@ endif PKG_EXTMOD_SUBDIRS ?= . PKG_SYMVERS_DIR = $(KERNEL_BUILD_DIR)/symvers +$(shell mkdir -p $(PKG_SYMVERS_DIR)) define collect_module_symvers for subdir in $(PKG_EXTMOD_SUBDIRS); do \ -- 2.26.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] build: allow file modes per binary package
Currently the global variable PKG_FILE_MODES is used for all ipkg creations. This works for Makefiles which output a single package, or variants of a single package. But if a Makefile outputs multiple packages that each contain different files, setting PKG_FILE_MODES causes build failure when any of the files in the variable do not exist in the folder that is currently being packaged. Example: /openwrt/staging_dir/host/bin/fakeroot -l /openwrt/staging_dir/host/lib/libfakeroot.so -f /openwrt/staging_dir/host/bin/faked /openwrt/scripts/ipkg-build -m "/usr/lib/mariadb/plugin/auth_pam_tool_dir:root:376:0750" /openwrt/build_dir/target-mips_24kc_musl/mariadb-10.4.13/ipkg-mips_24kc/mariadb-server-plugin-disks /openwrt/bin/packages/mips_24kc/packages +chown: cannot access '/openwrt/build_dir/target-mips_24kc_musl/mariadb-10.4.13/ipkg-mips_24kc/mariadb-server-plugin-disks//usr/lib/mariadb/plugin/auth_pam_tool_dir': No such file or directory This commit changes the file mode handling a bit. The file mode can now be set either globally via PKG_FILE_MODES (no behavior change) or on a per-package basis via FILE_MODES. This way specific file modes can be used for any particular package. This behavior is already used for other OpenWrt variables, hence it is familiar: PKG_MAINTAINER vs MAINTAINER PKG_SOURCE_SUBDIR vs SUBDIR PKG_LICENSE vs LICENSE ... Signed-off-by: Sebastian Kemper --- include/package-defaults.mk | 1 + include/package-ipkg.mk | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/include/package-defaults.mk b/include/package-defaults.mk index 2fed72b1a4..2a04bc17e9 100644 --- a/include/package-defaults.mk +++ b/include/package-defaults.mk @@ -59,6 +59,7 @@ define Package/Default ALTERNATIVES:= LICENSE:=$(PKG_LICENSE) LICENSE_FILES:=$(PKG_LICENSE_FILES) + FILE_MODES:=$(PKG_FILE_MODES) endef Build/Patch:=$(Build/Patch/Default) diff --git a/include/package-ipkg.mk b/include/package-ipkg.mk index 62cda5b936..0bca8ae84d 100644 --- a/include/package-ipkg.mk +++ b/include/package-ipkg.mk @@ -260,7 +260,7 @@ $(_endef) endif $(INSTALL_DIR) $$(PDIR_$(1)) - $(FAKEROOT) $(SCRIPT_DIR)/ipkg-build -m "$(PKG_FILE_MODES)" $$(IDIR_$(1)) $$(PDIR_$(1)) + $(FAKEROOT) $(SCRIPT_DIR)/ipkg-build -m "$(FILE_MODES)" $$(IDIR_$(1)) $$(PDIR_$(1)) @[ -f $$(IPKG_$(1)) ] $(1)-clean: -- 2.26.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] util-linux: fix build when libmagic is present
On Tue, Sep 01, 2020 at 03:37:03PM -0700, Rosen Penev wrote: > Signed-off-by: Rosen Penev > --- Acked-by: Sebastian Kemper Please apply to get util-linux building. We need libuuid for telephony and others :-) Regards, Seb > package/utils/util-linux/Makefile | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/package/utils/util-linux/Makefile > b/package/utils/util-linux/Makefile > index 0fc9819c58..05ceaa413e 100644 > --- a/package/utils/util-linux/Makefile > +++ b/package/utils/util-linux/Makefile > @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk > > PKG_NAME:=util-linux > PKG_VERSION:=2.36 > -PKG_RELEASE:=1 > +PKG_RELEASE:=2 > > PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz > PKG_SOURCE_URL:=@KERNEL/linux/utils/$(PKG_NAME)/v2.36 > @@ -526,6 +526,7 @@ CONFIGURE_ARGS += \ > --without-python\ > --without-udev \ > --without-readline \ > + --without-libmagic \ > --with-ncursesw > > TARGET_CFLAGS += $(FPIC) -std=gnu99 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ltq-vmmc: update permission handling
This commit addresses two permission issues.
1. The firmware is currently just copied. It can end up with o= on the
device (this is the case for voice_ar9_firmware.bin for instance).
Instead of copying it the Makefile is changed to use the macro
"$(INSTALL_DATA)" in order for the file to be world-readable.
2. A configuration file /etc/config/vmmc is added and the init script
updated accordingly, to allow changing the group of the device nodes.
Like this applications running as non-root may access the device
nodes after the user changes the configuration to the appropriate
group (for instance "asterisk"). Currently asterisk users update
init scripts to fix the permissions. With a configuration option the
user experience is easier and more straight-forward.
Signed-off-by: Sebastian Kemper
---
package/kernel/lantiq/ltq-vmmc/Makefile | 7 +++---
.../kernel/lantiq/ltq-vmmc/files/vmmc.conf| 6 +
.../kernel/lantiq/ltq-vmmc/files/vmmc.init| 25 +++
3 files changed, 24 insertions(+), 14 deletions(-)
create mode 100644 package/kernel/lantiq/ltq-vmmc/files/vmmc.conf
diff --git a/package/kernel/lantiq/ltq-vmmc/Makefile
b/package/kernel/lantiq/ltq-vmmc/Makefile
index 99263cce43..a1ea142925 100644
--- a/package/kernel/lantiq/ltq-vmmc/Makefile
+++ b/package/kernel/lantiq/ltq-vmmc/Makefile
@@ -10,7 +10,7 @@ include $(INCLUDE_DIR)/kernel.mk
PKG_NAME:=drv_vmmc
PKG_VERSION:=1.9.0
-PKG_RELEASE:=3
+PKG_RELEASE:=4
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
PKG_HASH:=707f515eb727c032418c4da67d7e86884bb56cdc2a606e8f6ded6057d8767e57
@@ -168,9 +168,10 @@ define Build/InstallDev
endef
define KernelPackage/ltq-vmmc/install
- $(INSTALL_DIR) $(1)/etc/init.d $(1)/$(FW_DIR)
+ $(INSTALL_DIR) $(1)/etc/config $(1)/etc/init.d $(1)/$(FW_DIR)
$(INSTALL_BIN) ./files/vmmc.init $(1)/etc/init.d/vmmc
- $(CP) $(PKG_BUILD_DIR)/firmware/$(FW_SOURCE) $(1)/$(FW_DIR)/$(FW_TARGET)
+ $(INSTALL_CONF) ./files/vmmc.conf $(1)/etc/config/vmmc
+ $(INSTALL_DATA) $(PKG_BUILD_DIR)/firmware/$(FW_SOURCE)
$(1)/$(FW_DIR)/$(FW_TARGET)
ln -s /$(FW_DIR)/$(FW_TARGET) $(1)/$(FW_DIR)/$(FW_TARGET_GENERIC)
$(CP) $(PKG_BUILD_DIR)/coef/$(COEF_SRC) $(1)/$(FW_DIR)/$(COEF_TARGET)
$(CP) $(PKG_BUILD_DIR)/coef/$(COEF_SRC_FXO)
$(1)/$(FW_DIR)/$(COEF_TARGET_FXO)
diff --git a/package/kernel/lantiq/ltq-vmmc/files/vmmc.conf
b/package/kernel/lantiq/ltq-vmmc/files/vmmc.conf
new file mode 100644
index 00..80abe58d79
--- /dev/null
+++ b/package/kernel/lantiq/ltq-vmmc/files/vmmc.conf
@@ -0,0 +1,6 @@
+# /dev/vmmc* nodes are by default created with ownership root:root. With
+# the below setting the group can be changed, so that software like
+# asterisk not running as root can properly access the hardware.
+
+config vmmc 'nodes'
+ #option group "asterisk"
diff --git a/package/kernel/lantiq/ltq-vmmc/files/vmmc.init
b/package/kernel/lantiq/ltq-vmmc/files/vmmc.init
index 100a97dc45..3734fcecb3 100644
--- a/package/kernel/lantiq/ltq-vmmc/files/vmmc.init
+++ b/package/kernel/lantiq/ltq-vmmc/files/vmmc.init
@@ -5,15 +5,18 @@
START=31
start() {
- [ ! -c /dev/vmmc10 ] && {
- mknod /dev/vmmc10 c 122 10
- mknod /dev/vmmc11 c 122 11
- mknod /dev/vmmc12 c 122 12
- mknod /dev/vmmc13 c 122 13
- mknod /dev/vmmc14 c 122 14
- mknod /dev/vmmc15 c 122 15
- mknod /dev/vmmc16 c 122 16
- mknod /dev/vmmc17 c 122 17
- mknod /dev/vmmc18 c 122 18
- }
+ config_load vmmc
+ config_get GROUP nodes group ""
+
+ if [ -n "$GROUP" ]; then
+ group_exists "$GROUP" || GROUP=
+ fi
+
+ for i in 10 11 12 13 14 15 16 17 18; do
+ if ! [ -e /dev/vmmc$i ]; then
+ mknod -m 664 /dev/vmmc$i c 122 $i
+ [ -n "$GROUP" ] && [ -c /dev/vmmc$i ] && \
+ chown :"$GROUP" /dev/vmmc$i
+ fi
+ done
}
--
2.26.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Strongswan compile fails since connmark related commits in OpenWrt
On Sat, Mar 21, 2020 at 09:38:27AM +, Kevin 'ldir' Darbyshire-Bryant
wrote:
> Hi Sebastian,
>
> I’ve just done a fix for this. Just waiting for a build to complete
> before I push it.
>
> In essence, the kernel hack patches for 4.19 were copied to 5.4. The
> patch in 4.19 was fixed but the one in 5.4 got forgotten about, since
> no one was actually building with a 5.4 kernel till now.
Thanks for looking into this!
> What I really don’t understand as the author of the patch is quite how
> the old header syntax still exists, since the version of patches I
> sent upstream has the fix….and in theory I backported those updates to
> openwrt.
>
> If you can’t wait then tweak
> hack-5.4/645-netfilter-connmark-introduce-set-dscpmark.patch:
No need, I was just seeing the failures on the build bots in the past
weeks and thought I should highlight them.
Thanks!
> diff --git
> a/target/linux/generic/hack-5.4/645-netfilter-connmark-introduce-set-dscpmark.patch
>
> b/target/linux/generic/hack-5.4/645-netfilter-connmark-introduce-set-dscpmark.patch
> index f5ca1bef6e..2d3fe01a75 100644
> ---
> a/target/linux/generic/hack-5.4/645-netfilter-connmark-introduce-set-dscpmark.patch
> +++
> b/target/linux/generic/hack-5.4/645-netfilter-connmark-introduce-set-dscpmark.patch
> @@ -87,8 +87,8 @@ Signed-off-by: Kevin Darbyshire-Bryant
>
> };
>
> enum {
> -+ XT_CONNMARK_VALUE = BIT(0),
> -+ XT_CONNMARK_DSCP = BIT(1)
> ++ XT_CONNMARK_VALUE = (1 << 0),
> ++ XT_CONNMARK_DSCP = (1 << 1)
> +};
> +
> +enum {
>
> Apologies for the inconvenience.
>
> Kevin
>
> > On 21 Mar 2020, at 09:13, Sebastian Kemper wrote:
> >
> > Hi all,
> >
> > strongswan fails to compile since many weeks:
> >
> > In file included from
> > /builder/shared-workdir/build/sdk/staging_dir/toolchain-aarch64_cortex-a53_gcc-8.4.0_musl/include/linux/netfilter/xt_CONNMARK.h:5,
> > from connmark_listener.c:30:
> > /builder/shared-workdir/build/sdk/staging_dir/toolchain-aarch64_cortex-a53_gcc-8.4.0_musl/include/linux/netfilter/xt_connmark.h:23:2:
> > error: enumerator value for 'XT_CONNMARK_VALUE' is not an integer constant
> > XT_CONNMARK_VALUE = BIT(0),
> > ^
> > /builder/shared-workdir/build/sdk/staging_dir/toolchain-aarch64_cortex-a53_gcc-8.4.0_musl/include/linux/netfilter/xt_connmark.h:25:1:
> > error: enumerator value for 'XT_CONNMARK_DSCP' is not an integer constant
> > };
> > ^
> >
> > Full log example:
> >
> > https://downloads.openwrt.org/snapshots/faillogs/aarch64_cortex-a53/packages/strongswan/compile.txt
> >
> > I think that this build failure is related to one of the following commits:
> >
> > https://github.com/openwrt/openwrt/commit/e481df07fa6599e18a0570acb4dadabc56299b7b
> > https://github.com/openwrt/openwrt/commit/a1cfe0dcbb242ab440af6801e223ebde540ed90f
> >
> > (probably the second one)
> >
> > Maybe anybody can take a look at this?
> >
> > If you want me to raise an issue in Flyspray let me know.
> >
> > Kind regards,
> > Seb
>
>
> Cheers,
>
> Kevin D-B
>
> gpg: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Strongswan compile fails since connmark related commits in OpenWrt
Hi all, strongswan fails to compile since many weeks: In file included from /builder/shared-workdir/build/sdk/staging_dir/toolchain-aarch64_cortex-a53_gcc-8.4.0_musl/include/linux/netfilter/xt_CONNMARK.h:5, from connmark_listener.c:30: /builder/shared-workdir/build/sdk/staging_dir/toolchain-aarch64_cortex-a53_gcc-8.4.0_musl/include/linux/netfilter/xt_connmark.h:23:2: error: enumerator value for 'XT_CONNMARK_VALUE' is not an integer constant XT_CONNMARK_VALUE = BIT(0), ^ /builder/shared-workdir/build/sdk/staging_dir/toolchain-aarch64_cortex-a53_gcc-8.4.0_musl/include/linux/netfilter/xt_connmark.h:25:1: error: enumerator value for 'XT_CONNMARK_DSCP' is not an integer constant }; ^ Full log example: https://downloads.openwrt.org/snapshots/faillogs/aarch64_cortex-a53/packages/strongswan/compile.txt I think that this build failure is related to one of the following commits: https://github.com/openwrt/openwrt/commit/e481df07fa6599e18a0570acb4dadabc56299b7b https://github.com/openwrt/openwrt/commit/a1cfe0dcbb242ab440af6801e223ebde540ed90f (probably the second one) Maybe anybody can take a look at this? If you want me to raise an issue in Flyspray let me know. Kind regards, Seb ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] cryptodev-linux: Fix error when compiling with 5.4 kernel
On Tue, Mar 17, 2020 at 10:27:13PM +0800, Jeffery To wrote:
> Currently, cryptodev-linux fails to compile with a
> '"crypto_givcipher_type" undefined' error for targets on the 5.4 kernel,
> e.g. armvirt[1].
>
> This backports an upstream patch[2] that fixes this error.
>
> [1]:
> https://downloads.openwrt.org/snapshots/faillogs/aarch64_generic/base/cryptodev-linux/compile.txt
> [2]:
> https://github.com/cryptodev-linux/cryptodev-linux/commit/f971e0cd4a0ebe59fb2e8e17240399bf6901b09b
>
> Signed-off-by: Jeffery To
Acked-by: Sebastian Kemper
Hi all,
Please include this. With kernel 5.4 cryptodev currently fails on the
bots. And when cryptodev fails then openssl fails as well and so on and
so forth.
Thanks!
Seb
> ---
> package/kernel/cryptodev-linux/Makefile | 2 +-
> ...x-module-loading-with-Linux-v5.0-rc5.patch | 50 +++
> 2 files changed, 51 insertions(+), 1 deletion(-)
> create mode 100644
> package/kernel/cryptodev-linux/patches/010-Fix-module-loading-with-Linux-v5.0-rc5.patch
>
> diff --git a/package/kernel/cryptodev-linux/Makefile
> b/package/kernel/cryptodev-linux/Makefile
> index da18c714b0..9bea63ebd1 100644
> --- a/package/kernel/cryptodev-linux/Makefile
> +++ b/package/kernel/cryptodev-linux/Makefile
> @@ -11,7 +11,7 @@ include $(INCLUDE_DIR)/kernel.mk
>
> PKG_NAME:=cryptodev-linux
> PKG_VERSION:=1.10
> -PKG_RELEASE:=1
> +PKG_RELEASE:=2
>
>
> PKG_SOURCE_URL:=https://codeload.github.com/$(PKG_NAME)/$(PKG_NAME)/tar.gz/$(PKG_NAME)-$(PKG_VERSION)?
> PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
> diff --git
> a/package/kernel/cryptodev-linux/patches/010-Fix-module-loading-with-Linux-v5.0-rc5.patch
>
> b/package/kernel/cryptodev-linux/patches/010-Fix-module-loading-with-Linux-v5.0-rc5.patch
> new file mode 100644
> index 00..5909f6dfb3
> --- /dev/null
> +++
> b/package/kernel/cryptodev-linux/patches/010-Fix-module-loading-with-Linux-v5.0-rc5.patch
> @@ -0,0 +1,50 @@
> +From f971e0cd4a0ebe59fb2e8e17240399bf6901b09b Mon Sep 17 00:00:00 2001
> +From: "Derald D. Woods"
> +Date: Sun, 10 Feb 2019 13:22:19 -0600
> +Subject: [PATCH] Fix module loading with Linux v5.0-rc5
> +
> +This commit fixes this module load error:
> +[...]
> +[ 29.112091] cryptodev: loading out-of-tree module taints kernel.
> +[ 29.128906] cryptodev: Unknown symbol crypto_givcipher_type (err -2)
> +[ 29.188842] cryptodev: Unknown symbol crypto_givcipher_type (err -2)
> +modprobe: can't load module cryptodev (extra/cryptodev.ko): unknown symbol
> in module, or unknown parameter
> +[...]
> +
> +Upstream Linux support for unused GIVCIPHER, and others, was dropped here:
> +
> +c79b411eaa72 (crypto: skcipher - remove remnants of internal IV generators)
> +
> +Signed-off-by: Derald D. Woods
> +---
> + cryptlib.c | 9 +++--
> + 1 file changed, 7 insertions(+), 2 deletions(-)
> +
> +diff --git a/cryptlib.c b/cryptlib.c
> +index 6e66698..4a87037 100644
> +--- a/cryptlib.c
> b/cryptlib.c
> +@@ -38,7 +38,9 @@
> + #include "cryptodev_int.h"
> + #include "cipherapi.h"
> +
> ++#if (LINUX_VERSION_CODE < KERNEL_VERSION(5, 0, 0))
> + extern const struct crypto_type crypto_givcipher_type;
> ++#endif
> +
> + static void cryptodev_complete(struct crypto_async_request *req, int err)
> + {
> +@@ -157,8 +159,11 @@ int cryptodev_cipher_init(struct cipher_data *out,
> const char *alg_name,
> +
> + #if (LINUX_VERSION_CODE >= KERNEL_VERSION(4, 8, 0))
> + tfm = crypto_skcipher_tfm(out->async.s);
> +-if ((tfm->__crt_alg->cra_type == _ablkcipher_type) ||
> +-(tfm->__crt_alg->cra_type == _givcipher_type)) {
> ++if ((tfm->__crt_alg->cra_type == _ablkcipher_type)
> ++#if (LINUX_VERSION_CODE < KERNEL_VERSION(5, 0, 0))
> ++|| (tfm->__crt_alg->cra_type == _givcipher_type)
> ++#endif
> ++) {
> + struct ablkcipher_alg *alg;
> +
> + alg = >__crt_alg->cra_ablkcipher;
> --
> 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
Re: [OpenWrt-Devel] [PATCH] cmake: Install host packages to lib instead of lib64
On Sun, Nov 17, 2019 at 01:42:04PM -0800, Rosen Penev wrote: > Several CMake packages such as log4cplus and protobuf(-c) install to > lib64 instead of lib on some hosts. This completely breaks rpath linking. > Override it globally to avoid fixing each package individually. > > Signed-off-by: Rosen Penev > --- > include/cmake.mk | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/include/cmake.mk b/include/cmake.mk > index a304ab3f70..2726b83a1e 100644 > --- a/include/cmake.mk > +++ b/include/cmake.mk > @@ -103,6 +103,7 @@ define Host/Configure/Default > -DCMAKE_INSTALL_PREFIX=$(HOST_BUILD_PREFIX) \ > -DCMAKE_PREFIX_PATH=$(HOST_BUILD_PREFIX) \ > -DCMAKE_SKIP_RPATH=TRUE \ > + -DCMAKE_INSTALL_LIBDIR=lib \ > $(CMAKE_HOST_OPTIONS) \ > $(HOST_CMAKE_SOURCE_DIR) \ > ) This works fine and solves the problem, tested with protobuf/host. Thanks Rosen! Tested-by: Sebastian Kemper ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] The meaning of Signed-off-by for netifd [Was: Re: [PATCH netifd] interface: warn if ip6hint is truncated]
On Tue, Dec 03, 2019 at 03:59:18PM +0100, Uwe Kleine-König wrote: > > ok, so you claim my SoB means that *I* confirmed that my change is > compatible to the netifd's license. I didn't do that though. > > Even if it was me who added that line I doubt is has any relevance for > netifd because nothing in the netifd sources explains what an SoB means. > And the link you sent applies only to patches for openwrt, not netifd. > (Also if this is the only place for openwrt where the significance of an > SoB is described I wonder if this is relevant given that from the POV of > openwrt.git the wiki is an external resource that can be modified by > anyone. What if someone removes item (d) from the wiki or introduces an > (e)?) Hi Uwe, The OpenWrt "Submitting patches" article links to https://www.kernel.org/doc/html/latest/process/submitting-patches.html. There the sign-off (and the reasons for it) is explained a bit more. So it seems OpenWrt is just following kernel.org's example. Which is fine in my opinion. Regarding somebody adding the sign-off _for_ you I share your opinion. It has to be _your_ sign-off, so if a third party adds it for you this is not correct. I didn't really think about this before reading your mail. So thanks for highlighting this. Regards, Seb > Don't get me wrong, my patch is compatible to netifd's license. But if > you want that netifd's license situation stays reasonably safe and > clean, it IMHO cannot be that you add a SoB for someone else, and give > that SoB a meaning that isn't documented for your project and assumes > things about that someone else that you cannot know for sure. So if you > require a formalism, please formalize it properly. (Of course INAL, but > that's my understanding of how open source licensing works.) > > Best regards > Uwe ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/1] mac80211: add default value for noscan
Hi all, Would be nice if this could be fixed in 19.07 branch as well (which is where I first saw the warning). Kind regards, Seb ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/1] mac80211: add default value for noscan
Commit b3d8b3a introduced a new test:
[ -n "$noscan" -a "$noscan" -gt 0 ] && hostapd_noscan=1
But if length of "$noscan" is zero (noscan is not set) this doesn't stop
the shell to evaluate the rest of the test.
root@hank2:~# [ -n "$noscan" -a "$noscan" -gt 0 ]
ash: out of range
root@hank2:~#
So when radios are brought up this shows in the log:
Sat Nov 23 10:51:38 2019 daemon.info procd: - init complete -
Sat Nov 23 10:52:24 2019 daemon.notice netifd: radio1 (1243): sh: out of range
Sat Nov 23 10:52:25 2019 user.notice firewall: Reloading firewall due to ifup
of wan (eth0.2)
Sat Nov 23 10:52:25 2019 daemon.notice netifd: radio0 (1242): sh: out of range
Sat Nov 23 10:52:26 2019 authpriv.info dropbear[1536]: Not backgrounding
This commit sets noscan to 0 if unset and removes the gratuitous length
check, preventing the warning.
Signed-off-by: Sebastian Kemper
---
package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
index a04f1e3ca7..5c67ea0600 100644
--- a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
+++ b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
@@ -106,7 +106,9 @@ mac80211_hostapd_setup_base() {
json_get_vars noscan ht_coex
json_get_values ht_capab_list ht_capab tx_burst
- [ -n "$noscan" -a "$noscan" -gt 0 ] && hostapd_noscan=1
+ set_default noscan 0
+
+ [ "$noscan" -gt 0 ] && hostapd_noscan=1
[ "$tx_burst" = 0 ] && tx_burst=
ieee80211n=1
--
2.23.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] rules.mk: remove "$(STAGING_DIR)/include"
On Fri, Nov 01, 2019 at 01:04:04PM -0700, Rosen Penev wrote: > On Fri, Nov 1, 2019 at 12:21 PM Sebastian Kemper wrote: > > > > On Fri, Nov 01, 2019 at 12:06:39PM -0700, Rosen Penev wrote: > > > Would it also make sense to remove $(STAGING_DIR)/lib ? Locally, it > > > seems libpam gets installed there (probably a bug). > > > > Quoting FHS 3.0 regarding /lib's purpose: "The /lib directory contains > > those shared library images needed to boot the system and run the > > commands in the root filesystem, ie. by binaries in /bin and /sbin." > > > > I think /lib should stay. > OTOH, many modern distros just symlink everything to /usr. Good morning Rosen, I did not want to imply that OpenWrt follows FHS, I don't know about that. I just think having /lib and /bin around makes much more sense than /include. Kind regards, Seb > Anyway, > > Acked-by: Rosen Penev > > > > Regards, > > Seb > > ___ > 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] rules.mk: remove "$(STAGING_DIR)/include"
On Fri, Nov 01, 2019 at 12:06:39PM -0700, Rosen Penev wrote: > Would it also make sense to remove $(STAGING_DIR)/lib ? Locally, it > seems libpam gets installed there (probably a bug). Quoting FHS 3.0 regarding /lib's purpose: "The /lib directory contains those shared library images needed to boot the system and run the commands in the root filesystem, ie. by binaries in /bin and /sbin." I think /lib should stay. Regards, Seb ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] rules.mk: remove "$(STAGING_DIR)/include"
"$(STAGING_DIR)/include" was carried over from buildroot-ng to OpenWrt in commit 60c1f0f64d23003a19a07d6b9638542130f6641d. buildroot has dropped this directory a long time ago. In OpenWrt the directory is still created by the PrepareStaging macro and is part of the default TARGET_CPPFLAGS. But nothing at all installs headers into this directory, nor should anything be installed under this path. Removing this directory from TARGET_CPPFLAGS will cut down the log noise a bit. Not only will CPPFLAGS be shorter, there will be less warnings set off by "-Wmissing-include-dirs" (or even failures when paired with "-Werror"). After all the directory does not even _exist_ in the SDKs, which are used on the build bots when building packages (see [1] and [2]). make[8]: Entering directory '/builder/shared-workdir/build/sdk/build_dir/target-aarch64_generic_musl/libmbim-1.20.0/src/common' CC libmbim_common_la-mbim-common.lo cc1: error: /builder/shared-workdir/build/sdk/staging_dir/target-aarch64_generic_musl/include: No such file or directory [-Werror=missing-include-dirs] cc1: all warnings being treated as errors [1] https://github.com/openwrt/packages/issues/10377 [2] https://github.com/openwrt/packages/pull/10378 Signed-off-by: Sebastian Kemper --- rules.mk | 2 +- tools/Makefile | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/rules.mk b/rules.mk index fbf42f725d..66ddea2883 100644 --- a/rules.mk +++ b/rules.mk @@ -174,7 +174,7 @@ TARGET_CFLAGS:=$(TARGET_OPTIMIZATION)$(if $(CONFIG_DEBUG), -g3) $(call qstrip,$( TARGET_CXXFLAGS = $(TARGET_CFLAGS) TARGET_ASFLAGS_DEFAULT = $(TARGET_CFLAGS) TARGET_ASFLAGS = $(TARGET_ASFLAGS_DEFAULT) -TARGET_CPPFLAGS:=-I$(STAGING_DIR)/usr/include -I$(STAGING_DIR)/include +TARGET_CPPFLAGS:=-I$(STAGING_DIR)/usr/include TARGET_LDFLAGS:=-L$(STAGING_DIR)/usr/lib -L$(STAGING_DIR)/lib ifneq ($(CONFIG_EXTERNAL_TOOLCHAIN),) LIBGCC_S_PATH=$(realpath $(wildcard $(call qstrip,$(CONFIG_LIBGCC_ROOT_DIR))/$(call qstrip,$(CONFIG_LIBGCC_FILE_SPEC diff --git a/tools/Makefile b/tools/Makefile index 23671cba91..2f57d25525 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -123,7 +123,7 @@ define PrepareStaging $(if $(QUIET),,set -x;) \ mkdir -p "$$dir"; \ cd "$$dir"; \ - mkdir -p bin lib include stamp; \ + mkdir -p bin lib stamp; \ ); done endef -- 2.23.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [openwrt/telephony 1/2] asterisk16-chan-lantiq: Use upstream sources from 2019-09-03
Apart from what I wrote earlier, this mailing list is not the right forum to send patches for the telephony repo (same is valid for the packages repo). Please send patches for telephony or packages via Github pull request. Kind regards, Sebastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [openwrt/telephony 1/2] asterisk16-chan-lantiq: Use upstream sources from 2019-09-03
On Sat, Aug 03, 2019 at 05:13:55PM +0200, Arnold Schulz wrote:
> This solves:
> - Fix build failure due to missing telephony.h in kernel 4.19 sources
> - OpenWrt specific patch+file removed; this stuff is now in upstream
>
> Signed-off-by: Arnold Schulz
> ---
> net/asterisk-16.x-chan-lantiq/Makefile| 16 +++
> .../files/default.exports | 8
> ...-ast_free-instead-of-malloc-and-free.patch | 43 ---
> 3 files changed, 5 insertions(+), 62 deletions(-)
> delete mode 100644 net/asterisk-16.x-chan-lantiq/files/default.exports
> delete mode 100644
> net/asterisk-16.x-chan-lantiq/patches/01-Use-ast_malloc-and-ast_free-instead-of-malloc-and-free.patch
>
> diff --git a/net/asterisk-16.x-chan-lantiq/Makefile
> b/net/asterisk-16.x-chan-lantiq/Makefile
> index 5884673..8210c07 100644
> --- a/net/asterisk-16.x-chan-lantiq/Makefile
> +++ b/net/asterisk-16.x-chan-lantiq/Makefile
> @@ -1,5 +1,5 @@
> #
> -# Copyright (C) 2018 OpenWrt.org
> +# Copyright (C) 2018-2019 OpenWrt.org
Are you a member of OpenWrt? Only members should should change OpenWrt
copyright message.
> #
> # This is free software, licensed under the GNU General Public License v2.
> # See /LICENSE for more information.
> @@ -8,14 +8,14 @@
> include $(TOPDIR)/rules.mk
>
> PKG_NAME:=asterisk16-chan-lantiq
> -PKG_VERSION:=20180215
> -PKG_RELEASE:=2
> +PKG_VERSION:=20190803
> +PKG_RELEASE:=1
>
> PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
> PKG_SOURCE_URL:=https://github.com/kochstefan/asterisk_channel_lantiq.git
> PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
> -PKG_SOURCE_VERSION:=c9d68dd06fcd46ac7985df45f8c2b8833e658f8e
> -PKG_MIRROR_HASH:=8666c18b24adf9da3ddf12306fcf0a8b4f56860c256b172bd0ba5c2a7a3ab25e
> +PKG_SOURCE_VERSION:=1d940b38cde0348dfe129d2b764e6faee440c45b
> +PKG_MIRROR_HASH:=ff838ff2a4c5353fadd73806e1513f59f224914582b6ba004165712268bc94e5
> PKG_SOURCE_PROTO:=git
>
> PKG_LICENSE:=GPL-2.0
> @@ -43,12 +43,6 @@ define Package/$(PKG_NAME)/conffiles
> /etc/asterisk/lantiq.conf
> endef
>
> -define Build/Prepare
> - $(call Build/Prepare/Default)
> - $(INSTALL_DATA) ./files/default.exports \
> - $(PKG_BUILD_DIR)/src/channels/chan_lantiq.exports
> -endef
> -
Why remove this? I put this in to recreate what happens during an
in-tree build (adding chan-lantig files into Asterisk source tree and
compiling it with Asterisk).
> define Build/Compile
> cd $(PKG_BUILD_DIR)/src/channels && \
> $(TARGET_CC) -o chan_lantiq.o -c chan_lantiq.c -MD -MT chan_lantiq.o \
> diff --git a/net/asterisk-16.x-chan-lantiq/files/default.exports
> b/net/asterisk-16.x-chan-lantiq/files/default.exports
> deleted file mode 100644
> index 6d9344d..000
> --- a/net/asterisk-16.x-chan-lantiq/files/default.exports
> +++ /dev/null
> @@ -1,8 +0,0 @@
> -{
> - global:
> - /* See main/asterisk.exports.in for an explanation why this is
> - * needed. */
> - _IO_stdin_used;
> - local:
> - *;
> -};
> diff --git
> a/net/asterisk-16.x-chan-lantiq/patches/01-Use-ast_malloc-and-ast_free-instead-of-malloc-and-free.patch
>
> b/net/asterisk-16.x-chan-lantiq/patches/01-Use-ast_malloc-and-ast_free-instead-of-malloc-and-free.patch
> deleted file mode 100644
> index f913b18..000
> ---
> a/net/asterisk-16.x-chan-lantiq/patches/01-Use-ast_malloc-and-ast_free-instead-of-malloc-and-free.patch
> +++ /dev/null
> @@ -1,43 +0,0 @@
> -commit 30f9a094c1c60e0d68e4ea189f48ecb47aebb485
> -Author: arny
> -Date: Thu May 2 20:07:28 2019 +0200
> -
> -Use ast_malloc and ast_free instead of malloc and free
> -in order to get rid of build errors with asterisk16 in OpenWrt
> -
> -Signed-off-by: arny
> -
> -diff --git a/src/channels/chan_lantiq.c b/src/channels/chan_lantiq.c
> -index a8fc869..90002ab 100644
> a/src/channels/chan_lantiq.c
> -+++ b/src/channels/chan_lantiq.c
> -@@ -563,9 +563,9 @@ lantiq_dev_binary_buffer_create(const char *path,
> uint8_t **ppBuf, uint32_t *pBu
> - goto on_exit;
> - }
> -
> --*ppBuf = malloc(file_stat.st_size);
> -+*ppBuf = ast_malloc(file_stat.st_size);
> - if (*ppBuf == NULL) {
> --ast_log(LOG_ERROR, "binary file %s memory allocation failed\n",
> path);
> -+// Message already logged by ast_malloc
> - goto on_exit;
> - }
> -
> -@@ -583,7 +583,7 @@ on_exit:
> - fclose(fd);
> -
> - if (*ppBuf != NULL && status)
> --free(*ppBuf);
> -+ast_free(*ppBuf);
> -
> - return status;
> - }
> -@@ -609,7 +609,7 @@ static int32_t lantiq_dev_firmware_download(int32_t fd,
> const char *path)
> - }
> -
> - if (firmware != NULL)
> --free(firmware);
> -+ast_free(firmware);
> -
> - return 0;
> - }
> --
> 2.20.1
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
>
Re: [OpenWrt-Devel] [openwrt/telephony 2/2] asterisk16-chan-lantiq: Move menu item into the asterisk16 menu
On Sat, Aug 03, 2019 at 05:13:56PM +0200, Arnold Schulz wrote: > This is now the same behaviour as used by the external asterisk > packages asterisk-chan-dongle and asterisk-chan-sccp. > > Signed-off-by: Arnold Schulz > --- > net/asterisk-16.x-chan-lantiq/Makefile | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/net/asterisk-16.x-chan-lantiq/Makefile > b/net/asterisk-16.x-chan-lantiq/Makefile > index 8210c07..55c1c35 100644 > --- a/net/asterisk-16.x-chan-lantiq/Makefile > +++ b/net/asterisk-16.x-chan-lantiq/Makefile > @@ -27,12 +27,12 @@ PKG_FLAGS:=nonshared > include $(INCLUDE_DIR)/package.mk > > define Package/$(PKG_NAME) > - SUBMENU:=Telephony Lantiq > + SUBMENU:=Telephony >SECTION:=net >CATEGORY:=Network >TITLE:=Lantiq channel driver >URL:=https://github.com/kochstefan/asterisk_channel_lantiq > - DEPENDS:=+asterisk16 +kmod-ltq-vmmc > + DEPENDS:=asterisk16 +kmod-ltq-vmmc > endef Hi Arnold, Please see commit 8dd77211e025709bef36d4994fcf08ccc9107422. With your patch chan-lantiq would again not be built by the buildbots. I know that the extra submenu isn't nice. But we need the '+asterisk' dep for the build bots to build the package. And when you stick chan-lantiq into the Telephony submenu with its depend '+asterisk' then menuconfig looks even stranger. NACK from me. Kind regards, Seb > > define Package/$(PKG_NAME)/description > -- > 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Why ath79 has been made source-only on 19.07?
On Mon, Jul 29, 2019 at 05:14:09PM +, Sebastian Kemper wrote: > Am July 29, 2019 4:30:33 PM UTC schrieb Dmitry Tunin > : > >There is also a few devices that have been recently added as ath79 > >only. So they won't be supported. > > > >пн, 29 июл. 2019 г. в 19:28, Dmitry Tunin : > >> > >> 2b074654b0f259518aa56e0975ca8e26c0c12bc9 > >> > >> I see no reason why not to build both ar71xx and ath79 for devices > >> that have been ported to ath79 already. Many people already use > >> 19.07 branch and wait for the release. > >> > >> That will require lots of custom builds. What is the point of > >excluding ath79? > > Good points. I'd like to see ath79 builds for 19.07 as well. And even > if that means more stress on the build bots it'd be only every point > release, not constantly. At least that's my understanding. > > Just my opinion. I don't have voting rights :-) > > Kind regards, > Seb Also having ath79 builds would likely result in some additional feedback (about something that doesn't work on ath79 but does work on ar71xx). ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Why ath79 has been made source-only on 19.07?
Am July 29, 2019 4:30:33 PM UTC schrieb Dmitry Tunin : >There is also a few devices that have been recently added as ath79 >only. So they won't be supported. > >пн, 29 июл. 2019 г. в 19:28, Dmitry Tunin : >> >> 2b074654b0f259518aa56e0975ca8e26c0c12bc9 >> >> I see no reason why not to build both ar71xx and ath79 for devices >> that have been ported to ath79 already. Many people already use 19.07 >> branch and wait for the release. >> >> That will require lots of custom builds. What is the point of >excluding ath79? > >___ >openwrt-devel mailing list >openwrt-devel@lists.openwrt.org >https://lists.openwrt.org/mailman/listinfo/openwrt-devel Good points. I'd like to see ath79 builds for 19.07 as well. And even if that means more stress on the build bots it'd be only every point release, not constantly. At least that's my understanding. Just my opinion. I don't have voting rights :-) Kind regards, Seb ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] sqlite3: bump to 3270100
Hello 紫 昕, Can you please send a pull request via github? Kind regards, Seb ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath79: seting GPIO registers to specific values via DTS?
On Sun, Dec 16, 2018 at 06:23:53PM +0100, Roger Pueyo Centelles | Guifi.net
wrote:
>
>
> Hi,
Hello Roger!
> [...]
>
> leds {
> compatible = "gpio-leds";
> pinctrl-1 = <_rssilow_pin _rssimediumhigh_pin
> _rssihigh_pin>;
>
> [...]
>
> {
> led_rssilow_pin: pinmux_rssilow_pin {
> pinctrl-single,bits = <0x8 0x0 0xff00>;
> };
>
> led_rssimediumhigh_pin: pinmux_rssimediumhigh_pin {
> pinctrl-single,bits = <0xc 0x0 0x00ff>;
> };
>
> led_rssihigh_pin: pinmux_rssihigh_pin {
> pinctrl-single,bits = <0x10 0x0 0x00ff>;
> };
> };
>
> [...]
The pinmux part looks OK to me. Could you change the leds part to the
below and try again?
leds {
compatible = "gpio-leds";
pinctrl-names = "default";
pinctrl-0 = <_disable_pins _rssilow_pin
_rssimediumhigh_pin _rssihigh_pin>;
[...]
I added the jtag bit because I saw that you use it under keys. You have
to remove
pinctrl-0 = <_disable_pins>;
under keys. Just put them all in one place.
>From my testing, when defining pinctrl-0 and pinctrl-1, the second one
doesn't do anything. For example:
pinctrl-0 = <_disable_pins>; // works
pinctrl-1 = <_gpio_11>; // nothing happens
But
pinctrl-0 = <_disable_pins _gpio_11>; // both are applied - works
Kind regards,
Seb
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] ath79: pinctrl question, ar71xx migration
Hello all,
I'm still working on the dts file for d-link dir-825-c1. I'm trying to
get the usb led to work. Configuring the led with gpio 11 alone is not
enough, the led stays dark, even if it appears in
/sys/kernel/debug/gpio:
gpio-11 (|d-link:blue:usb ) out hi
On ar71xx in the mach file
ath79_gpio_output_select(11, AR934X_GPIO_OUT_GPIO);
is called to make it work. In a chat on irc it was suggested that this
could probably be done with some pinctrl magic, possibly with
"pinctrl-single,bits". But I have trouble coming up with the arguments.
I did an ar71xx compile before which I put some extra printk into
gpio.c:
void __init ath79_gpio_output_select(unsigned gpio, u8 val)
{
printk("Here comes GPIO %u\n", gpio);
printk("t is %u and reg is %u\n", t, reg);
printk("base is %p and base + reg is %p\n", base, base + reg);
__raw_writel(t, base + reg);
/* flush write */
(void) __raw_readl(base + reg);
}
In dmesg I got this:
[0.135479] Here comes GPIO 11
[0.139500] t is 1572864 and reg is 52
[0.145149] base is b804 and base + reg is b8040034
These numbers are the same on every reboot. 1572864 is 0x18.
I checked the mem area's content:
root@OpenWrt:~# devmem 0xb804 64
0x0003131B006FA420
I compiled an image that doesn't call ath79_gpio_output_select(). So usb
led was dark. I checked the same area again:
root@OpenWrt:~# devmem 0xb804 64
0x0003131B006FAC20
But really this doesn't tell me anything :)
Anybody knows if I can use pinctrl to get what I need and how to go
about it?
Thanks for reading!
Best regards,
Seb
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath79 ascii mac + led open drain
Hello all, I seem to have found the ways around this. So never mind. I'll send the dts file when I'm happy with it. Regards, Seb ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] ath79 ascii mac + led open drain
Hi all, I'm trying to get a dlink dir-825-c1 working with a device tree setup. So far it can boot, the partitions are correctly set up, the Ethernet ports seem to work and the wireless devices are coming up. I'm a bit stumped with mac addresses as well as LAN port leds, though. In ar71xx ath79_parse_ascii_mac() is used (for this and some other boards) to get the macs. But I don't see any equivalent in ath79. For now I try to use target/linux/ath79/base-files/etc/board.d/02_network to set the mac addresses like this: dlink,dir-825-c1) lan_mac=$(mtd_get_mac_text "mac" 4) wan_mac=$(mtd_get_mac_text "mac" 24) ;; But currently that doesn't work out. I must be doing something wrong. I think it would be great if something like ath79_parse_ascii_mac() could be added to of_net.c. I'm not a programmer, so for me that would be tough :) Is it possible that somebody please adds this? And the leds from the Ethernet ports are still just dark. I saw that ".open_drain" is set to "true" in the ar71xx mach file. Anybody knows what the equivalent config is in a DTS file? Thanks for reading! Kind regards, Seb ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Disclaimer for user documentation?
On Sat, Jul 28, 2018 at 02:36:20PM +0200, Alberto Bursi wrote: > In other articles where user error might cause issues we placed a banner > on top with a warning, like this > https://openwrt.org/docs/guide-user/network/wan/smartphone.usb.tethering Hello Alberto, Thank you for your input. I put up a warning like that now. > I personally don't think people writing the articles can be blamed > unless the guide they wrote is actually wrong. If users screw up that's > their own responsibility. I agree. But lets say for the sake of argument that a company has an admin who uses your guide to configure his telephony system. And then somebody takes advantage of some configuration issue in your guide and commits toll fraud. Lets say for a couple thousand . The provider will get their money from the company. And the company goes to the admin who then points to your article. Would the company perhaps consider suing you, the author of the guide? > But I don't know the legal side of things, can someone actually sue > OpenWrt or try to go after the contributors if such things happen? Interesting questions. The answers may also be different depending on your location. > If others agree (I'm CCing this mail to other wiki maintainers) I can > add a new "Legal" page with link on the menu on the left where such > disclaimers can be placed. I think a general disclaim-all DISCLAIMER would be handy. > In the meantime you can place any disclaimer you want in the warning box > at the top of your article, and be covered by that. A good starting > point is copy-pasting LineageOS's https://lineageos.org/legal/ I'll not put up a guide right now as the liability situation is uncertain. I'll just provide basic infos about some of the packages. Kind regards, Seb ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Disclaimer for user documentation?
Hi all, I'm adding a page about FreeSWITCH to the OpenWrt user documentation. I would like to add a guide on setting up a configuration to use freeswitch with Ekiga, along the lines of a testing ground for people to use and play around with before they take on other endeavors. But I'm a bit reluctant to do it because if somebody sets up SIP connections wrongly it can cost them money (PBX getting hacked etc.). I don't want any blame for that. Can there maybe be a general disclaimer that disclaims any liability that users adding documentation can link to? I've searched if something like this exists already but didn't find anything. Kind regards, Seb ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] curl: fix build failure due to incorrect IDN dep
curl stopped supporting libidn a while back. The configure script instead looks for libidn2, which was recently added to OpenWrt's package repo. curl will link to it, causing build failures due to the missing dependency, because --without-idn is not recognized anymore. Fix this by amending the dependency from libidn to libidn2 and correcting the configure switches. Signed-off-by: Sebastian Kemper <sebastian...@gmx.net> --- package/network/utils/curl/Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/package/network/utils/curl/Makefile b/package/network/utils/curl/Makefile index 77af54fae8..f1a9f9eb0f 100644 --- a/package/network/utils/curl/Makefile +++ b/package/network/utils/curl/Makefile @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk PKG_NAME:=curl PKG_VERSION:=7.59.0 -PKG_RELEASE:=1 +PKG_RELEASE:=2 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2 PKG_SOURCE_URL:=https://dl.uxnr.de/mirror/curl/ \ @@ -87,7 +87,7 @@ define Package/libcurl SECTION:=libs CATEGORY:=Libraries DEPENDS:= +LIBCURL_WOLFSSL:libwolfssl +LIBCURL_OPENSSL:libopenssl +LIBCURL_GNUTLS:libgnutls +LIBCURL_MBEDTLS:libmbedtls - DEPENDS += +LIBCURL_ZLIB:zlib +LIBCURL_THREADED_RESOLVER:libpthread +LIBCURL_LDAP:libopenldap +LIBCURL_LIBIDN:libidn + DEPENDS += +LIBCURL_ZLIB:zlib +LIBCURL_THREADED_RESOLVER:libpthread +LIBCURL_LDAP:libopenldap +LIBCURL_LIBIDN:libidn2 DEPENDS += +LIBCURL_SSH2:libssh2 +LIBCURL_NGHTTP2:libnghttp2 TITLE:=A client-side URL transfer library MENU:=1 @@ -119,7 +119,7 @@ CONFIGURE_ARGS += \ $(if $(CONFIG_LIBCURL_OPENSSL),--with-ssl="$(STAGING_DIR)/usr" --without-ca-bundle --with-ca-path=/etc/ssl/certs,--without-ssl) \ $(if $(CONFIG_LIBCURL_MBEDTLS),--with-mbedtls="$(STAGING_DIR)/usr" --without-ca-path --with-ca-bundle=/etc/ssl/certs/ca-certificates.crt,--without-mbedtls) \ \ - $(if $(CONFIG_LIBCURL_LIBIDN),--with-libidn="$(STAGING_DIR)/usr",--without-libidn) \ + $(if $(CONFIG_LIBCURL_LIBIDN),--with-libidn2="$(STAGING_DIR)/usr",--without-libidn2) \ $(if $(CONFIG_LIBCURL_SSH2),--with-libssh2="$(STAGING_DIR)/usr",--without-libssh2) \ $(if $(CONFIG_LIBCURL_ZLIB),--with-zlib="$(STAGING_DIR)/usr",--without-zlib) \ $(if $(CONFIG_LIBCURL_NGHTTP2),--with-nghttp2="$(STAGING_DIR)/usr",--without-nghttp2) \ -- 2.16.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] "nonshared" telephony package not being built
(already posted to LEDE dev a few days ago, posting to OpenWrt dev as no response.) Hi all, I'm wondering why a nonshared packages from the telephony feed is ignored by the buildbots. There is asterisk-chan-lantig here: https://github.com/openwrt/telephony/blob/master/net/asterisk-chan-lantiq/Makefile It has: PKG_FLAGS:=nonshared It also has a dependency on kmod-ltq-vmmc. The latter has the following dependencies: DEPENDS:=@(TARGET_lantiq_xway||TARGET_lantiq_xrx200) +kmod-ltq-tapi So I'm thinking that the buildbots should attempt to build asterisk-chan-lantig when building the targets lantiq_xway and lantiq_xrx200. I checked the infra website to try to find some logs. Here's a recent xway build: http://phase1.builds.lede-project.org/builders/lantiq%2Fxway/builds/762 I downloaded the pkgbuild log: http://phase1.builds.lede-project.org/builders/lantiq%2Fxway/builds/762/steps/pkgbuild/logs/stdio I don't find any mention of asterisk-chan-lantig. Why is that? Is it because: - the buildbots ignore nonshared packages from the telephony feed? I can't image this is the case, but I'm asking anyway. - there's something wrong with the Makefile? - it's a VARIANT Makefile? Thanks for your time! Kind regards, Sebastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [packages] ntpd: fix hotplug script
Currently the hotplug script never starts because it assumes the wrong
path to the binary. Fix the path.
Signed-off-by: Sebastian Kemper sebastian...@gmx.net
---
diff --git a/net/ntpd/files/ntpd.hotplug b/net/ntpd/files/ntpd.hotplug
index 992628f..975be75 100644
--- a/net/ntpd/files/ntpd.hotplug
+++ b/net/ntpd/files/ntpd.hotplug
@@ -1,6 +1,6 @@
NAME=ntpd
CONFIG=/etc/ntp.conf
-COMMAND=/usr/sbin/$NAME
+COMMAND=/sbin/$NAME
[ $ACTION = ifup -a $INTERFACE = wan ] {
[ -x $COMMAND ] [ -r $CONFIG ] {
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] BB rc3 includes Luci?
Hello list, On my ar71xx/dir-825-c1 Luci is included in rc3. This was not the case for rc2. Can anybody please point me to the related changeset? I can't seem to find it. Kind regards, Sebastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [ar71xx] fix WAN MAC setup on dir-825-c1
Changeset 38690 broke the WAN MAC setup. Here's the fix. Signed-off-by: Sebastian Kemper sebastian_ml at gmx.net --- diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network index 481d458..cee1328 100755 --- a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network @@ -240,7 +240,7 @@ dir-825-c1) ucidef_add_switch switch0 1 1 ucidef_add_switch_vlan switch0 1 0t 1 2 3 4 ucidef_add_switch_vlan switch0 2 0t 5 - mac=$(mtd_get_mac_ascii nvram ^wan_mac) + mac=$(mtd_get_mac_ascii nvram wan_mac) [ -n $mac ] ucidef_set_interface_macaddr wan $mac ;; ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ar71xx: Backport DIR-825 C1 support to AA
This is a backport to add support for D-Link's DIR-825 rev. C1 to the
Attitude Adjustment branch.
Signed-off-by: Sebastian Kemper sebastian...@gmx.net
---
I don't know with certainty how open the OpenWrt project is towards
backporting a router from trunk to the stable branch. This backport is
tested by myself and works well.
If it's just about the format of the patch, e.g. one big patch versus
multiple smaller patches, I'm willing to put in the extra work to divide
the patch into a series.
Index: package/base-files/files/lib/functions.sh
===
--- package/base-files/files/lib/functions.sh (revision 36088)
+++ package/base-files/files/lib/functions.sh (working copy)
@@ -229,6 +229,25 @@
echo ${PART:+$PREFIX$PART}
}
+mtd_get_mac_ascii() {
+ local mtdname=$1
+ local key=$2
+ local part
+ local mac_dirty
+
+ . /lib/functions.sh
+
+ part=$(find_mtd_part $mtdname)
+ if [ -z $part ]; then
+ echo mtd_get_mac_ascii: partition $mtdname not found! 2
+ return
+ fi
+
+ mac_dirty=$(strings $part | sed -n 's/'$key'=//p')
+ # canonicalize mac
+ printf %02x:%02x:%02x:%02x:%02x:%02x 0x${mac_dirty//:/ 0x}
+}
+
strtok() { # string { variable [separator] ... }
local tmp
local val=$1
Index: target/linux/ar71xx/base-files/etc/diag.sh
===
--- target/linux/ar71xx/base-files/etc/diag.sh (revision 36088)
+++ target/linux/ar71xx/base-files/etc/diag.sh (working copy)
@@ -70,6 +70,9 @@
dir-825-b1)
status_led=d-link:orange:power
;;
+ dir-825-c1)
+ status_led=d-link:amber:power
+ ;;
eap7660d)
status_led=eap7660d:green:ds4
;;
Index: target/linux/ar71xx/base-files/etc/uci-defaults/leds
===
--- target/linux/ar71xx/base-files/etc/uci-defaults/leds(revision 36088)
+++ target/linux/ar71xx/base-files/etc/uci-defaults/leds(working copy)
@@ -63,6 +63,10 @@
dir-825-b1)
ucidef_set_led_usbdev usb USB d-link:blue:usb 1-1
;;
+dir-825-c1)
+ ucidef_set_led_usbdev usb USB d-link:blue:usb 1-1
+ ucidef_set_led_wlan wlan2g WLAN 2.4 GHz d-link:blue:wlan2g
phy0tpt
+ ;;
hornet-ub)
ucidef_set_led_netdev lan LAN alfa:blue:lan eth0
Index: target/linux/ar71xx/base-files/etc/uci-defaults/network
===
--- target/linux/ar71xx/base-files/etc/uci-defaults/network (revision 36088)
+++ target/linux/ar71xx/base-files/etc/uci-defaults/network (working copy)
@@ -146,6 +146,16 @@
ucidef_add_switch_vlan switch0 1 0 1 2 3 5t
;;
+dir-825-c1)
+ local mac
+ ucidef_set_interfaces_lan_wan eth0.1 eth0.2
+ ucidef_add_switch eth0 1 1
+ ucidef_add_switch_vlan eth0 1 0t 1 2 3 4
+ ucidef_add_switch_vlan eth0 2 0t 5
+ mac=$(mtd_get_mac_ascii nvram ^wan_mac)
+ [ -n $mac ] ucidef_set_interface_macaddr wan $mac
+ ;;
+
all0305 |\
aw-nr580 |\
bullet-m |\
Index: target/linux/ar71xx/base-files/lib/ar71xx.sh
===
--- target/linux/ar71xx/base-files/lib/ar71xx.sh(revision 36088)
+++ target/linux/ar71xx/base-files/lib/ar71xx.sh(working copy)
@@ -204,6 +204,9 @@
*DIR-825 rev. B1)
name=dir-825-b1
;;
+ *DIR-825 rev. C1)
+ name=dir-825-c1
+ ;;
*EAP7660D)
name=eap7660d
;;
Index: target/linux/ar71xx/base-files/lib/upgrade/platform.sh
===
--- target/linux/ar71xx/base-files/lib/upgrade/platform.sh (revision 36088)
+++ target/linux/ar71xx/base-files/lib/upgrade/platform.sh (working copy)
@@ -105,6 +105,7 @@
dir-600-a1 | \
dir-615-c1 | \
dir-615-e4 | \
+ dir-825-c1 | \
ew-dorin | \
ew-dorin-router | \
mzk-w04nu | \
Index: target/linux/ar71xx/config-3.3
===
--- target/linux/ar71xx/config-3.3 (revision 36088)
+++ target/linux/ar71xx/config-3.3 (working copy)
@@ -35,6 +35,7 @@
CONFIG_ATH79_MACH_DIR_600_A1=y
CONFIG_ATH79_MACH_DIR_615_C1=y
CONFIG_ATH79_MACH_DIR_825_B1=y
+CONFIG_ATH79_MACH_DIR_825_C1=y
CONFIG_ATH79_MACH_EAP7660D=y
CONFIG_ATH79_MACH_EW_DORIN=y
CONFIG_ATH79_MACH_HORNET_UB=y
Index: target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
===
--- target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c (revision 0)
+++ target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c (working copy)
@@ -0,0 +1,211
[OpenWrt-Devel] [PATCH] ar71xx: fix WLAN 5 GHz LED init on dir-825-c1
Fixes the 5 GHz LED. The same function has no effect on the 2.4 GHz LED at all, so we might as well remove it. Signed-off-by: Sebastian Kemper sebastian...@gmx.net --- Now all LEDs are finally working in OpenWrt. diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c b/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c index af9805a..9c4c1a8 100644 --- a/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c @@ -217,8 +217,7 @@ static void __init dir825c1_setup(void) ath79_register_leds_gpio(-1, ARRAY_SIZE(dir825c1_leds_gpio), dir825c1_leds_gpio); - ap9x_pci_setup_wmac_led_pin(0, 13); - ap9x_pci_setup_wmac_led_pin(1, 32); + ap9x_pci_setup_wmac_led_pin(0, 0); dir825c1_generic_setup(); } ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] ar71xx: How to setup a GPIO bigger than GPIO_COUNT?
Hello list, On my dir-825-c1 the 5 GHz WLAN LED is connected to gpio 32. But I can't access GPIO 32. If I try I get Invalid argument errors. It seems that OpenWrt only sets up gpios 0 to 22, according to the system log: gpiochip_add: registered GPIOs 0 to 22 on device: ath79 I think 22 is the limit set in ar71xx_regs.h: #define AR913X_GPIO_COUNT 22 How would one go about registering gpio 32 to make use of this particular LED? Regards, Sebastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/4] ar71xx: let HW switch control WAN LED on dir-825-c1
Enable GPIO 20. This hands off control of the blue planet led to the
integrated switch. Consequently, remove the led configuration for the
blue planet led.
Signed-off-by: Sebastian Kemper sebastian...@gmx.net
---
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
index 21d4271..3ff5da1 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
@@ -36,6 +36,8 @@
#define DIR825C1_GPIO_LED_BLUE_PLANET 18
#define DIR825C1_GPIO_LED_WIFI_BGN 13
+#define DIR825C1_GPIO_WAN_LED_ENABLE 20
+
#define DIR825C1_GPIO_BTN_RESET17
#define DIR825C1_GPIO_BTN_WPS 16
@@ -74,10 +76,6 @@ static struct gpio_led dir825c1_leds_gpio[] __initdata = {
.active_low = 1,
},
{
- .name = d-link:blue:planet,
- .gpio = DIR825C1_GPIO_LED_BLUE_PLANET,
- .active_low = 1,
- }, {
.name = d-link:blue:wifi_bgn,
.gpio = DIR825C1_GPIO_LED_WIFI_BGN,
.active_low = 1,
@@ -213,6 +211,9 @@ static void __init dir825c1_setup(void)
ath79_gpio_output_select(DIR825C1_GPIO_LED_BLUE_USB,
AR934X_GPIO_OUT_GPIO);
+ gpio_request_one(DIR825C1_GPIO_WAN_LED_ENABLE,
+ GPIOF_OUT_INIT_LOW, WAN LED enable);
+
ath79_register_leds_gpio(-1, ARRAY_SIZE(dir825c1_leds_gpio),
dir825c1_leds_gpio);
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/4] ar71xx: vanity changes for dir-825-c1
This patch
- changes the color names from orange to amber
- changes the name of GPIO 13 from WIFI_BGN (wifi_bgn) to WLAN_2G
(wlan2g) to be more consistent with the other routers' files
- changes the descriptions of the hardware keys to be a tad more
explicit
Signed-off-by: Sebastian Kemper sebastian...@gmx.net
---
diff --git a/target/linux/ar71xx/base-files/etc/diag.sh
b/target/linux/ar71xx/base-files/etc/diag.sh
index 2719a13..e5738f5 100755
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -51,12 +51,12 @@ get_status_led() {
dir-615-c1)
status_led=d-link:green:status
;;
- dir-825-b1 |\
- dir-835-a1)
+ dir-825-b1)
status_led=d-link:orange:power
;;
- dir-825-c1)
- status_led=d-link:orange:power
+ dir-825-c1 |\
+ dir-835-a1)
+ status_led=d-link:amber:power
;;
eap7660d)
status_led=eap7660d:green:ds4
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
index 3ff5da1..d311081 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
@@ -29,12 +29,12 @@
#include machtypes.h
#define DIR825C1_GPIO_LED_BLUE_USB 11
-#define DIR825C1_GPIO_LED_ORANGE_POWER 14
+#define DIR825C1_GPIO_LED_AMBER_POWER 14
#define DIR825C1_GPIO_LED_BLUE_POWER 22
#define DIR825C1_GPIO_LED_BLUE_WPS 15
-#define DIR825C1_GPIO_LED_ORANGE_PLANET19
+#define DIR825C1_GPIO_LED_AMBER_PLANET 19
#define DIR825C1_GPIO_LED_BLUE_PLANET 18
-#define DIR825C1_GPIO_LED_WIFI_BGN 13
+#define DIR825C1_GPIO_LED_WLAN_2G 13
#define DIR825C1_GPIO_WAN_LED_ENABLE 20
@@ -56,8 +56,8 @@ static struct gpio_led dir825c1_leds_gpio[] __initdata = {
.active_low = 1,
},
{
- .name = d-link:orange:power,
- .gpio = DIR825C1_GPIO_LED_ORANGE_POWER,
+ .name = d-link:amber:power,
+ .gpio = DIR825C1_GPIO_LED_AMBER_POWER,
.active_low = 1,
},
{
@@ -71,21 +71,21 @@ static struct gpio_led dir825c1_leds_gpio[] __initdata = {
.active_low = 1,
},
{
- .name = d-link:orange:planet,
- .gpio = DIR825C1_GPIO_LED_ORANGE_PLANET,
+ .name = d-link:amber:planet,
+ .gpio = DIR825C1_GPIO_LED_AMBER_PLANET,
.active_low = 1,
},
{
- .name = d-link:blue:wifi_bgn,
- .gpio = DIR825C1_GPIO_LED_WIFI_BGN,
+ .name = d-link:blue:wlan2g,
+ .gpio = DIR825C1_GPIO_LED_WLAN_2G,
.active_low = 1,
},
};
static struct gpio_led dir835a1_leds_gpio[] __initdata = {
{
- .name = d-link:orange:power,
- .gpio = DIR825C1_GPIO_LED_ORANGE_POWER,
+ .name = d-link:amber:power,
+ .gpio = DIR825C1_GPIO_LED_AMBER_POWER,
.active_low = 1,
},
{
@@ -99,8 +99,8 @@ static struct gpio_led dir835a1_leds_gpio[] __initdata = {
.active_low = 1,
},
{
- .name = d-link:orange:planet,
- .gpio = DIR825C1_GPIO_LED_ORANGE_PLANET,
+ .name = d-link:amber:planet,
+ .gpio = DIR825C1_GPIO_LED_AMBER_PLANET,
.active_low = 1,
},
{
@@ -112,7 +112,7 @@ static struct gpio_led dir835a1_leds_gpio[] __initdata = {
static struct gpio_keys_button dir825c1_gpio_keys[] __initdata = {
{
- .desc = reset,
+ .desc = Soft reset,
.type = EV_KEY,
.code = KEY_RESTART,
.debounce_interval = DIR825C1_KEYS_DEBOUNCE_INTERVAL,
@@ -120,7 +120,7 @@ static struct gpio_keys_button dir825c1_gpio_keys[]
__initdata = {
.active_low = 1,
},
{
- .desc = wps,
+ .desc = WPS button,
.type = EV_KEY,
.code = KEY_WPS_BUTTON,
.debounce_interval = DIR825C1_KEYS_DEBOUNCE_INTERVAL,
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/5] [ar71xx] vanity changes for dir-825-c1
On Thu, Sep 19, 2013 at 11:55:13PM +0200, Sebastian Kemper wrote: Hello list, This patch - changes the color names from orange to amber - changes the name of GPIO 13 from WIFI_BGN (wifi_bgn) to WLAN_2G (wlan2g) to be more consistent with the other routers' files - changes the descriptions of the hardware keys to be a tad more explicit Signed-off-by: Sebastian Kemper sebastian...@gmx.net Hello list, It seems vanity comes at a price :) I forgot about the diagnostic LED; target/linux/ar71xx/base-files/etc/diag.sh needs an update otherwise it won't blink. I'll send an extra patch for this tonight. Regards, Sebastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/5] [ar71xx] fix LAN LEDs for dir-825-c1
On Fri, Sep 20, 2013 at 06:46:32PM +0200, Gabor Juhos wrote: Hi Sebastian, Please use the 'ar71xx:' prefix instead of [ar71xx] in the subject of ar71xx specific patches. Hello list, Please don't use salutation part in patches. Everything before the marker line '---' will be included into the commit message, so I have to remove this line manually before applying the patch. This patch removes the custom LAN LED configuration for the switch. Without it the LAN LEDs are actually working. I also tried the same configuration that is used in mach-db120.c. That worked as well. But I think why add it when it's not needed. I would fix it instead. It would make it independent from the bootloader. Signed-off-by: Sebastian Kemper sebastian...@gmx.net The marker line '---' is missing. -Gabor Hello Gabor, OK, thanks for the hints. I'll send a new round of patches in a short while. Kind regards, Sebastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/5] [ar71xx] add gpio that lets the switch control the WAN LED on dir-825-c1
On Fri, Sep 20, 2013 at 06:50:56PM +0200, Gabor Juhos wrote:
2013.09.19. 23:50 keltezéssel, Sebastian Kemper írta:
Hello list,
Activating GPIO 20 hands over the control of the blue planet LED (WAN
LED) to the switch. Add this so we can put it to use.
Signed-off-by: Sebastian Kemper sebastian...@gmx.net
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
index c2ddfa8..8d9e7af 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
@@ -36,6 +36,8 @@
#define DIR825C1_GPIO_LED_BLUE_PLANET 18
#define DIR825C1_GPIO_LED_WIFI_BGN 13
+#define DIR825C1_GPIO_LED_SWITCH_CONTROL 20
+
#define DIR825C1_GPIO_BTN_RESET17
#define DIR825C1_GPIO_BTN_WPS 16
@@ -82,6 +84,11 @@ static struct gpio_led dir825c1_leds_gpio[] __initdata =
{
.gpio = DIR825C1_GPIO_LED_WIFI_BGN,
.active_low = 1,
},
+ {
+ .name = d-link:none:wan_led_switch_ctrl,
+ .gpio = DIR825C1_GPIO_LED_SWITCH_CONTROL,
+ .active_low = 1,
+ },
This looks quite ugly. The GPIO line should be configured directly from the
board setup code instead of adding a dummy LED. See the 'gpio_request_one()'
call in mach-tew-712br.c for example.
Thanks for the tip. I'll try it out.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 5/5] [ar71xx] add to the default LED configuration of dir-825-c1
On Fri, Sep 20, 2013 at 07:10:18PM +0200, Gabor Juhos wrote: 2013.09.20. 0:04 keltezéssel, Sebastian Kemper írta: + ucidef_set_led_default wan Switch controls blue planet LED d-link:none:wan_led_switch_ctrl 1 This line should be removed along with the LED definition in mach-dir-825-c1.c file. + ucidef_set_led_default power Power Blue: on d-link:blue:power 1 Once the LED name will be fixed in diag.sh, this line will be obsolete as well. Sounds like a plan. Thanks Gabor! Regards, Sebastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/4] ar71xx: fix LAN LEDs for dir-825-c1
This patches fixes the lan led configuration. The new configuration is
identical to the one in mach-db120.c and it works. The previous one
didn't work at all.
Signed-off-by: Sebastian Kemper sebastian...@gmx.net
---
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
index 3ab16e0..21d4271 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
@@ -140,11 +140,11 @@ static struct ar8327_pad_cfg dir825c1_ar8327_pad0_cfg = {
};
static struct ar8327_led_cfg dir825c1_ar8327_led_cfg = {
- .led_ctrl0 = 0xc737c737,
- .led_ctrl1 = 0x,
+ .led_ctrl0 = 0x,
+ .led_ctrl1 = 0xc737c737,
.led_ctrl2 = 0x,
- .led_ctrl3 = 0x0030c300,
- .open_drain = false,
+ .led_ctrl3 = 0x00c30c00,
+ .open_drain = true,
};
static struct ar8327_platform_data dir825c1_ar8327_data = {
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/4] ar71xx: let HW switch control WAN LED on dir-825-c1
Enable GPIO 20. This hands off control of the blue planet led to the
integrated switch. Consequently, remove the led configuration for the
blue planet led.
Remove also the configuration for the orange planet led as both share
the same look-out.
Signed-off-by: Sebastian Kemper sebastian...@gmx.net
---
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
index 21d4271..60d1e0e 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
@@ -36,6 +36,8 @@
#define DIR825C1_GPIO_LED_BLUE_PLANET 18
#define DIR825C1_GPIO_LED_WIFI_BGN 13
+#define DIR825C1_GPIO_WAN_LED_ENABLE 20
+
#define DIR825C1_GPIO_BTN_RESET17
#define DIR825C1_GPIO_BTN_WPS 16
@@ -69,15 +71,6 @@ static struct gpio_led dir825c1_leds_gpio[] __initdata = {
.active_low = 1,
},
{
- .name = d-link:orange:planet,
- .gpio = DIR825C1_GPIO_LED_ORANGE_PLANET,
- .active_low = 1,
- },
- {
- .name = d-link:blue:planet,
- .gpio = DIR825C1_GPIO_LED_BLUE_PLANET,
- .active_low = 1,
- }, {
.name = d-link:blue:wifi_bgn,
.gpio = DIR825C1_GPIO_LED_WIFI_BGN,
.active_low = 1,
@@ -213,6 +206,9 @@ static void __init dir825c1_setup(void)
ath79_gpio_output_select(DIR825C1_GPIO_LED_BLUE_USB,
AR934X_GPIO_OUT_GPIO);
+ gpio_request_one(DIR825C1_GPIO_WAN_LED_ENABLE,
+ GPIOF_OUT_INIT_LOW, WAN LED enable);
+
ath79_register_leds_gpio(-1, ARRAY_SIZE(dir825c1_leds_gpio),
dir825c1_leds_gpio);
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 3/4] ar71xx: vanity changes for dir-825-c1
This patch
- changes the color names from orange to amber
- changes the name of GPIO 13 from WIFI_BGN (wifi_bgn) to WLAN_2G
(wlan2g) to be more consistent with the other routers' files
- changes the descriptions of the hardware keys to be a tad more
explicit
Signed-off-by: Sebastian Kemper sebastian...@gmx.net
---
diff --git a/target/linux/ar71xx/base-files/etc/diag.sh
b/target/linux/ar71xx/base-files/etc/diag.sh
index 2719a13..e5738f5 100755
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -51,12 +51,12 @@ get_status_led() {
dir-615-c1)
status_led=d-link:green:status
;;
- dir-825-b1 |\
- dir-835-a1)
+ dir-825-b1)
status_led=d-link:orange:power
;;
- dir-825-c1)
- status_led=d-link:orange:power
+ dir-825-c1 |\
+ dir-835-a1)
+ status_led=d-link:amber:power
;;
eap7660d)
status_led=eap7660d:green:ds4
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
index 60d1e0e..de0c3ad 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
@@ -29,12 +29,12 @@
#include machtypes.h
#define DIR825C1_GPIO_LED_BLUE_USB 11
-#define DIR825C1_GPIO_LED_ORANGE_POWER 14
+#define DIR825C1_GPIO_LED_AMBER_POWER 14
#define DIR825C1_GPIO_LED_BLUE_POWER 22
#define DIR825C1_GPIO_LED_BLUE_WPS 15
-#define DIR825C1_GPIO_LED_ORANGE_PLANET19
+#define DIR825C1_GPIO_LED_AMBER_PLANET 19
#define DIR825C1_GPIO_LED_BLUE_PLANET 18
-#define DIR825C1_GPIO_LED_WIFI_BGN 13
+#define DIR825C1_GPIO_LED_WLAN_2G 13
#define DIR825C1_GPIO_WAN_LED_ENABLE 20
@@ -56,8 +56,8 @@ static struct gpio_led dir825c1_leds_gpio[] __initdata = {
.active_low = 1,
},
{
- .name = d-link:orange:power,
- .gpio = DIR825C1_GPIO_LED_ORANGE_POWER,
+ .name = d-link:amber:power,
+ .gpio = DIR825C1_GPIO_LED_AMBER_POWER,
.active_low = 1,
},
{
@@ -71,16 +71,16 @@ static struct gpio_led dir825c1_leds_gpio[] __initdata = {
.active_low = 1,
},
{
- .name = d-link:blue:wifi_bgn,
- .gpio = DIR825C1_GPIO_LED_WIFI_BGN,
+ .name = d-link:blue:wlan2g,
+ .gpio = DIR825C1_GPIO_LED_WLAN_2G,
.active_low = 1,
},
};
static struct gpio_led dir835a1_leds_gpio[] __initdata = {
{
- .name = d-link:orange:power,
- .gpio = DIR825C1_GPIO_LED_ORANGE_POWER,
+ .name = d-link:amber:power,
+ .gpio = DIR825C1_GPIO_LED_AMBER_POWER,
.active_low = 1,
},
{
@@ -94,8 +94,8 @@ static struct gpio_led dir835a1_leds_gpio[] __initdata = {
.active_low = 1,
},
{
- .name = d-link:orange:planet,
- .gpio = DIR825C1_GPIO_LED_ORANGE_PLANET,
+ .name = d-link:amber:planet,
+ .gpio = DIR825C1_GPIO_LED_AMBER_PLANET,
.active_low = 1,
},
{
@@ -107,7 +107,7 @@ static struct gpio_led dir835a1_leds_gpio[] __initdata = {
static struct gpio_keys_button dir825c1_gpio_keys[] __initdata = {
{
- .desc = reset,
+ .desc = Soft reset,
.type = EV_KEY,
.code = KEY_RESTART,
.debounce_interval = DIR825C1_KEYS_DEBOUNCE_INTERVAL,
@@ -115,7 +115,7 @@ static struct gpio_keys_button dir825c1_gpio_keys[]
__initdata = {
.active_low = 1,
},
{
- .desc = wps,
+ .desc = WPS button,
.type = EV_KEY,
.code = KEY_WPS_BUTTON,
.debounce_interval = DIR825C1_KEYS_DEBOUNCE_INTERVAL,
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 4/4] ar71xx: enable wlan2g led in the default configuration of dir-825-c1
Enable the wlan2g led in the default configuration of dir-825-c1. Signed-off-by: Sebastian Kemper sebastian...@gmx.net --- diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds index 845de4e..74c9f36 100755 --- a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds @@ -70,9 +70,13 @@ dir-615-e4) ucidef_set_led_switch lan4 LAN4 d-link:green:lan4 switch0 0x10 ;; -dir-825-b1 | \ +dir-825-b1) + ucidef_set_led_usbdev usb USB d-link:blue:usb 1-1 + ;; + dir-825-c1) ucidef_set_led_usbdev usb USB d-link:blue:usb 1-1 + ucidef_set_led_wlan wlan2g WLAN 2.4 GHz d-link:blue:wlan2g phy0tpt ;; hornet-ub) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [ar71xx] change MAC address behavior of dir-825-c1
On Fri, Sep 13, 2013 at 01:53:03PM +0200, Dirk Neukirchen wrote: What about changing something in file: mach-dir-825-c1.c ath79_init_mac(wmac1, mac1, 1); shouldn't that be the second MAC +1 - you can change that maybe? Is ath79_eth0_data / ath79_eth1_data used in another machine .c : ath79_init_mac(ath79_eth1_data.mac_addr, art+WNR2000V3_MAC1_OFFSET, 0); Maybe thats WAN on switch? Hello Dirk, Thanks for your reply. I'd have loved to do that. Truth is I even tried it :) But it turned out it doesn't work. I believe the board has just one GMAC and hence there's just eth0 instead of eth0 and eth1. Kind regards, Sebastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/5] [ar71xx] fix LAN LEDs for dir-825-c1
Hello list,
This patch removes the custom LAN LED configuration for the switch.
Without it the LAN LEDs are actually working.
I also tried the same configuration that is used in mach-db120.c. That
worked as well. But I think why add it when it's not needed.
Signed-off-by: Sebastian Kemper sebastian...@gmx.net
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
index c1bd8d6..c2ddfa8 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
@@ -139,14 +139,6 @@ static struct ar8327_pad_cfg dir825c1_ar8327_pad0_cfg = {
.rxclk_delay_sel = AR8327_CLK_DELAY_SEL2,
};
-static struct ar8327_led_cfg dir825c1_ar8327_led_cfg = {
- .led_ctrl0 = 0xc737c737,
- .led_ctrl1 = 0x,
- .led_ctrl2 = 0x,
- .led_ctrl3 = 0x0030c300,
- .open_drain = false,
-};
-
static struct ar8327_platform_data dir825c1_ar8327_data = {
.pad0_cfg = dir825c1_ar8327_pad0_cfg,
.port0_cfg = {
@@ -156,7 +148,6 @@ static struct ar8327_platform_data dir825c1_ar8327_data = {
.txpause = 1,
.rxpause = 1,
},
- .led_cfg = dir825c1_ar8327_led_cfg,
};
static struct mdio_board_info dir825c1_mdio0_info[] = {
@@ -236,8 +227,6 @@ static void __init dir825c1_setup(void)
static void __init dir835a1_setup(void)
{
- dir825c1_ar8327_data.led_cfg = NULL;
-
ath79_register_leds_gpio(-1, ARRAY_SIZE(dir835a1_leds_gpio),
dir835a1_leds_gpio);
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/5] [ar71xx] add gpio that lets the switch control the WAN LED on dir-825-c1
Hello list,
Activating GPIO 20 hands over the control of the blue planet LED (WAN
LED) to the switch. Add this so we can put it to use.
Signed-off-by: Sebastian Kemper sebastian...@gmx.net
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
index c2ddfa8..8d9e7af 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
@@ -36,6 +36,8 @@
#define DIR825C1_GPIO_LED_BLUE_PLANET 18
#define DIR825C1_GPIO_LED_WIFI_BGN 13
+#define DIR825C1_GPIO_LED_SWITCH_CONTROL 20
+
#define DIR825C1_GPIO_BTN_RESET17
#define DIR825C1_GPIO_BTN_WPS 16
@@ -82,6 +84,11 @@ static struct gpio_led dir825c1_leds_gpio[] __initdata = {
.gpio = DIR825C1_GPIO_LED_WIFI_BGN,
.active_low = 1,
},
+ {
+ .name = d-link:none:wan_led_switch_ctrl,
+ .gpio = DIR825C1_GPIO_LED_SWITCH_CONTROL,
+ .active_low = 1,
+ },
};
static struct gpio_led dir835a1_leds_gpio[] __initdata = {
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 3/5] [ar71xx] vanity changes for dir-825-c1
Hello list,
This patch
- changes the color names from orange to amber
- changes the name of GPIO 13 from WIFI_BGN (wifi_bgn) to WLAN_2G
(wlan2g) to be more consistent with the other routers' files
- changes the descriptions of the hardware keys to be a tad more
explicit
Signed-off-by: Sebastian Kemper sebastian...@gmx.net
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
index 8d9e7af..902383e 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
@@ -29,12 +29,12 @@
#include machtypes.h
#define DIR825C1_GPIO_LED_BLUE_USB 11
-#define DIR825C1_GPIO_LED_ORANGE_POWER 14
+#define DIR825C1_GPIO_LED_AMBER_POWER 14
#define DIR825C1_GPIO_LED_BLUE_POWER 22
#define DIR825C1_GPIO_LED_BLUE_WPS 15
-#define DIR825C1_GPIO_LED_ORANGE_PLANET19
+#define DIR825C1_GPIO_LED_AMBER_PLANET 19
#define DIR825C1_GPIO_LED_BLUE_PLANET 18
-#define DIR825C1_GPIO_LED_WIFI_BGN 13
+#define DIR825C1_GPIO_LED_WLAN_2G 13
#define DIR825C1_GPIO_LED_SWITCH_CONTROL 20
@@ -56,8 +56,8 @@ static struct gpio_led dir825c1_leds_gpio[] __initdata = {
.active_low = 1,
},
{
- .name = d-link:orange:power,
- .gpio = DIR825C1_GPIO_LED_ORANGE_POWER,
+ .name = d-link:amber:power,
+ .gpio = DIR825C1_GPIO_LED_AMBER_POWER,
.active_low = 1,
},
{
@@ -71,8 +71,8 @@ static struct gpio_led dir825c1_leds_gpio[] __initdata = {
.active_low = 1,
},
{
- .name = d-link:orange:planet,
- .gpio = DIR825C1_GPIO_LED_ORANGE_PLANET,
+ .name = d-link:amber:planet,
+ .gpio = DIR825C1_GPIO_LED_AMBER_PLANET,
.active_low = 1,
},
{
@@ -80,8 +80,8 @@ static struct gpio_led dir825c1_leds_gpio[] __initdata = {
.gpio = DIR825C1_GPIO_LED_BLUE_PLANET,
.active_low = 1,
}, {
- .name = d-link:blue:wifi_bgn,
- .gpio = DIR825C1_GPIO_LED_WIFI_BGN,
+ .name = d-link:blue:wlan2g,
+ .gpio = DIR825C1_GPIO_LED_WLAN_2G,
.active_low = 1,
},
{
@@ -93,8 +93,8 @@ static struct gpio_led dir825c1_leds_gpio[] __initdata = {
static struct gpio_led dir835a1_leds_gpio[] __initdata = {
{
- .name = d-link:orange:power,
- .gpio = DIR825C1_GPIO_LED_ORANGE_POWER,
+ .name = d-link:amber:power,
+ .gpio = DIR825C1_GPIO_LED_AMBER_POWER,
.active_low = 1,
},
{
@@ -108,8 +108,8 @@ static struct gpio_led dir835a1_leds_gpio[] __initdata = {
.active_low = 1,
},
{
- .name = d-link:orange:planet,
- .gpio = DIR825C1_GPIO_LED_ORANGE_PLANET,
+ .name = d-link:amber:planet,
+ .gpio = DIR825C1_GPIO_LED_AMBER_PLANET,
.active_low = 1,
},
{
@@ -121,7 +121,7 @@ static struct gpio_led dir835a1_leds_gpio[] __initdata = {
static struct gpio_keys_button dir825c1_gpio_keys[] __initdata = {
{
- .desc = reset,
+ .desc = Soft reset,
.type = EV_KEY,
.code = KEY_RESTART,
.debounce_interval = DIR825C1_KEYS_DEBOUNCE_INTERVAL,
@@ -129,7 +129,7 @@ static struct gpio_keys_button dir825c1_gpio_keys[]
__initdata = {
.active_low = 1,
},
{
- .desc = wps,
+ .desc = WPS button,
.type = EV_KEY,
.code = KEY_WPS_BUTTON,
.debounce_interval = DIR825C1_KEYS_DEBOUNCE_INTERVAL,
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 5/5] [ar71xx] add to the default LED configuration of dir-825-c1
Hello list, This patch adds to the default LED configuration. The blue power LED defaults to on. With the activation of wan_led_switch_ctrl we hand off control of the blue planet LED to the hardware switch; this means also that it will be enabled when the router starts. WLAN_2G LED also enabled by default. I haven't yet figured out how to setup GPIO 32 for WLAN_5G. Hopefully that will follow later :) Signed-off-by: Sebastian Kemper sebastian...@gmx.net diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds index f55f1fe..5e8e505 100755 --- a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds @@ -70,9 +70,15 @@ dir-615-e4) ucidef_set_led_switch lan4 LAN4 d-link:green:lan4 switch0 0x10 ;; -dir-825-b1 | \ +dir-825-b1) + ucidef_set_led_usbdev usb USB d-link:blue:usb 1-1 + ;; + dir-825-c1) ucidef_set_led_usbdev usb USB d-link:blue:usb 1-1 + ucidef_set_led_default wan Switch controls blue planet LED d-link:none:wan_led_switch_ctrl 1 + ucidef_set_led_default power Power Blue: on d-link:blue:power 1 + ucidef_set_led_wlan wlan2g WLAN 2.4 GHz LED d-link:blue:wlan2g phy0tpt ;; hornet-ub) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 4/5] [ar71xx] set proper wan mac during initial configuration on dir-825-c1
Hello list, I sent a patch earlier and received some advice on how to do it better. Here is my 2nd attempt. The goal remains to set the WAN MAC address to the one on the sticker on the bottom of the unit. Currently it is not used at all. But some users expect the WAN interface to have the MAC address that is written on the sticker. Signed-off-by: Sebastian Kemper sebastian...@gmx.net diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network index d5a1506..5abf796 100755 --- a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network @@ -194,7 +194,16 @@ wzr-hp-g300nh) ucidef_add_switch_vlan switch0 1 0 1 2 3 5t ;; -dir-825-c1 |\ +dir-825-c1) + local mac + ucidef_set_interfaces_lan_wan eth0.1 eth0.2 + ucidef_add_switch switch0 1 1 + ucidef_add_switch_vlan switch0 1 0t 1 2 3 4 + ucidef_add_switch_vlan switch0 2 0t 5 + mac=$(mtd_get_mac_ascii nvram ^wan_mac) + [ -n $mac ] ucidef_set_interface_macaddr wan $mac + ;; + dir-835-a1 |\ wndr4300) ucidef_set_interfaces_lan_wan eth0.1 eth0.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [ar71xx] add wireless bgn led support for dir-825-c1
Hello list,
I checked the GPL code drop from D-Link and tried to get the wireless
and LAN switch LEDs to light up. I found some references in
AthSDK/www/DIR-825_C1/bsp.h as well as
AthSDK/www/DIR-825_C1/rootfs/etc/sysconfig/S2gpio.sh, but in the end I
only got the led for 2.4GHz to work. Anyway, here's the patch.
Signed-off-by: Sebastian Kemper sebastian...@gmx.net
diff -Nur
openwrt.orig/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
openwrt.new/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
--- openwrt.orig/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
2013-09-12 23:56:18.864876903 +0200
+++ openwrt.new/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
2013-09-13 10:37:40.226421755 +0200
@@ -34,6 +34,7 @@
#define DIR825C1_GPIO_LED_BLUE_WPS 15
#define DIR825C1_GPIO_LED_ORANGE_PLANET19
#define DIR825C1_GPIO_LED_BLUE_PLANET 18
+#define DIR825C1_GPIO_LED_WIFI_BGN 13
#define DIR825C1_GPIO_BTN_RESET17
#define DIR825C1_GPIO_BTN_WPS 16
@@ -76,6 +77,10 @@
.name = d-link:blue:planet,
.gpio = DIR825C1_GPIO_LED_BLUE_PLANET,
.active_low = 1,
+ }, {
+ .name = d-link:blue:wifi_bgn,
+ .gpio = DIR825C1_GPIO_LED_WIFI_BGN,
+ .active_low = 1,
},
};
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [ar71xx] change MAC address behavior of dir-825-c1
Hello list,
The current behavior is that all interfaces (LAN, WAN and Wifi0) get the
first MAC address in the mac mtd assigned (Wifi1 gets the MAC address of
the second MAC address plus 1).
Unfortunately the MAC address printed on the sticker on the bottom of
the router (the second MAC address in the mac mtd) is not used at all.
But for some use cases it appears to be vital that the printed MAC gets
assigned.
For testing I installed D-Link's firmware 304b01 (latest). It handles
MAC assignments the same way as OpenWrt does, except it assigns the
printed MAC to the WAN interface.
So I tried to come up with a way to do the same in OpenWrt. As the WAN
interface is a virtual interface there's no way to do this while loading
the driver. For the same reason I couldn't use the existing code in
lib/preinit, i.e. 05_set_iface_mac_ar71xx.
So I ended up with the following patch. Please consider it/tell me what
you think. Thanks!
Signed-off-by: Sebastian Kemper sebastian...@gmx.net
diff -Nur
openwrt.orig/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
openwrt.new/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
--- openwrt.orig/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
2013-09-12 23:54:58.491543186 +0200
+++ openwrt.new/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
2013-09-13 00:04:46.284856230 +0200
@@ -5,6 +5,18 @@
[ -e /etc/config/network ] exit 0
+fetch_wan_mac_from_mtd() {
+ local mtd_part=$1
+ local wan_env=$2
+ local mtd mac
+
+ mtd=$(grep $mtd_part /proc/mtd | cut -d: -f1)
+ [ -z $mtd ] return
+
+ mac=$(grep -m 1 $wan_env /dev/$mtd | cut -d= -f2)
+ [ ! -z $mac ] ucidef_set_interface_macaddr wan $mac
+}
+
touch /etc/config/network
. /lib/functions/uci-defaults.sh
@@ -193,7 +205,14 @@
ucidef_add_switch_vlan switch0 1 0 1 2 3 5t
;;
-dir-825-c1 |\
+dir-825-c1)
+ ucidef_set_interfaces_lan_wan eth0.1 eth0.2
+ fetch_wan_mac_from_mtd nvram wan_mac
+ ucidef_add_switch switch0 1 1
+ ucidef_add_switch_vlan switch0 1 0t 1 2 3 4
+ ucidef_add_switch_vlan switch0 2 0t 5
+ ;;
+
dir-835-a1 |\
wndr4300)
ucidef_set_interfaces_lan_wan eth0.1 eth0.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
