Re: [OpenWrt-Devel] [PATCH-19.07] build: fix module strip invalid
Build file drivers/net/ethernet/intel/e1000e/e1000e.ko size about 920KB for old
PATCH.
After the new patch is about 177KB
From: Hauke Mehrtens
Date: 2019-10-30 23:47
To: daxiong; openwrt-devel
Subject: Re: [OpenWrt-Devel] [PATCH-19.07] build: fix module strip invalid
On 10/30/19 11:14 AM, daxiong wrote:
> Current modpost cannot reduce the module size.
>
> Use $(STRIP) command to replace the modpost patch,
> I think to be compatibility will be better.
>
> Signed-off-by: daxiong
Please base this against master, then we can backport it to 19.07.
Could you please elaborate a little bit more how module-strip provides
better results than the previous patch? It would be nice if you could
also provide some numbers to compare the previous size and the current size.
Would it make sense to do both together, what was done in this patch
before and after your change?
Hauke
> ---
> .../linux/generic/hack-4.14/204-module_strip.patch | 216
> +++--
> 1 file changed, 24 insertions(+), 192 deletions(-)
>
> diff --git a/target/linux/generic/hack-4.14/204-module_strip.patch
> b/target/linux/generic/hack-4.14/204-module_strip.patch
> index d847adf..c22a507 100644
> --- a/target/linux/generic/hack-4.14/204-module_strip.patch
> +++ b/target/linux/generic/hack-4.14/204-module_strip.patch
> @@ -1,104 +1,8 @@
> -From a779a482fb9b9f8fcdf8b2519c789b4b9bb5dd05 Mon Sep 17 00:00:00 2001
> -From: Felix Fietkau
> -Date: Fri, 7 Jul 2017 16:56:48 +0200
> -Subject: build: add a hack for removing non-essential module info
> -
> -Signed-off-by: Felix Fietkau
>
> - include/linux/module.h | 13 -
> - include/linux/moduleparam.h | 15 ---
> - init/Kconfig| 7 +++
> - kernel/module.c | 5 -
> - scripts/mod/modpost.c | 12
> - 5 files changed, 43 insertions(+), 9 deletions(-)
> -
> a/include/linux/module.h
> -+++ b/include/linux/module.h
> -@@ -158,6 +158,7 @@ extern void cleanup_module(void);
> -
> - /* Generic info of form tag = "info" */
> - #define MODULE_INFO(tag, info) __MODULE_INFO(tag, tag, info)
> -+#define MODULE_INFO_STRIP(tag, info) __MODULE_INFO_STRIP(tag, tag, info)
> -
> - /* For userspace: you can also call me... */
> - #define MODULE_ALIAS(_alias) MODULE_INFO(alias, _alias)
> -@@ -201,12 +202,12 @@ extern void cleanup_module(void);
> - * Author(s), use "Name " or just "Name", for multiple
> - * authors use multiple MODULE_AUTHOR() statements/lines.
> - */
> --#define MODULE_AUTHOR(_author) MODULE_INFO(author, _author)
> -+#define MODULE_AUTHOR(_author) MODULE_INFO_STRIP(author, _author)
> -
> - /* What your module does. */
> --#define MODULE_DESCRIPTION(_description) MODULE_INFO(description,
> _description)
> -+#define MODULE_DESCRIPTION(_description) MODULE_INFO_STRIP(description,
> _description)
> -
> --#ifdef MODULE
> -+#if defined(MODULE) && !defined(CONFIG_MODULE_STRIPPED)
> - /* Creates an alias so file2alias.c can find device table. */
> - #define MODULE_DEVICE_TABLE(type, name) \
> - extern typeof(name) __mod_##type##__##name##_device_table \
> -@@ -233,7 +234,9 @@ extern typeof(name) __mod_##type##__##na
> - */
> -
> - #if defined(MODULE) || !defined(CONFIG_SYSFS)
> --#define MODULE_VERSION(_version) MODULE_INFO(version, _version)
> -+#define MODULE_VERSION(_version) MODULE_INFO_STRIP(version, _version)
> -+#elif defined(CONFIG_MODULE_STRIPPED)
> -+#define MODULE_VERSION(_version) __MODULE_INFO_DISABLED(version)
> - #else
> - #define MODULE_VERSION(_version) \
> - static struct module_version_attribute ___modver_attr = { \
> -@@ -255,7 +258,7 @@ extern typeof(name) __mod_##type##__##na
> - /* Optional firmware file (or files) needed by the module
> - * format is simply firmware file name. Multiple firmware
> - * files require multiple MODULE_FIRMWARE() specifiers */
> --#define MODULE_FIRMWARE(_firmware) MODULE_INFO(firmware, _firmware)
> -+#define MODULE_FIRMWARE(_firmware) MODULE_INFO_STRIP(firmware, _firmware)
> -
> - struct notifier_block;
> -
> a/include/linux/moduleparam.h
> -+++ b/include/linux/moduleparam.h
> -@@ -17,6 +17,16 @@
> - /* Chosen so that structs with an unsigned long line up. */
> - #define MAX_PARAM_PREFIX_LEN (64 - sizeof(unsigned long))
> -
> -+/* This struct is here for syntactic coherency, it is not used */
> -+#define __MODULE_INFO_DISABLED(name) \
> -+ struct __UNIQUE_ID(name) {}
> -+
> -+#ifdef CONFIG_MODULE_STRIPPED
> -+#define __MODULE_INFO_STRIP(tag, name, info) __MODULE_INFO_DISABLED(name)
> -+#else
> -+#define __MODULE_INFO_STRIP(tag, name, info) __MODULE_INFO(tag, name, info)
> -+#endif
> -+
> - #ifdef MODULE
> - #define __MODULE_INFO(tag, name, info) \
> - static const char __UNIQUE_ID(name)[] \
> -@@ -24,8 +34,7 @@ static const char __UNIQUE_ID(name)[]
> - = __stringify(tag) "=" info
> - #else /* !MODULE */
> - /* This struct is here for syntactic coherency, it is not used */
> --#define __MODULE_INFO(tag, name, info) \
> --
Re: [OpenWrt-Devel] [PATCH] hostapd: enable PMKSA and OK caching for WPA3-Personal
Hello Hauke,
On 10/30/19 8:47 PM, Hauke Mehrtens wrote:
> Do you know which, PMKSA or OKC, is needed for the iPhone?
PMKSA caching is the one required to work with the iPhone (however OKC should
not be harmful).
>
> I do not understand why the iPhone only works when one of these options
> is set, you should probably ask on the hostapd mailing list for help,
> this could be also a bug in hostapd.
This is due to the fact, that Apple sends the PMKID in the first association
request
(before the EAPOL handshake).
In case PMKID caching is disabled, the association is rejected at this point.
An OpenWrt / Android (probably all wpa_supplicant based clients without
sae_pmkid_in_assoc
enabled) will send an empty PMKID list, thus not triggering the issue.
As the PMKID in association seems not to be against the spec, we either have to
a) ignore the PMKID list in the association request
b) enable caching for WPA3-personal / OWE
(I'm not an expert in this field, so feel free to point out wrong assumptions
here)
Best wishes
David
>
>> ---
>> package/network/services/hostapd/files/hostapd.sh | 9 -
>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/package/network/services/hostapd/files/hostapd.sh
>> b/package/network/services/hostapd/files/hostapd.sh
>> index 8da8539e8a..fdbce815df 100644
>> --- a/package/network/services/hostapd/files/hostapd.sh
>> +++ b/package/network/services/hostapd/files/hostapd.sh
>> @@ -540,7 +540,14 @@ hostapd_set_bss_options() {
>> append bss_conf "rsn_preauth=1" "$N"
>> append bss_conf
>> "rsn_preauth_interfaces=$network_bridge" "$N"
>> else
>> -set_default auth_cache 0
>> +case "$auth_type" in
>> +sae|psk-sae|owe)
>> +set_default auth_cache 1
>> +;;
>> +*)
>> +set_default auth_cache 0
>> +;;
>> +esac
>> fi
>>
>> append bss_conf "okc=$auth_cache" "$N"
>>
>
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH netifd 2/5] wireless: serialize wireless interface configuration
On 30/10/2019 16:56, Daniel Golle wrote: + wdev->serialize = true; this should default to false, my bad, it's a leftover from my testing setup, will fixup when I merge the patch John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] v5.4 as next kernel
Hi On 2019-10-30, Adrian Schmutzler wrote: > 1. We currently have work-in-progress 4.19 support PRs for ramips, > ipq806x and bcm63xx, still with considerable work to do at least for > the first two (IIRC). Kernel 4.19 has been working fine on ipq806x (nbg6817) for me so far, I've been using it a for couple of months now and the pending pull request[0] is functional. Yes, there might be further optimization steps possible, but none of that is necessary to switch ipq806x from v4.14 to v4.19 now'ish (routing throughput is already significantly better in v4.19, jumbo frames no longer crash stmmac, so I do consider the current state of the v4.19 patches for ipq806x to be an improvement over v4.14). Regards Stefan Lippers-Hollmann [0] https://github.com/openwrt/openwrt/pull/2472 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] hostapd: enable PMKSA and OK caching for WPA3-Personal
On 10/29/19 11:42 PM, David Bauer wrote:
> This enables PMKSA and opportunistic key caching by default for
> WPA2/WPA3-Personal, WPA3-Personal and OWE auth types.
> Otherwise, Apple devices won't connect to the WPA3 network.
>
> This should not degrade security, as there's no external authentication
> provider.
>
> Tested with OCEDO Koala and iPhone 7 (iOS 13.1).
>
> Signed-off-by: David Bauer
Do you know which, PMKSA or OKC, is needed for the iPhone?
I do not understand why the iPhone only works when one of these options
is set, you should probably ask on the hostapd mailing list for help,
this could be also a bug in hostapd.
> ---
> package/network/services/hostapd/files/hostapd.sh | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/package/network/services/hostapd/files/hostapd.sh
> b/package/network/services/hostapd/files/hostapd.sh
> index 8da8539e8a..fdbce815df 100644
> --- a/package/network/services/hostapd/files/hostapd.sh
> +++ b/package/network/services/hostapd/files/hostapd.sh
> @@ -540,7 +540,14 @@ hostapd_set_bss_options() {
> append bss_conf "rsn_preauth=1" "$N"
> append bss_conf
> "rsn_preauth_interfaces=$network_bridge" "$N"
> else
> - set_default auth_cache 0
> + case "$auth_type" in
> + sae|psk-sae|owe)
> + set_default auth_cache 1
> + ;;
> + *)
> + set_default auth_cache 0
> + ;;
> + esac
> fi
>
> append bss_conf "okc=$auth_cache" "$N"
>
signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] v5.4 as next kernel
On 10/30/19 6:25 PM, Piotr Dymacz wrote: > Hi Hauke, John, > > On 30.10.2019 16:54, Hauke Mehrtens wrote: >> On 10/29/19 6:37 AM, John Crispin wrote: >>> Hi, >>> should we use v5.4 as our next kernel ? >>> John >> >> I also agree to have kernel 5.4 as the next kernel, it will be finally >> released in about 1 months and it is a long term kernel. If we are lucky >> it will be supported for 6 years for Android. >> >> What do we want to use in the next 20.X release after 19.07? >> If we want to go with kernel 5.4 with the release after 19.07 we can not >> make this release before April, I would assume. We would have generic >> support in OpenWrt master in about 1 month and then we will port the >> targets, probably we will have the most important targets ported about >> 2 months later (Mid January 2020) and can stabilize and port the rest of >> afterwards. > > +1 for 5.4 as next one but not as next (20.x) release base. 4.19 EOL is > Dec 2020, with 5.4 in master around Jan 2020 we should be able to ship > release with 5.4 before 4.19 gets EOL. Otherwise, I'm worried jumping to > 5.4 now might delay next release to the end of 2020. My 2c. > Hi, I am pretty sure kernel 4.19 and 5.4 will get 6 years support like the previous versions. For kernel 4.9 and 4.14 kernel initially listed only 1 or 2 years support, but this was extended. Currently Google pays for this support, so that Android phones get updates and they have no plan to do major kernel updates. Hauke signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ipq40xx: convert IMAGE_SIZE/KERNEL_SIZE/BLOCKSIZE to kiB
This cosmetical patch converts IMAGE_SIZE, KERNEL_SIZE and
BLOCKSIZE definitions to kilobytes, as this is consistent and
easier to read/type.
An exception was made for asus_rt-ac58u, where the IMAGE_SIZE of
20439364 cannot be divided by 1024 (and also does not seem to
match anything in DTS).
Build-tested for all devices.
Signed-off-by: Adrian Schmutzler
---
target/linux/ipq40xx/image/Makefile | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/target/linux/ipq40xx/image/Makefile
b/target/linux/ipq40xx/image/Makefile
index ed46bca649..8dd960bc1c 100644
--- a/target/linux/ipq40xx/image/Makefile
+++ b/target/linux/ipq40xx/image/Makefile
@@ -124,7 +124,7 @@ define Device/avm_fritzbox-4040
DEVICE_MODEL := FRITZ!Box 4040
DEVICE_DTS := qcom-ipq4018-fritz4040
BOARD_NAME := fritz4040
- IMAGE_SIZE := 29753344
+ IMAGE_SIZE := 29056k
UBOOT_PATH := $(STAGING_DIR_IMAGE)/uboot-fritz4040.bin
UBOOT_PARTITION_SIZE := 524288
IMAGES = eva.bin sysupgrade.bin
@@ -209,7 +209,7 @@ define Device/engenius_ens620ext
FW_VER := 3.1.2
FW_VER_NEW := 3.5.6
CW_VER := 1.8.99
- IMAGE_SIZE := 21823488
+ IMAGE_SIZE := 21312k
KERNEL_SIZE := 5120k
FILESYSTEMS := squashfs
IMAGES := sysupgrade.bin factory_30.bin factory_35.bin
@@ -260,8 +260,8 @@ define Device/linksys_ea6350v3
DEVICE_DTS := qcom-ipq4018-ea6350v3
BLOCKSIZE := 128k
PAGESIZE := 2048
- KERNEL_SIZE := 3145728
- IMAGE_SIZE := 38797312
+ KERNEL_SIZE := 3072k
+ IMAGE_SIZE := 37888k
UBINIZE_OPTS := -E 5
IMAGES := factory.bin sysupgrade.bin
IMAGE/factory.bin := append-kernel | append-uImage-fakehdr filesystem |
pad-to {KERNEL_SIZE} | append-ubi | linksys-image type=EA6350v3
@@ -290,7 +290,7 @@ define Device/meraki_mr33
DEVICE_VENDOR := Cisco Meraki
DEVICE_MODEL := MR33
DEVICE_DTS := qcom-ipq4029-mr33
- BLOCKSIZE := 131072
+ BLOCKSIZE := 128k
PAGESIZE := 2048
IMAGES = sysupgrade.bin
DEVICE_PACKAGES := -swconfig ath10k-firmware-qca9887-ct
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] v5.4 as next kernel
On 10/30/19 9:50 AM, Hauke Mehrtens wrote: On 10/30/19 5:29 PM, Adrian Schmutzler wrote: Hi, -Original Message- From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of Hauke Mehrtens Sent: Mittwoch, 30. Oktober 2019 16:54 To: John Crispin ; OpenWrt Development List Subject: Re: [OpenWrt-Devel] v5.4 as next kernel On 10/29/19 6:37 AM, John Crispin wrote: Hi, should we use v5.4 as our next kernel ? John I also agree to have kernel 5.4 as the next kernel, it will be finally released in about 1 months and it is a long term kernel. If we are lucky it will be supported for 6 years for Android. What do we want to use in the next 20.X release after 19.07? If we want to go with kernel 5.4 with the release after 19.07 we can not make this release before April, I would assume. We would have generic support in OpenWrt master in about 1 month and then we will port the targets, probably we will have the most important targets ported about 2 months later (Mid January 2020) and can stabilize and port the rest of afterwards. hauke 1. We currently have work-in-progress 4.19 support PRs for ramips, ipq806x and bcm63xx, still with considerable work to do at least for the first two (IIRC). Without in-depth knowledge, I wonder whether it wouldn't be more efficient to skip 4.19 for those and go directly to 5.4 (less backporting etc., but also more adjustments of local stuff). 2. Obviously, starting with 5.4 now will cause a mixed-kernel-release-or-not debate in early 2020. So, when moving to 5.4 we should already ask ourselves this question early in the process. (Which obviously also depends on the decision on subject 1.) I personally favor to not have a mixed kernel release, but as I'm commenting from the side my voice shouldn't count much in that process. 3. Since stable branches are typically made 3-6 months after when they have been set, I wouldn't care too much about a 3 month delay in estimated release date. :-) Just wanted to add those thoughts to the discussion, sorry for not providing answers ;-) Best Adrian Supporting two different kernel versions in one release was not a good idea, we did it because the release was delayed and we decided to use kernel 4.14 partially for this release pretty late in the process. We should decide if we want to use kernel 5.4 in the next release in the next 2 to 4 weeks, so we do not lose so much time. I would suggest the following. 1. Sift the 20.X release after 19.07 from January to April 2020 1.1. We will not get kernel 5.4 stable till January 2. Integrate support for kernel 5.4 soon 2.1. The generic support with the first targets should be there in about 1.5 months, which should be doable 3. Migrate all the targets to kernel 5.4 3.1. Probably all the targets on kernel 4.19 will be migrated quickly, the not so well supported targets could cause problems, but we have similar problems with kernel 4.19. 4. When no target is using kernel 4.19 any more, drop support for it 4.1. dropping support for kernel 4.19 could cause problems for some downstream users which would like to use kernel 4.19 (e.g. Intel in prpl), I do not know if we care. Hauke At least in my opinion, and echoed by comments on the forum, OpenWrt is suffering from a credibility gap due to the delays associated with the release of 19.01, err, 19.07, amplified by the statements made after the Hamburg meeting[1]. There are also significant gaps in the ath79 target when it comes to NAND support. Although AR934X support was just added in 758a4d1766 and devices that use that "flavor" of NAND are appearing, there still is no SPI-NAND support (https://github.com/openwrt/openwrt/pull/2184 has been available for review for nearly four months now) and I am not aware of work on the Mikrotik devices. Even though the ar71xx target has been deprecated and announced to be dropped in the next release, this lack of support has downstream projects still developing against it as there is no "release" version on which to base their devices. See, for example https://github.com/gl-inet/openwrt/commit/cfc85fc80e914a2808f7b19d71c47db24c471cd7 At least if the work on ath79 around NAND is adopted and additional work (Mikrotik) can proceed on the "familiar" Linux 4.19, it seems that it would have a greater likelihood of success that if the transition to Linux 5.4 were thrown into the mix. To address these issues, I'd suggest: * Release 19.07 as soon as possible * Plan for and release 20.01 * On schedule * With Linux 4.19 * With NAND support as complete as possible for the ath79 target * Include devices using the AR934X driver * Adopt https://github.com/openwrt/openwrt/pull/2184 * Encourage porting of the remaining ar71xx/NAND devices to ath79 * Encourage and adopt development of Mikrotik support * Dropping ar71xx, as agreed at Hamburg * Give up on "Point release cycle: Every 2 months automatic if there are any new commits within release
Re: [OpenWrt-Devel] v5.4 as next kernel
Hi Hauke, John, On 30.10.2019 16:54, Hauke Mehrtens wrote: On 10/29/19 6:37 AM, John Crispin wrote: Hi, should we use v5.4 as our next kernel ? John I also agree to have kernel 5.4 as the next kernel, it will be finally released in about 1 months and it is a long term kernel. If we are lucky it will be supported for 6 years for Android. What do we want to use in the next 20.X release after 19.07? If we want to go with kernel 5.4 with the release after 19.07 we can not make this release before April, I would assume. We would have generic support in OpenWrt master in about 1 month and then we will port the targets, probably we will have the most important targets ported about 2 months later (Mid January 2020) and can stabilize and port the rest of afterwards. +1 for 5.4 as next one but not as next (20.x) release base. 4.19 EOL is Dec 2020, with 5.4 in master around Jan 2020 we should be able to ship release with 5.4 before 4.19 gets EOL. Otherwise, I'm worried jumping to 5.4 now might delay next release to the end of 2020. My 2c. -- Cheers, Piotr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] v5.4 as next kernel
On 10/30/19 5:29 PM, Adrian Schmutzler wrote: > Hi, > >> -Original Message- >> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On >> Behalf Of Hauke Mehrtens >> Sent: Mittwoch, 30. Oktober 2019 16:54 >> To: John Crispin ; OpenWrt Development List >> >> Subject: Re: [OpenWrt-Devel] v5.4 as next kernel >> >> On 10/29/19 6:37 AM, John Crispin wrote: >>> Hi, >>> should we use v5.4 as our next kernel ? >>> John >> >> I also agree to have kernel 5.4 as the next kernel, it will be finally >> released in about 1 months and it is a long term kernel. If we are lucky >> it will be supported for 6 years for Android. >> >> What do we want to use in the next 20.X release after 19.07? >> If we want to go with kernel 5.4 with the release after 19.07 we can not >> make this release before April, I would assume. We would have generic >> support in OpenWrt master in about 1 month and then we will port the >> targets, probably we will have the most important targets ported about >> 2 months later (Mid January 2020) and can stabilize and port the rest of >> afterwards. >> >> hauke > > 1. We currently have work-in-progress 4.19 support PRs for ramips, ipq806x > and bcm63xx, still with considerable work to do at least for the first two > (IIRC). Without in-depth knowledge, I wonder whether it wouldn't be more > efficient to skip 4.19 for those and go directly to 5.4 (less backporting > etc., but also more adjustments of local stuff). > 2. Obviously, starting with 5.4 now will cause a mixed-kernel-release-or-not > debate in early 2020. So, when moving to 5.4 we should already ask ourselves > this question early in the process. (Which obviously also depends on the > decision on subject 1.) I personally favor to not have a mixed kernel > release, but as I'm commenting from the side my voice shouldn't count much in > that process. > 3. Since stable branches are typically made 3-6 months after when they have > been set, I wouldn't care too much about a 3 month delay in estimated release > date. :-) > > Just wanted to add those thoughts to the discussion, sorry for not providing > answers ;-) > > Best > > Adrian > Supporting two different kernel versions in one release was not a good idea, we did it because the release was delayed and we decided to use kernel 4.14 partially for this release pretty late in the process. We should decide if we want to use kernel 5.4 in the next release in the next 2 to 4 weeks, so we do not lose so much time. I would suggest the following. 1. Sift the 20.X release after 19.07 from January to April 2020 1.1. We will not get kernel 5.4 stable till January 2. Integrate support for kernel 5.4 soon 2.1. The generic support with the first targets should be there in about 1.5 months, which should be doable 3. Migrate all the targets to kernel 5.4 3.1. Probably all the targets on kernel 4.19 will be migrated quickly, the not so well supported targets could cause problems, but we have similar problems with kernel 4.19. 4. When no target is using kernel 4.19 any more, drop support for it 4.1. dropping support for kernel 4.19 could cause problems for some downstream users which would like to use kernel 4.19 (e.g. Intel in prpl), I do not know if we care. Hauke signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] v5.4 as next kernel
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On > Behalf Of Hauke Mehrtens > Sent: Mittwoch, 30. Oktober 2019 16:54 > To: John Crispin ; OpenWrt Development List > > Subject: Re: [OpenWrt-Devel] v5.4 as next kernel > > On 10/29/19 6:37 AM, John Crispin wrote: > > Hi, > > should we use v5.4 as our next kernel ? > > John > > I also agree to have kernel 5.4 as the next kernel, it will be finally > released in about 1 months and it is a long term kernel. If we are lucky > it will be supported for 6 years for Android. > > What do we want to use in the next 20.X release after 19.07? > If we want to go with kernel 5.4 with the release after 19.07 we can not > make this release before April, I would assume. We would have generic > support in OpenWrt master in about 1 month and then we will port the > targets, probably we will have the most important targets ported about > 2 months later (Mid January 2020) and can stabilize and port the rest of > afterwards. > > hauke 1. We currently have work-in-progress 4.19 support PRs for ramips, ipq806x and bcm63xx, still with considerable work to do at least for the first two (IIRC). Without in-depth knowledge, I wonder whether it wouldn't be more efficient to skip 4.19 for those and go directly to 5.4 (less backporting etc., but also more adjustments of local stuff). 2. Obviously, starting with 5.4 now will cause a mixed-kernel-release-or-not debate in early 2020. So, when moving to 5.4 we should already ask ourselves this question early in the process. (Which obviously also depends on the decision on subject 1.) I personally favor to not have a mixed kernel release, but as I'm commenting from the side my voice shouldn't count much in that process. 3. Since stable branches are typically made 3-6 months after when they have been set, I wouldn't care too much about a 3 month delay in estimated release date. :-) Just wanted to add those thoughts to the discussion, sorry for not providing answers ;-) Best Adrian openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/3] ipq40xx: ipq4019: Add new device Compex WPJ419
Hi,
> > + m25p80@0 {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + reg = <0>;
> > + linux,modalias = "m25p80", "n25q128a11";
> > + compatible = "jedec,spi-nor", "n25q128a11";
> > + spi-max-frequency = <2400>;
>
>
> I don't think you need linux,modalias here, nor the chip type in the
> compatible line.
> I believe that the following compatible line is sufficient
>
> compatible = "jedec,spi-nor";
>
>
> You might also want to consider "flash@0" or "nor@0" or "nor_flash@0",
> or the like, rather than a chip-specific name. (I'm not a committer.)
Indeed.
Best
Adrian
openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 4/5] mac80211: add support for dynamically reconfiguring wifi
From: John Crispin
Change scripts to use ubus interface of hostapd/wpa_supplicant to
add/remove/modify wireless interfaces instead of (re-)starting the
services.
Signed-off-by: Daniel Golle
---
.../files/lib/netifd/wireless/mac80211.sh | 135 ++
1 file changed, 107 insertions(+), 28 deletions(-)
diff --git a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
index f9d5c0c6d5..e62a53f5be 100644
--- a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
+++ b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
@@ -18,6 +18,11 @@ iw() {
command iw $@ || logger -t mac80211 "Failed command: iw $@"
}
+NEWAPLIST=
+OLDAPLIST=
+NEWSPLIST=
+OLDSPLIST=
+
drv_mac80211_init_device_config() {
hostapd_common_add_device_config
@@ -57,7 +62,7 @@ drv_mac80211_init_iface_config() {
config_add_string 'macaddr:macaddr' ifname
- config_add_boolean wds powersave
+ config_add_boolean wds powersave enable
config_add_int maxassoc
config_add_int max_listen_int
config_add_int dtim_period
@@ -456,7 +461,7 @@ mac80211_iw_interface_add() {
mac80211_prepare_vif() {
json_select config
- json_get_vars ifname mode ssid wds powersave macaddr
+ json_get_vars ifname mode ssid wds powersave macaddr enable
[ -n "$ifname" ] || ifname="wlan${phy#phy}${if_idx:+-$if_idx}"
if_idx=$((${if_idx:-0} + 1))
@@ -492,8 +497,8 @@ mac80211_prepare_vif() {
mac80211_hostapd_setup_bss "$phy" "$ifname" "$macaddr"
"$type" || return
+ NEWAPLIST="${NEWAPLIST}$ifname "
[ -n "$hostapd_ctrl" ] || {
- mac80211_iw_interface_add "$phy" "$ifname" __ap
|| return
hostapd_ctrl="${hostapd_ctrl:-/var/run/hostapd/$ifname}"
}
;;
@@ -505,7 +510,7 @@ mac80211_prepare_vif() {
;;
sta)
local wdsflag=
- staidx="$(($staidx + 1))"
+ [ "$enable" = 0 ] || staidx="$(($staidx + 1))"
[ "$wds" -gt 0 ] && wdsflag="4addr on"
mac80211_iw_interface_add "$phy" "$ifname" managed
"$wdsflag" || return
[ "$powersave" -gt 0 ] && powersave="on" ||
powersave="off"
@@ -531,19 +536,51 @@ mac80211_prepare_vif() {
}
mac80211_setup_supplicant() {
+ local add_sp=0
+ local spobj="$(ubus -S list | grep wpa_supplicant.${ifname})"
+
wpa_supplicant_prepare_interface "$ifname" nl80211 || return 1
+ wpa_supplicant_prepare_interface "$ifname" nl80211 || {
+ iw dev "$ifname" del
+ return 1
+ }
if [ "$mode" = "sta" ]; then
wpa_supplicant_add_network "$ifname"
else
wpa_supplicant_add_network "$ifname" "$freq" "$htmode" "$noscan"
fi
- wpa_supplicant_run "$ifname" ${hostapd_ctrl:+-H $hostapd_ctrl}
+
+ NEWSPLIST="${NEWSPLIST}$ifname "
+
+ if [ "${NEWAPLIST%% *}" != "${OLDAPLIST%% *}" ]; then
+ [ "$spobj" ] && ubus call wpa_supplicant.${phy} config_del
"{\"iface\":\"$ifname\"}"
+ add_sp=1
+ fi
+ [ -z "$spobj" ] && add_sp=1
+
+ if [ "$add_sp" = "1" ]; then
+ wpa_supplicant_run "$ifname" "$hostapd_ctrl"
+ else
+ ubus call $spobj reload
+ fi
}
mac80211_setup_supplicant_noctl() {
- wpa_supplicant_prepare_interface "$ifname" nl80211 || return 1
+ local spobj="$(ubus -S list | grep wpa_supplicant.${ifname})"
+ wpa_supplicant_prepare_interface "$ifname" nl80211 || {
+ iw dev "$ifname" del
+ return 1
+ }
+
wpa_supplicant_add_network "$ifname" "$freq" "$htmode" "$noscan"
- wpa_supplicant_run "$ifname"
+
+ NEWSPLIST="${NEWSPLIST}$ifname "
+
+ if [ -z "$spobj" ]; then
+ wpa_supplicant_run "$ifname"
+ else
+ ubus call $spobj reload
+ fi
}
mac80211_setup_adhoc_htmode() {
@@ -581,7 +618,6 @@ mac80211_setup_adhoc_htmode() {
;;
*) ibss_htmode="" ;;
esac
-
}
mac80211_setup_adhoc() {
@@ -672,6 +708,7 @@ mac80211_setup_mesh() {
mac80211_setup_vif() {
local name="$1"
local failed
+ local action=up
json_select data
json_get_vars ifname
@@ -680,13 +717,15 @@ mac80211_setup_vif() {
json_select config
json_get_vars mode
json_get_var vif_txpower txpower
+ json_get_var vif_enable enable 1
- ip link set dev "$ifname" up || {
+ [ "$vif_enable" = 1 ] || action=down
+ logger ip link set dev "$ifname" $action
+ ip link set dev "$ifname" "$action" || {
wireless_setup_vif_failed
[OpenWrt-Devel] [PATCH netifd 2/5] wireless: serialize wireless interface configuration
From: John Crispin
Signed-off-by: Daniel Golle
---
wireless.c | 57 --
wireless.h | 7 +++
2 files changed, 62 insertions(+), 2 deletions(-)
diff --git a/wireless.c b/wireless.c
index 9986e9a..06afea3 100644
--- a/wireless.c
+++ b/wireless.c
@@ -23,6 +23,8 @@ struct vlist_tree wireless_devices;
struct avl_tree wireless_drivers;
static struct blob_buf b;
static int drv_fd;
+static LIST_HEAD(handlers);
+static bool handler_pending;
static const struct blobmsg_policy wdev_policy =
{ .name = "disabled", .type = BLOBMSG_TYPE_BOOL };
@@ -52,6 +54,15 @@ static const struct uci_blob_param_list vif_param = {
.params = vif_policy,
};
+static void
+wireless_handler_stop(struct wireless_device *wdev)
+{
+ if (wdev->handler_pending) {
+ wdev->handler_pending = false;
+ list_del(>handler);
+ }
+}
+
static void
put_container(struct blob_buf *buf, struct blob_attr *attr, const char *name)
{
@@ -188,6 +199,7 @@ wireless_device_free_state(struct wireless_device *wdev)
{
struct wireless_interface *vif;
+ wireless_handler_stop(wdev);
uloop_timeout_cancel(>script_check);
uloop_timeout_cancel(>timeout);
wireless_complete_kill_request(wdev);
@@ -236,6 +248,7 @@ wireless_device_setup_cancel(struct wireless_device *wdev)
if (wdev->cancel)
return;
+ wireless_handler_stop(wdev);
D(WIRELESS, "Cancel wireless device '%s' setup\n", wdev->name);
wdev->cancel = true;
uloop_timeout_set(>timeout, 10 * 1000);
@@ -250,6 +263,17 @@ wireless_device_run_handler(struct wireless_device *wdev,
bool up)
int i = 0;
int fds[2] = { -1, -1 };
+ wireless_handler_stop(wdev);
+
+ if (handler_pending && wdev->serialize) {
+ wdev->handler_action = up;
+ wdev->handler_pending = true;
+ list_add_tail(>handler, );
+ return;
+ }
+ if (wdev->serialize)
+ handler_pending = true;
+
D(WIRELESS, "Wireless device '%s' run %s handler\n", wdev->name,
action);
if (!up && wdev->prev_config) {
config = blobmsg_format_json(wdev->prev_config, true);
@@ -281,6 +305,21 @@ wireless_device_run_handler(struct wireless_device *wdev,
bool up)
free(config);
}
+static void
+wireless_handler_next(void)
+{
+ struct wireless_device *wdev;
+
+ if (handler_pending)
+ return;
+ if (list_empty())
+ return;
+ wdev = list_first_entry(, struct wireless_device, handler);
+ list_del(>handler);
+ wdev->handler_pending = false;
+ wireless_device_run_handler(wdev, wdev->handler_action);
+}
+
static void
__wireless_device_set_up(struct wireless_device *wdev, int force)
{
@@ -305,6 +344,7 @@ __wireless_device_set_up(struct wireless_device *wdev, int
force)
static void
wireless_device_free(struct wireless_device *wdev)
{
+ wireless_handler_stop(wdev);
vlist_flush_all(>interfaces);
avl_delete(_devices.avl, >node.avl);
free(wdev->config);
@@ -353,6 +393,10 @@ wireless_device_setup_timeout(struct uloop_timeout
*timeout)
{
struct wireless_device *wdev = container_of(timeout, struct
wireless_device, timeout);
+ if (wdev->handler_pending) {
+ wdev->handler_pending = false;
+ list_del(>handler);
+ }
netifd_kill_process(>script_task);
wdev->script_task.cb(>script_task, -1);
wireless_device_mark_down(wdev);
@@ -371,7 +415,7 @@ wireless_device_reconf(struct wireless_device *wdev)
{
wdev->retry = WIRELESS_SETUP_RETRY;
wdev->autostart = true;
- __wireless_device_set_up(wdev, 1);
+ __wireless_device_set_up(wdev, wdev->reconf && (wdev->state == IFS_UP));
}
static void
@@ -433,6 +477,11 @@ wireless_device_script_task_cb(struct netifd_process
*proc, int ret)
default:
break;
}
+
+ if (wdev->serialize) {
+ handler_pending = false;
+ wireless_handler_next();
+ }
}
void
@@ -452,7 +501,7 @@ wdev_set_config_state(struct wireless_device *wdev, enum
interface_config_state
wdev->config_state = s;
if (wdev->state == IFS_DOWN)
wdev_handle_config_change(wdev);
- else
+ else if (!wdev->reconf || wdev->state != IFS_UP)
__wireless_device_set_down(wdev);
}
@@ -501,6 +550,7 @@ wdev_update(struct vlist_tree *tree, struct vlist_node
*node_new,
struct wireless_device *wd_new = container_of(node_new, struct
wireless_device, node);
if (wd_old && wd_new) {
+ D(WIRELESS, "Update wireless device '%s'\n", wd_old->name);
wdev_change_config(wd_old, wd_new);
} else if (wd_old) {
D(WIRELESS, "Delete wireless device '%s'\n", wd_old->name);
@@
[OpenWrt-Devel] [PATCH 5/5] base-files: add 'wifi reconf'
From: John Crispin
Now that netifd and hostapd allow dynamic reconfiguration, add a
command to trigger it.
Signed-off-by: Daniel Golle
---
package/base-files/files/sbin/wifi | 5 +
1 file changed, 5 insertions(+)
diff --git a/package/base-files/files/sbin/wifi
b/package/base-files/files/sbin/wifi
index f7a10de215..261d2fb500 100755
--- a/package/base-files/files/sbin/wifi
+++ b/package/base-files/files/sbin/wifi
@@ -130,6 +130,10 @@ wifi_updown() {
scan_wifi
cmd=up
}
+ [ reconf = "$1" ] && {
+ scan_wifi
+ cmd=reconf
+ }
ubus_wifi_cmd "$cmd" "$2"
_wifi_updown "$@"
}
@@ -241,6 +245,7 @@ case "$1" in
reload) wifi_reload "$2";;
reload_legacy) wifi_reload_legacy "$2";;
--help|help) usage;;
+ reconf) ubus call network reload; wifi_updown "reconf" "$2";;
''|up) ubus call network reload; wifi_updown "enable" "$2";;
*) usage; exit 1;;
esac
--
2.23.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 3/5] hostapd: add ubus reload
From: John Crispin
Add ubus interface to hostapd and wpa_supplicant to allow dynamically
reloading wiface configuration without having to restart the hostapd
process.
As a consequence, bost hostapd and wpa_supplicant are now started
persistently on boot for each wifi device in the system and then
receive ubus calls adding, modifying or removing interface
configuration.
At a later stage it would be desirable to reduce the services to one
single instance of each managing all radios.
Signed-off-by: John Crispin
Signed-off-by: Daniel Golle
---
package/network/services/hostapd/Makefile | 3 +-
.../services/hostapd/files/hostapd.hotplug| 14 ++
.../network/services/hostapd/files/hostapd.sh | 25 +--
.../hostapd/patches/600-ubus_support.patch| 127 -
.../hostapd/patches/700-wifi-reload.patch | 118
.../services/hostapd/src/src/ap/ubus.c| 131 -
.../services/hostapd/src/src/ap/ubus.h| 12 ++
.../hostapd/src/wpa_supplicant/ubus.c | 176 +-
.../hostapd/src/wpa_supplicant/ubus.h | 13 ++
9 files changed, 600 insertions(+), 19 deletions(-)
create mode 100644 package/network/services/hostapd/files/hostapd.hotplug
create mode 100644
package/network/services/hostapd/patches/700-wifi-reload.patch
diff --git a/package/network/services/hostapd/Makefile
b/package/network/services/hostapd/Makefile
index 4f6420f503..52adb1115e 100644
--- a/package/network/services/hostapd/Makefile
+++ b/package/network/services/hostapd/Makefile
@@ -519,8 +519,9 @@ define Install/supplicant
endef
define Package/hostapd-common/install
- $(INSTALL_DIR) $(1)/lib/netifd $(1)/etc/rc.button
+ $(INSTALL_DIR) $(1)/lib/netifd $(1)/etc/rc.button
$(1)/etc/hotplug.d/ieee80211
$(INSTALL_DATA) ./files/hostapd.sh $(1)/lib/netifd/hostapd.sh
+ $(INSTALL_BIN) ./files/hostapd.hotplug
$(1)/etc/hotplug.d/ieee80211/20-hostapd
$(INSTALL_BIN) ./files/wps-hotplug.sh $(1)/etc/rc.button/wps
endef
diff --git a/package/network/services/hostapd/files/hostapd.hotplug
b/package/network/services/hostapd/files/hostapd.hotplug
new file mode 100644
index 00..d568b3c85a
--- /dev/null
+++ b/package/network/services/hostapd/files/hostapd.hotplug
@@ -0,0 +1,14 @@
+#!/bin/sh
+
+[ ${ACTION} = "remove" -a -n "${DEVICENAME}" ] && {
+ kill $(cat /var/run/hostapd-${DEVICENAME}.pid)
+ rm -rf /var/run/hostapd-${DEVICENAME}.pid
/var/run/hostapd-${DEVICENAME}/
+ kill $(cat /var/run/wpa_supplicant-${DEVICENAME}.pid)
+ rm -rf /var/run/wpa_supplicant-${DEVICENAME}.pid
/var/run/wpa_supplicant-${DEVICENAME}/
+}
+
+[ ${ACTION} = "add" -a -n "${DEVICENAME}" ] && {
+ /usr/sbin/hostapd -s -n ${DEVICENAME} -P
/var/run/hostapd-${DEVICENAME}.pid -g /var/run/hostapd-${DEVICENAME}/global -B &
+ mkdir -p /var/run/wpa_supplicant-${DEVICENAME}
+ /usr/sbin/wpa_supplicant -s -n ${DEVICENAME} -P
/var/run/wpa_supplicant-${DEVICENAME}.pid -g
/var/run/wpa_supplicant-${DEVICENAME}/global -B &
+}
diff --git a/package/network/services/hostapd/files/hostapd.sh
b/package/network/services/hostapd/files/hostapd.sh
index 8da8539e8a..d2d9f95f59 100644
--- a/package/network/services/hostapd/files/hostapd.sh
+++ b/package/network/services/hostapd/files/hostapd.sh
@@ -252,7 +252,7 @@ hostapd_set_bss_options() {
wireless_vif_parse_encryption
- local bss_conf
+ local bss_conf bss_md5sum
local wep_rekey wpa_group_rekey wpa_pair_rekey wpa_master_rekey
wpa_key_mgmt
json_get_vars \
@@ -607,6 +607,9 @@ hostapd_set_bss_options() {
}
}
+ bss_md5sum=$(echo $bss_conf | md5sum | cut -d" " -f1)
+ append bss_conf "config_id=$bss_md5sum" "$N"
+
append "$var" "$bss_conf" "$N"
return 0
}
@@ -930,21 +933,19 @@ EOF
}
wpa_supplicant_run() {
- local ifname="$1"; shift
+ local ifname="$1"
+ local hostapd_ctrl="$2"
_wpa_supplicant_common "$ifname"
- /usr/sbin/wpa_supplicant -B -s \
- ${network_bridge:+-b $network_bridge} \
- -P "/var/run/wpa_supplicant-${ifname}.pid" \
- -D ${_w_driver:-wext} \
- -i "$ifname" \
- -c "$_config" \
- -C "$_rpath" \
- "$@"
+ ubus call wpa_supplicant.$phy config_add "{ \
+ \"driver\": \"${_w_driver:-wext}\", \"ctrl\": \"$_rpath\", \
+ \"iface\": \"$ifname\", \"config\": \"$_config\" \
+ ${network_bridge:+, \"bridge\": \"$network_bridge\"} \
+ ${hostapd_ctrl:+, \"hostapd_ctrl\": \"$hostapd_ctrl\"} \
+ }"
ret="$?"
- wireless_add_process "$(cat "/var/run/wpa_supplicant-${ifname}.pid")"
/usr/sbin/wpa_supplicant 1
[ "$ret" != 0 ] && wireless_setup_vif_failed WPA_SUPPLICANT_FAILED
@@ -952,5 +953,5 @@ wpa_supplicant_run() {
}
hostapd_common_cleanup() {
- killall hostapd
Re: [OpenWrt-Devel] ath79/qca9533rev2: Help needed on missing GPIO on ath9k-phy0
Hi Adrian, On 30.10.2019 15:30, Adrian Schmutzler wrote: Hi, we are still working on broken WiFi on CPE210v2/v3 (ath79, QCA9533 rev. 2) and have found that on ath79 a GPIO is missing compared to ar71xx (where WIFI is working): It's not missing, it's there, just not controlled by the ath9k driver. There is no separated radio (just the built-in one) on this platform so all GPIOs belong to the main SOC and can be controlled with ath79-gpio. See also: https://github.com/openwrt/openwrt/commit/d35f2a5565fc51fb277f72a8565c871ce1785588 -- Cheers, Piotr GPIO Config on the ar71xx: gpiochip0: GPIOs 0-31, parent: platform/ath79-gpio, ath79-gpio: gpio-11 (|tp-link:green:lan0 ) out hi gpio-13 (|tp-link:green:link1 ) out hi gpio-14 ( |tp-link:green:link2 ) out hi gpio-15 ( |tp-link:green:link3 ) out hi gpio-16 ( |tp-link:green:link4 ) out hi gpio-17 (|Reset button) in hi gpiochip1: GPIOs 494-511, ath9k-phy0: gpio-495 ( |ath9k-phy0 ) in lo On the ath79: gpio-11 (|tp-link:green:lan ) out lo gpio-13 (|tp-link:green:link1 ) out hi gpio-14 ( |tp-link:green:link2 ) out hi gpio-15 ( |tp-link:green:link3 ) out hi gpio-16 ( |tp-link:green:link4 ) out hi gpio-17 (|Reset button) in hi Can somebody point out how we can introduce the ath9k gpio? Or may this be already the result of something broken at an earlier step? Best Adrian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH netifd 1/5] wireless: add ubus method for reloading configuration
From: John Crispin
Signed-off-by: Daniel Golle
---
ubus.c | 23 +++
wireless.c | 18 +-
wireless.h | 1 +
3 files changed, 37 insertions(+), 5 deletions(-)
diff --git a/ubus.c b/ubus.c
index 150d818..5a2a339 100644
--- a/ubus.c
+++ b/ubus.c
@@ -1081,6 +1081,28 @@ get_wdev(struct blob_attr *msg, int *ret)
return wdev;
}
+static int
+netifd_handle_wdev_reconf(struct ubus_context *ctx, struct ubus_object *obj,
+ struct ubus_request_data *req, const char *method,
+ struct blob_attr *msg)
+{
+ struct wireless_device *wdev;
+ int ret;
+
+ wdev = get_wdev(msg, );
+ if (ret == UBUS_STATUS_NOT_FOUND)
+ return ret;
+
+ if (wdev) {
+ wireless_device_reconf(wdev);
+ } else {
+ vlist_for_each_element(_devices, wdev, node)
+ wireless_device_reconf(wdev);
+ }
+
+ return 0;
+}
+
static int
netifd_handle_wdev_up(struct ubus_context *ctx, struct ubus_object *obj,
struct ubus_request_data *req, const char *method,
@@ -1189,6 +1211,7 @@ netifd_handle_wdev_notify(struct ubus_context *ctx,
struct ubus_object *obj,
static struct ubus_method wireless_object_methods[] = {
{ .name = "up", .handler = netifd_handle_wdev_up },
{ .name = "down", .handler = netifd_handle_wdev_down },
+ { .name = "reconf", .handler = netifd_handle_wdev_reconf },
{ .name = "status", .handler = netifd_handle_wdev_status },
{ .name = "notify", .handler = netifd_handle_wdev_notify },
{ .name = "get_validate", .handler = netifd_handle_wdev_get_validate },
diff --git a/wireless.c b/wireless.c
index 387f4ba..9986e9a 100644
--- a/wireless.c
+++ b/wireless.c
@@ -282,7 +282,7 @@ wireless_device_run_handler(struct wireless_device *wdev,
bool up)
}
static void
-__wireless_device_set_up(struct wireless_device *wdev)
+__wireless_device_set_up(struct wireless_device *wdev, int force)
{
if (wdev->disabled)
return;
@@ -293,7 +293,7 @@ __wireless_device_set_up(struct wireless_device *wdev)
if (!wdev->autostart)
return;
- if (wdev->state != IFS_DOWN || config_init)
+ if (!force && (wdev->state != IFS_DOWN || config_init))
return;
free(wdev->prev_config);
@@ -320,7 +320,7 @@ wdev_handle_config_change(struct wireless_device *wdev)
switch(state) {
case IFC_NORMAL:
case IFC_RELOAD:
- __wireless_device_set_up(wdev);
+ __wireless_device_set_up(wdev, 0);
wdev->config_state = IFC_NORMAL;
break;
@@ -363,7 +363,15 @@ wireless_device_set_up(struct wireless_device *wdev)
{
wdev->retry = WIRELESS_SETUP_RETRY;
wdev->autostart = true;
- __wireless_device_set_up(wdev);
+ __wireless_device_set_up(wdev, 0);
+}
+
+void
+wireless_device_reconf(struct wireless_device *wdev)
+{
+ wdev->retry = WIRELESS_SETUP_RETRY;
+ wdev->autostart = true;
+ __wireless_device_set_up(wdev, 1);
}
static void
@@ -1001,5 +1009,5 @@ wireless_start_pending(void)
struct wireless_device *wdev;
vlist_for_each_element(_devices, wdev, node)
- __wireless_device_set_up(wdev);
+ __wireless_device_set_up(wdev, 0);
}
diff --git a/wireless.h b/wireless.h
index 3498bd8..bade738 100644
--- a/wireless.h
+++ b/wireless.h
@@ -93,6 +93,7 @@ struct wireless_process {
void wireless_device_create(struct wireless_driver *drv, const char *name,
struct blob_attr *data);
void wireless_device_set_up(struct wireless_device *wdev);
void wireless_device_set_down(struct wireless_device *wdev);
+void wireless_device_reconf(struct wireless_device *wdev);
void wireless_device_status(struct wireless_device *wdev, struct blob_buf *b);
void wireless_device_get_validate(struct wireless_device *wdev, struct
blob_buf *b);
void wireless_interface_create(struct wireless_device *wdev, struct blob_attr
*data, const char *section);
--
2.23.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH-19.07] build: fix module strip invalid
On 10/30/19 11:14 AM, daxiong wrote:
> Current modpost cannot reduce the module size.
>
> Use $(STRIP) command to replace the modpost patch,
> I think to be compatibility will be better.
>
> Signed-off-by: daxiong
Please base this against master, then we can backport it to 19.07.
Could you please elaborate a little bit more how module-strip provides
better results than the previous patch? It would be nice if you could
also provide some numbers to compare the previous size and the current size.
Would it make sense to do both together, what was done in this patch
before and after your change?
Hauke
> ---
> .../linux/generic/hack-4.14/204-module_strip.patch | 216
> +++--
> 1 file changed, 24 insertions(+), 192 deletions(-)
>
> diff --git a/target/linux/generic/hack-4.14/204-module_strip.patch
> b/target/linux/generic/hack-4.14/204-module_strip.patch
> index d847adf..c22a507 100644
> --- a/target/linux/generic/hack-4.14/204-module_strip.patch
> +++ b/target/linux/generic/hack-4.14/204-module_strip.patch
> @@ -1,104 +1,8 @@
> -From a779a482fb9b9f8fcdf8b2519c789b4b9bb5dd05 Mon Sep 17 00:00:00 2001
> -From: Felix Fietkau
> -Date: Fri, 7 Jul 2017 16:56:48 +0200
> -Subject: build: add a hack for removing non-essential module info
> -
> -Signed-off-by: Felix Fietkau
>
> - include/linux/module.h | 13 -
> - include/linux/moduleparam.h | 15 ---
> - init/Kconfig| 7 +++
> - kernel/module.c | 5 -
> - scripts/mod/modpost.c | 12
> - 5 files changed, 43 insertions(+), 9 deletions(-)
> -
> a/include/linux/module.h
> -+++ b/include/linux/module.h
> -@@ -158,6 +158,7 @@ extern void cleanup_module(void);
> -
> - /* Generic info of form tag = "info" */
> - #define MODULE_INFO(tag, info) __MODULE_INFO(tag, tag, info)
> -+#define MODULE_INFO_STRIP(tag, info) __MODULE_INFO_STRIP(tag, tag, info)
> -
> - /* For userspace: you can also call me... */
> - #define MODULE_ALIAS(_alias) MODULE_INFO(alias, _alias)
> -@@ -201,12 +202,12 @@ extern void cleanup_module(void);
> - * Author(s), use "Name " or just "Name", for multiple
> - * authors use multiple MODULE_AUTHOR() statements/lines.
> - */
> --#define MODULE_AUTHOR(_author) MODULE_INFO(author, _author)
> -+#define MODULE_AUTHOR(_author) MODULE_INFO_STRIP(author, _author)
> -
> - /* What your module does. */
> --#define MODULE_DESCRIPTION(_description) MODULE_INFO(description,
> _description)
> -+#define MODULE_DESCRIPTION(_description) MODULE_INFO_STRIP(description,
> _description)
> -
> --#ifdef MODULE
> -+#if defined(MODULE) && !defined(CONFIG_MODULE_STRIPPED)
> - /* Creates an alias so file2alias.c can find device table. */
> - #define MODULE_DEVICE_TABLE(type, name)
> \
> - extern typeof(name) __mod_##type##__##name##_device_table \
> -@@ -233,7 +234,9 @@ extern typeof(name) __mod_##type##__##na
> - */
> -
> - #if defined(MODULE) || !defined(CONFIG_SYSFS)
> --#define MODULE_VERSION(_version) MODULE_INFO(version, _version)
> -+#define MODULE_VERSION(_version) MODULE_INFO_STRIP(version, _version)
> -+#elif defined(CONFIG_MODULE_STRIPPED)
> -+#define MODULE_VERSION(_version) __MODULE_INFO_DISABLED(version)
> - #else
> - #define MODULE_VERSION(_version)\
> - static struct module_version_attribute ___modver_attr = { \
> -@@ -255,7 +258,7 @@ extern typeof(name) __mod_##type##__##na
> - /* Optional firmware file (or files) needed by the module
> - * format is simply firmware file name. Multiple firmware
> - * files require multiple MODULE_FIRMWARE() specifiers */
> --#define MODULE_FIRMWARE(_firmware) MODULE_INFO(firmware, _firmware)
> -+#define MODULE_FIRMWARE(_firmware) MODULE_INFO_STRIP(firmware, _firmware)
> -
> - struct notifier_block;
> -
> a/include/linux/moduleparam.h
> -+++ b/include/linux/moduleparam.h
> -@@ -17,6 +17,16 @@
> - /* Chosen so that structs with an unsigned long line up. */
> - #define MAX_PARAM_PREFIX_LEN (64 - sizeof(unsigned long))
> -
> -+/* This struct is here for syntactic coherency, it is not used */
> -+#define __MODULE_INFO_DISABLED(name)
> \
> -+ struct __UNIQUE_ID(name) {}
> -+
> -+#ifdef CONFIG_MODULE_STRIPPED
> -+#define __MODULE_INFO_STRIP(tag, name, info) __MODULE_INFO_DISABLED(name)
> -+#else
> -+#define __MODULE_INFO_STRIP(tag, name, info) __MODULE_INFO(tag, name, info)
> -+#endif
> -+
> - #ifdef MODULE
> - #define __MODULE_INFO(tag, name, info)
> \
> - static const char __UNIQUE_ID(name)[]
> \
> -@@ -24,8 +34,7 @@ static const char __UNIQUE_ID(name)[]
> - = __stringify(tag) "=" info
> - #else /* !MODULE */
> - /* This struct is here for syntactic coherency, it is not used */
> --#define __MODULE_INFO(tag, name, info)
> \
> -- struct
Re: [OpenWrt-Devel] v5.4 as next kernel
On 10/29/19 6:37 AM, John Crispin wrote: > Hi, > should we use v5.4 as our next kernel ? > John I also agree to have kernel 5.4 as the next kernel, it will be finally released in about 1 months and it is a long term kernel. If we are lucky it will be supported for 6 years for Android. What do we want to use in the next 20.X release after 19.07? If we want to go with kernel 5.4 with the release after 19.07 we can not make this release before April, I would assume. We would have generic support in OpenWrt master in about 1 month and then we will port the targets, probably we will have the most important targets ported about 2 months later (Mid January 2020) and can stabilize and port the rest of afterwards. hauke signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/3] ipq40xx: ipq4019: Add new device Compex WPJ419
On 10/30/19 4:27 AM, Daniel Danzberger wrote:
This device contains 2 flash devices. One NOR (32M) and one NAND (128M).
U-boot and caldata are on the NOR, the firmware on the NAND.
SoC:IPQ4019
CPU:4x 710MHz ARMv7
RAM:256MB
FLASH: NOR:32MB NAND:128MB
[...]
.../arch/arm/boot/dts/qcom-ipq4019-bus.dtsi | 1142 +
.../include/dt-bindings/msm/msm-bus-ids.h | 869 +
The sudden appearance of a need the MSM bus and its IDs worries me.
With 25 devices already on the ipq40xx platform without them, it feels
like something is missing if they are needed by this one.
diff --git a/target/linux/ipq40xx/config-4.19 b/target/linux/ipq40xx/config-4.19
index 8948b73ff7..3ee921abed 100644
--- a/target/linux/ipq40xx/config-4.19
+++ b/target/linux/ipq40xx/config-4.19
@@ -303,6 +303,9 @@ CONFIG_MTD_NAND_ECC=y
CONFIG_MTD_NAND_QCOM=y
CONFIG_MTD_SPI_NAND=y
CONFIG_MTD_SPI_NOR=y
+CONFIG_MTD_SPINAND_MT29F=y
+CONFIG_MTD_SPINAND_GIGADEVICE=y
+CONFIG_MTD_SPINAND_ONDIEECC=y
The CONFIG_SPINAND_* additions are not required for upstream SPI-NAND
CONFIG_MTD_SPLIT_FIRMWARE=y
CONFIG_MTD_SPLIT_FIT_FW=y
CONFIG_MTD_UBI=y
[...]
diff --git
a/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-wpj419.dts
b/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-wpj419.dts
new file mode 100644
index 00..5553bbd166
--- /dev/null
+++ b/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-wpj419.dts
@@ -0,0 +1,371 @@
+/* Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2019, Nguyen Dinh Phi
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ *
+ */
+
[...]
+
+ spi_0: spi@78b5000 {
+ pinctrl-0 = <_0_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ cs-gpios = < 12 GPIO_ACTIVE_HIGH>, < 41
GPIO_ACTIVE_HIGH>;
+ num-cs = <2>;
+
+ m25p80@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0>;
+ linux,modalias = "m25p80", "n25q128a11";
+ compatible = "jedec,spi-nor", "n25q128a11";
+ spi-max-frequency = <2400>;
I don't think you need linux,modalias here, nor the chip type in the
compatible line.
I believe that the following compatible line is sufficient
compatible = "jedec,spi-nor";
You might also want to consider "flash@0" or "nor@0" or "nor_flash@0",
or the like, rather than a chip-specific name. (I'm not a committer.)
+
+ partitions {
+ compatible = "fixed-partitions";
+
+ partition@0 {
+ label = "0:SBL1";
+ reg = <0x00 0x04>;
+ read-only;
+ };
+
+ partition@4 {
+ label = "0:MIBIB";
+ reg = <0x04 0x02>;
+ read-only;
+ };
+
+ partition@6 {
+ label = "0:QSEE";
+ reg = <0x06 0x06>;
+ read-only;
+ };
+
+ partition@c {
+ label = "0:CDT";
+ reg = <0x0c 0x01>;
+ read-only;
+ };
Someone may rip on you for capitalization of labels. (I'm not a committer.)
+
+ partition@d {
+ label = "0:DDRPARAMS";
+
Re: [OpenWrt-Devel] [PATCH 0/6] buildsystem: Activate PIE ASLR for some packages
On 10/28/19 10:14 AM, Daniel Engberg wrote: > On 2019-10-27 18:44, Hauke Mehrtens wrote: >> This is a follow up patch on this discussion on the mailing list: >> https://patchwork.ozlabs.org/patch/1041647/ >> >> This allows to activate PIE only for some packages where we thing it is >> necessary and not only globally for all of them. >> >> Hauke Mehrtens (6): >> buildsystem: Make PIE ASLR option tristate >> dnsmasq: Activate PIE by default >> dropbear: Activate PIE by default >> hostapd: Activate PIE by default >> uhttpd: Activate PIE by default >> lantiq: Allow PKG_ASLR_PIE for DSL and voice drivers >> >> config/Config-build.in | 22 >> include/hardening.mk | 9 +++- >> package/kernel/lantiq/ltq-adsl/Makefile | 1 - >> package/kernel/lantiq/ltq-ifxos/Makefile | 1 - >> package/kernel/lantiq/ltq-tapi/Makefile | 1 - >> package/kernel/lantiq/ltq-vdsl-mei/Makefile | 2 -- >> package/kernel/lantiq/ltq-vdsl/Makefile | 1 - >> package/kernel/lantiq/ltq-vmmc/Makefile | 1 - >> package/network/config/ltq-vdsl-app/Makefile | 1 - >> package/network/services/dnsmasq/Makefile | 1 + >> package/network/services/dropbear/Makefile | 1 + >> package/network/services/hostapd/Makefile | 1 + >> package/network/services/uhttpd/Makefile | 1 + >> 13 files changed, 30 insertions(+), 13 deletions(-) > > I think ASLRs value needs to be evaluated especially due to the > performance penalty (hostapd mainly in that regard) and not to forget > size increase depending on for how long OpenWrt intends to keep 8Mbyte > devices around as 4Mbyte devices are more or less unsupported by now. > It's probably a better idea to only enable it on aarch64 and x86-64 > where size isn't as much of a concern and where it probably(?) receives > most exposure to avoid uncessary breakage. > > http://intx0x80.blogspot.com/2018/04/bypass-aslrnx-part-1.html > https://svnweb.freebsd.org/base?view=revision=343964 > Might also be worth taking into consideration. > > Best regards, > Daniel Yes ASLR is not preventing any exploits it just makes it harder for an attacker like most other mechanisms too. Especially on 32 bit platforms like MIPS 32 bit and ARM 32 bit we only use 8 bit of the address for ASLR, on 64 bit platforms this feature is a lot more useful as we have a lot more bits. I am wondering why the kernel takes CONFIG_ARCH_MMAP_RND_BITS_MIN as the default for CONFIG_ARCH_MMAP_RND_BITS and not the max value, on MIPS 32 bit min is 8 bits and max is 16 bit. https://elixir.bootlin.com/linux/v4.19.79/source/arch/Kconfig#L598 Do you know any benchmark results measuring the performance penalty of ASLR and PIE? Hauke signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath79/qca9533rev2: Help needed on missing GPIO on ath9k-phy0
What about ar9533 devices on ath79 that do have working wifi, is that gpio present there? As far as I understand the idea was to use alias gpio chip (starting from 494) on ath79 instead of generic gpio (0-31) but I might be wrong about this. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/3] ipq40xx: Add gigadevice nandspi flash driver
> Is there a reason why the upstream SPI-NAND framework isn't being used? No, I didn't know about it. The patches I used are copied from a compex openwrt tree and have only been modified by me to run on kernel 4.19 I am going to checkout the new API and try to make the device work with it. On 10/30/19 4:15 PM, Jeff Kletsky wrote: > On 10/30/19 4:27 AM, Daniel Danzberger wrote: > >> This patch adds support for Gigadevice SPI NAND device to the mt29f stagging >> driver. >> >> Signed-off-by: Daniel Danzberger >> --- >> ...port-gigadevice-nandspi-flash-device.patch | 1778 + >> 1 file changed, 1778 insertions(+) >> create mode 100644 >> target/linux/ipq40xx/patches-4.19/400-mtd-nand-support-gigadevice-nandspi-flash-device.patch >> >> >> >> [...] > > > Is there a reason why the upstream SPI-NAND framework isn't being used? > > This has been demanded of the ath79 target (see, for example > https://github.com/openwrt/openwrt/pull/1428#issuecomment-441594401) > > and is available to the ipq40xx target and appears to already be in use by: > > qcom-ipq4018-rt-ac58u.dts > qcom-ipq4018-ea6350v3.dts > qcom-ipq4018-ap120c-ac.dts > qcom-ipq4018-jalapeno.dts > > > > Further, the mt29f driver has been removed from upstream Linux > > commit 647ad49ca672 > Author: Boris Brezillon > Date: Mon Oct 22 22:10:59 2018 +0200 > > staging: Remove the mt29f_spinand driver > > A new SPI NAND subsystem has been added in drivers/mtd/nand/spi/ and > Micron's MT29F devices are now supported in > drivers/mtd/nand/spi/micron.c. > > Remove the old driver. > > > > > The set of SPI-NAND chips supported by Linux 5.3 has already been > backported to OpenWrt `master`, including; GigaDevice, Macronix, > Micron, Paragon, Toshiba, and Winbond. > > > commit b9d58f7e06 > Author: Jeff Kletsky > Date: Thu Oct 24 09:54:11 2019 -0700 > > kernel: mtd: spinand: Backport chip definitions > > generic: Add/rename patches for upstream consistency > > ipq40xx: generic-level patch replaces same-source patches-4.19/ > 082-v4.20-mtd-spinand-winbond-Add-support-for-W25N01GV.patch > > The SPI-NAND framework from Linux uses common driver code that is then > "tuned" by a tiny struct of chip-specific data that describes > available commands, timing, and layout (data and OOB data). Several > manufacturers and chips have been added since 4.19, several of which > are used in devices already supported by OpenWrt (typically with no or > "legacy" access to their NAND memory). This commit catches up the > supported-chip definitions through Linux 5.2-rc6 and linux/next. > > The driver is only compiled for platforms with CONFIG_MTD_SPI_NAND=y. > This presently includes ipq40xx and pistachio, with the addition of > ath79-nand in these commits (and not ath79-generic or ath79-tiny). > > Upstream patches refreshed against 4.19.75 > > Build-tested-on: ipq40xx > Run-tested-on: ath79-nand > > > > -- Regards Daniel Danzberger embeDD GmbH, Alter Postplatz 2, CH-6370 Stans ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/3] ipq40xx: Add gigadevice nandspi flash driver
On 10/30/19 4:27 AM, Daniel Danzberger wrote: This patch adds support for Gigadevice SPI NAND device to the mt29f stagging driver. Signed-off-by: Daniel Danzberger --- ...port-gigadevice-nandspi-flash-device.patch | 1778 + 1 file changed, 1778 insertions(+) create mode 100644 target/linux/ipq40xx/patches-4.19/400-mtd-nand-support-gigadevice-nandspi-flash-device.patch [...] Is there a reason why the upstream SPI-NAND framework isn't being used? This has been demanded of the ath79 target (see, for example https://github.com/openwrt/openwrt/pull/1428#issuecomment-441594401) and is available to the ipq40xx target and appears to already be in use by: qcom-ipq4018-rt-ac58u.dts qcom-ipq4018-ea6350v3.dts qcom-ipq4018-ap120c-ac.dts qcom-ipq4018-jalapeno.dts Further, the mt29f driver has been removed from upstream Linux commit 647ad49ca672 Author: Boris Brezillon Date: Mon Oct 22 22:10:59 2018 +0200 staging: Remove the mt29f_spinand driver A new SPI NAND subsystem has been added in drivers/mtd/nand/spi/ and Micron's MT29F devices are now supported in drivers/mtd/nand/spi/micron.c. Remove the old driver. The set of SPI-NAND chips supported by Linux 5.3 has already been backported to OpenWrt `master`, including; GigaDevice, Macronix, Micron, Paragon, Toshiba, and Winbond. commit b9d58f7e06 Author: Jeff Kletsky Date: Thu Oct 24 09:54:11 2019 -0700 kernel: mtd: spinand: Backport chip definitions generic: Add/rename patches for upstream consistency ipq40xx: generic-level patch replaces same-source patches-4.19/ 082-v4.20-mtd-spinand-winbond-Add-support-for-W25N01GV.patch The SPI-NAND framework from Linux uses common driver code that is then "tuned" by a tiny struct of chip-specific data that describes available commands, timing, and layout (data and OOB data). Several manufacturers and chips have been added since 4.19, several of which are used in devices already supported by OpenWrt (typically with no or "legacy" access to their NAND memory). This commit catches up the supported-chip definitions through Linux 5.2-rc6 and linux/next. The driver is only compiled for platforms with CONFIG_MTD_SPI_NAND=y. This presently includes ipq40xx and pistachio, with the addition of ath79-nand in these commits (and not ath79-generic or ath79-tiny). Upstream patches refreshed against 4.19.75 Build-tested-on: ipq40xx Run-tested-on: ath79-nand ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath79/qca9533rev2: Help needed on missing GPIO on ath9k-phy0
Hi Dmitry, > Where I can see the DTS? Generally ath9k gpio is added by > gpio-controller property to the ath9k node. See dir825b1 as an example > an many others. ath79: https://github.com/openwrt/openwrt/blob/master/target/linux/ath79/dts/qca9533_tplink_cpe210.dtsi https://github.com/openwrt/openwrt/commit/141698ce8fbc52d253c9207ef46b3630a0870567 ar71xx: https://github.com/openwrt/openwrt/blob/master/target/linux/ar71xx/files/arch/mips/ath79/mach-cpe510.c#L212 The actual problem is that we have broken WiFi for _some_ of the devices (with no error messages anywhere). Details on that may be found at: https://github.com/openwrt/openwrt/pull/2514#issuecomment-547799576 Best Adrian openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath79/qca9533rev2: Help needed on missing GPIO on ath9k-phy0
Is one wireless adapter connected using PCIE? If it is true, you'll have to set it's node in DTS. Generally it's not required, but if you need a gpio controller, then you have to. ср, 30 окт. 2019 г. в 17:51, Dmitry Tunin : > > ср, 30 окт. 2019 г. в 17:31, Adrian Schmutzler : > > > > Hi, > > > > we are still working on broken WiFi on CPE210v2/v3 (ath79, QCA9533 rev. 2) > > and have found that on ath79 a GPIO is missing compared to ar71xx (where > > WIFI is working): > > > > GPIO Config on the ar71xx: > > > > gpiochip0: GPIOs 0-31, parent: platform/ath79-gpio, ath79-gpio: > > gpio-11 (|tp-link:green:lan0 ) out hi > > gpio-13 (|tp-link:green:link1 ) out hi > > gpio-14 (|tp-link:green:link2 ) out hi > > gpio-15 (|tp-link:green:link3 ) out hi > > gpio-16 (|tp-link:green:link4 ) out hi > > gpio-17 (|Reset button) in hi > > > > gpiochip1: GPIOs 494-511, ath9k-phy0: > > gpio-495 (|ath9k-phy0 ) in lo > > > > > > On the ath79: > > > > gpio-11 (|tp-link:green:lan ) out lo > > gpio-13 (|tp-link:green:link1 ) out hi > > gpio-14 (|tp-link:green:link2 ) out hi > > gpio-15 (|tp-link:green:link3 ) out hi > > gpio-16 (|tp-link:green:link4 ) out hi > > gpio-17 (|Reset button) in hi > > > > > > Can somebody point out how we can introduce the ath9k gpio? Or may this be > > already the result of something broken at an earlier step? > > Where I can see the DTS? Generally ath9k gpio is added by > gpio-controller property to the ath9k node. See dir825b1 as an example > an many others. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath79/qca9533rev2: Help needed on missing GPIO on ath9k-phy0
ср, 30 окт. 2019 г. в 17:31, Adrian Schmutzler : > > Hi, > > we are still working on broken WiFi on CPE210v2/v3 (ath79, QCA9533 rev. 2) > and have found that on ath79 a GPIO is missing compared to ar71xx (where WIFI > is working): > > GPIO Config on the ar71xx: > > gpiochip0: GPIOs 0-31, parent: platform/ath79-gpio, ath79-gpio: > gpio-11 (|tp-link:green:lan0 ) out hi > gpio-13 (|tp-link:green:link1 ) out hi > gpio-14 (|tp-link:green:link2 ) out hi > gpio-15 (|tp-link:green:link3 ) out hi > gpio-16 (|tp-link:green:link4 ) out hi > gpio-17 (|Reset button) in hi > > gpiochip1: GPIOs 494-511, ath9k-phy0: > gpio-495 (|ath9k-phy0 ) in lo > > > On the ath79: > > gpio-11 (|tp-link:green:lan ) out lo > gpio-13 (|tp-link:green:link1 ) out hi > gpio-14 (|tp-link:green:link2 ) out hi > gpio-15 (|tp-link:green:link3 ) out hi > gpio-16 (|tp-link:green:link4 ) out hi > gpio-17 (|Reset button) in hi > > > Can somebody point out how we can introduce the ath9k gpio? Or may this be > already the result of something broken at an earlier step? Where I can see the DTS? Generally ath9k gpio is added by gpio-controller property to the ath9k node. See dir825b1 as an example an many others. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] ath79: add support for Netgear WNDR4300
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On > Behalf Of Michal Cieslakiewicz > Sent: Mittwoch, 30. Oktober 2019 15:28 > To: Adrian Schmutzler > Cc: openwrt-devel@lists.openwrt.org > Subject: Re: [OpenWrt-Devel] [PATCH v2] ath79: add support for Netgear > WNDR4300 > > > Hello Adrian, > > Thanks for your feedback! > > > Hi, > > > > Same question I asked on zyxel support: Do you expect several further > > netgear devices to be added to nand target? > > > > Up to let's say three/four devices, I'd prefer to merge stuff into > > nand.mk, otherwise I'd say a separate file is justified, so we do get > > a .mk file for every vendor. > > > > Yes, I'm planning to take on WNDR4300v2 (which, as usual, is quite > different from v1 but still QCA-based -> ath79) after this one gets to > mainline. I didn't investigated that router yet (it looks like a SPI > NAND device) but I expect it to require the same image tools. > Anyway, it is your call, I just didn't wanted to put Netgear-specific > stuff into main nand Makefile. I'd still put it in nand.mk, for GL.inet we will end up with four devices there. > > > > > I there a real need to deviate from the sysupgrade.bin/factory.img > > naming scheme here? I didn't find that naming scheme anywhere else in > > ath79 or ramips. > > > > ar71xx replaces 'squashfs' with 'ubi' in factory image name, for ath79 I > couldn't find matching rename function in mk files, so I decided to > append 'ubi' in that very simple way. Again, I do not want to create > mess, I just wanted to preserve information that ar71xx provides. I commented on this with no deeper research, so keep it as it is for now. It's not really important enough to waste time on it, so I don't know whether I will have a second look on that. > > > > > I hesitated when reviewing the DTS section of your patch, but since > > this can be merged with zyxel here, I'd recommend to change the > > partition label to "art", which is frequently used for that very > > reason. > > > > It is for compatibility with vendor naming 'scheme' (which I agree is > inconsistent by itself), there is also 'caldata_backup' partition that > is a copy of 'caldata'. Well, again this is not really important. Knowing about caldata_backup, I'm 50:50 for renaming vs. keeping... Best Adrian openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] ath79/qca9533rev2: Help needed on missing GPIO on ath9k-phy0
Hi, we are still working on broken WiFi on CPE210v2/v3 (ath79, QCA9533 rev. 2) and have found that on ath79 a GPIO is missing compared to ar71xx (where WIFI is working): GPIO Config on the ar71xx: gpiochip0: GPIOs 0-31, parent: platform/ath79-gpio, ath79-gpio: gpio-11 (|tp-link:green:lan0 ) out hi gpio-13 (|tp-link:green:link1 ) out hi gpio-14 (|tp-link:green:link2 ) out hi gpio-15 (|tp-link:green:link3 ) out hi gpio-16 (|tp-link:green:link4 ) out hi gpio-17 (|Reset button) in hi gpiochip1: GPIOs 494-511, ath9k-phy0: gpio-495 (|ath9k-phy0 ) in lo On the ath79: gpio-11 (|tp-link:green:lan ) out lo gpio-13 (|tp-link:green:link1 ) out hi gpio-14 (|tp-link:green:link2 ) out hi gpio-15 (|tp-link:green:link3 ) out hi gpio-16 (|tp-link:green:link4 ) out hi gpio-17 (|Reset button) in hi Can somebody point out how we can introduce the ath9k gpio? Or may this be already the result of something broken at an earlier step? Best Adrian openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] ath79: add support for Netgear WNDR4300
Hello Adrian, Thanks for your feedback! > Hi, > > Same question I asked on zyxel support: Do you expect several further > netgear devices to be added to nand target? > > Up to let's say three/four devices, I'd prefer to merge stuff into > nand.mk, otherwise I'd say a separate file is justified, so we do get > a .mk file for every vendor. > Yes, I'm planning to take on WNDR4300v2 (which, as usual, is quite different from v1 but still QCA-based -> ath79) after this one gets to mainline. I didn't investigated that router yet (it looks like a SPI NAND device) but I expect it to require the same image tools. Anyway, it is your call, I just didn't wanted to put Netgear-specific stuff into main nand Makefile. > > I there a real need to deviate from the sysupgrade.bin/factory.img > naming scheme here? I didn't find that naming scheme anywhere else in > ath79 or ramips. > ar71xx replaces 'squashfs' with 'ubi' in factory image name, for ath79 I couldn't find matching rename function in mk files, so I decided to append 'ubi' in that very simple way. Again, I do not want to create mess, I just wanted to preserve information that ar71xx provides. > > I hesitated when reviewing the DTS section of your patch, but since > this can be merged with zyxel here, I'd recommend to change the > partition label to "art", which is frequently used for that very > reason. > It is for compatibility with vendor naming 'scheme' (which I agree is inconsistent by itself), there is also 'caldata_backup' partition that is a copy of 'caldata'. Cheers Michal ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/3] ipq40xx: mtd m25p80: fix hang on device shutdown
Hi Daniel,
On 30.10.2019 12:27, Daniel Danzberger wrote:
Signed-off-by: Daniel Danzberger
---
.../401-mtd-m25p80-fix-shutdown-hang.patch| 21 +++
1 file changed, 21 insertions(+)
create mode 100644
target/linux/ipq40xx/patches-4.19/401-mtd-m25p80-fix-shutdown-hang.patch
diff --git
a/target/linux/ipq40xx/patches-4.19/401-mtd-m25p80-fix-shutdown-hang.patch
b/target/linux/ipq40xx/patches-4.19/401-mtd-m25p80-fix-shutdown-hang.patch
new file mode 100644
index 00..779f7ec4af
--- /dev/null
+++ b/target/linux/ipq40xx/patches-4.19/401-mtd-m25p80-fix-shutdown-hang.patch
@@ -0,0 +1,21 @@
+diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
+index 270d3c95..39f90436 100644
+--- a/drivers/mtd/devices/m25p80.c
b/drivers/mtd/devices/m25p80.c
+@@ -256,9 +256,16 @@ static int m25p_remove(struct spi_mem *spimem)
+ static void m25p_shutdown(struct spi_mem *spimem)
+ {
+ struct m25p *flash = spi_mem_get_drvdata(spimem);
++ u8 command[1];
++
++ command[0] = 0x66;
++ spi_write(spimem->spi, command, 1);
++ command[0] = 0x99;
++ spi_write(spimem->spi, command, 1);
This is not the correct way to solve 'broken' hardware designs (I assume
your board has incorrect bootstrap configuration and boots from 32M SPI
NOR in default 3-byte addressing mode instead of 4-byte or the flash IC
isn't reset during SOC reset).
I remember discussing this topic at least several times during reviews
of some MediaTek based boards back in 2018, please see great explanation
from Mathias here: [0].
Since kernel 4.19 we have an official 'solution' for that, look for
'broken-flash-reset' property description in [1] documentation and
deeper explanation in [2].
[0] https://github.com/lede-project/source/pull/620#issuecomment-295401936
[1]
https://www.kernel.org/doc/Documentation/devicetree/bindings/mtd/jedec%2Cspi-nor.txt
[2]
https://github.com/torvalds/linux/commit/bb276262e88dae52cc717bb636b7468f66bb234e
--
Cheers,
Piotr
+
+ spi_nor_restore(>spi_nor);
+ }
++
+ /*
+ * Do NOT add to this array without reading the following:
+ *
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] ath79: add support for Netgear WNDR4300
Hi, > diff --git a/target/linux/ath79/image/Makefile > b/target/linux/ath79/image/Makefile > index 24768ef5e0..b6ac83cdc1 100644 > --- a/target/linux/ath79/image/Makefile > +++ b/target/linux/ath79/image/Makefile > @@ -77,6 +77,7 @@ include ./generic-ubnt.mk > endif > ifeq ($(SUBTARGET),nand) > include ./nand.mk > +include ./nand-netgear.mk Same question I asked on zyxel support: Do you expect several further netgear devices to be added to nand target? Up to let's say three/four devices, I'd prefer to merge stuff into nand.mk, otherwise I'd say a separate file is justified, so we do get a .mk file for every vendor. > diff --git a/target/linux/ath79/image/nand-netgear.mk > b/target/linux/ath79/image/nand-netgear.mk > new file mode 100644 > index 00..b25e6ec66c > --- /dev/null > +++ b/target/linux/ath79/image/nand-netgear.mk > @@ -0,0 +1,34 @@ > +include ./common-netgear.mk # for netgear-uImage > + > +# (pad-offset 129 = 2 * uimage_header + 0xff) > +define Device/netgear_ath79_nand > + DEVICE_VENDOR := NETGEAR > + DEVICE_PACKAGES := kmod-usb2 kmod-usb-ledtrig-usbport > + KERNEL_SIZE := 2048k > + BLOCKSIZE := 128k > + PAGESIZE := 2048 > + IMAGE_SIZE := 25600k > + KERNEL := kernel-bin | append-dtb | lzma -d20 | \ > + pad-offset $$(KERNEL_SIZE) 129 | \ > + netgear-uImage lzma | append-string -e '\xff' | \ > + append-uImage-fakehdr filesystem $$(NETGEAR_KERNEL_MAGIC) > + KERNEL_INITRAMFS := kernel-bin | append-dtb | lzma -d20 | \ > + netgear-uImage lzma > + IMAGES := ubi-sysupgrade.bin ubi-factory.img > + IMAGE/ubi-factory.img := append-kernel | append-ubi | netgear-dni | \ > + check-size (IMAGE_SIZE) > + IMAGE/ubi-sysupgrade.bin := sysupgrade-tar | append-metadata | \ > + check-size (IMAGE_SIZE) I there a real need to deviate from the sysupgrade.bin/factory.img naming scheme here? I didn't find that naming scheme anywhere else in ath79 or ramips. > diff --git > a/target/linux/ath79/nand/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom > b/target/linux/ath79/nand/base- > files/etc/hotplug.d/firmware/10-ath9k-eeprom > index 88a40b5d41..ae1d3572a8 100644 > --- > a/target/linux/ath79/nand/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom > +++ > b/target/linux/ath79/nand/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom > @@ -9,6 +9,9 @@ board=$(board_name) > case "$FIRMWARE" in > "ath9k-eeprom-ahb-1810.wmac.bin") > case $board in > + netgear,wndr4300) > + caldata_extract "caldata" 0x1000 0x440 > + ;; I hesitated when reviewing the DTS section of your patch, but since this can be merged with zyxel here, I'd recommend to change the partition label to "art", which is frequently used for that very reason. Best Adrian openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/3] ipq40xx: ipq4019: Add new device Compex WPJ419
Hi,
just some cosmetical drive-by comments below:
...
> diff --git
> a/target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> b/target/linux/ipq40xx/base-
> files/etc/hotplug.d/firmware/11-ath10k-caldata
> index 2336ef3c7b..b18d17e422 100644
> --- a/target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> +++ b/target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> @@ -71,6 +71,7 @@ case "$FIRMWARE" in
> /usr/bin/fritz_cal_extract -i 1 -s 0x3D000 -e 0x207 -l 12064 -o
> /lib/firmware/$FIRMWARE $(find_mtd_chardev
> "urlader1")
> ;;
> compex,wpj428 |\
> + compex,wpj419 |\
Please apply correct alphabetic sorting.
> engenius,eap1300 |\
> openmesh,a42 |\
> openmesh,a62 |\
> @@ -134,6 +135,7 @@ case "$FIRMWARE" in
> /usr/bin/fritz_cal_extract -i 1 -s 0x3C000 -e 0x208 -l 12064 -o
> /lib/firmware/$FIRMWARE $(find_mtd_chardev
> "urlader1")
> ;;
> compex,wpj428 |\
> + compex,wpj419 |\
Please apply correct alphabetic sorting.
> engenius,eap1300 |\
> openmesh,a42 |\
> openmesh,a62 |\
> diff --git a/target/linux/ipq40xx/config-4.19
> b/target/linux/ipq40xx/config-4.19
> index 8948b73ff7..3ee921abed 100644
> --- a/target/linux/ipq40xx/config-4.19
> +++ b/target/linux/ipq40xx/config-4.19
> @@ -303,6 +303,9 @@ CONFIG_MTD_NAND_ECC=y
> CONFIG_MTD_NAND_QCOM=y
> CONFIG_MTD_SPI_NAND=y
> CONFIG_MTD_SPI_NOR=y
> +CONFIG_MTD_SPINAND_MT29F=y
> +CONFIG_MTD_SPINAND_GIGADEVICE=y
> +CONFIG_MTD_SPINAND_ONDIEECC=y
> CONFIG_MTD_SPLIT_FIRMWARE=y
> CONFIG_MTD_SPLIT_FIT_FW=y
> CONFIG_MTD_UBI=y
> diff --git
> a/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-bus.dtsi
> b/target/linux/ipq40xx/files-
> 4.19/arch/arm/boot/dts/qcom-ipq4019-bus.dtsi
> new file mode 100644
> index 00..169505973f
> --- /dev/null
> +++ b/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-bus.dtsi
> @@ -0,0 +1,1142 @@
> +/* Copyright (c) 2015, The Linux Foundation. All rights reserved.
> + *
> + * Permission to use, copy, modify, and/or distribute this software for any
> + * purpose with or without fee is hereby granted, provided that the above
> + * copyright notice and this permission notice appear in all copies.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> + *
> + */
> +
> +#include
> +
> +/ {
> +
> +soc {
Child nodes (=soc) should be indented.
> + ad_hoc_bus: ad-hoc-bus {
> + compatible = "qcom,msm-bus-device";
...
> diff --git
> a/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-wpj419.dts
> b/target/linux/ipq40xx/files-
> 4.19/arch/arm/boot/dts/qcom-ipq4019-wpj419.dts
> new file mode 100644
> index 00..5553bbd166
> --- /dev/null
> +++
> b/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-wpj419.dts
> @@ -0,0 +1,371 @@
...
> + {
> +qcom,phy_mdio_addr = <4>;
> +qcom,poll_required = <1>;
> +qcom,forced_speed = <1000>;
> +qcom,forced_duplex = <1>;
> +vlan_tag = <2 0x20>;
> +};
> +
> + {
> +qcom,phy_mdio_addr = <3>;
> +qcom,poll_required = <1>;
> +qcom,forced_speed = <1000>;
> +qcom,forced_duplex = <1>;
> +vlan_tag = <1 0x10>;
> +};
> +
> + {
> +status = "okay";
> +};
> +
> + {
> +status = "okay";
> +};
Fix indent for the content of the four nodes above.
> diff --git
> a/target/linux/ipq40xx/files-4.19/include/dt-bindings/msm/msm-bus-ids.h
> b/target/linux/ipq40xx/files-4.19/include/dt-
> bindings/msm/msm-bus-ids.h
> new file mode 100644
> index 00..da0b83e831
> --- /dev/null
> +++ b/target/linux/ipq40xx/files-4.19/include/dt-bindings/msm/msm-bus-ids.h
...
> +#define MSM_BUS_SLAVE_CATS_128 663
> +#define MSM_BUS_SLAVE_OCMEM_64 664
> +#define MSM_BUS_SLAVE_PCIE_0 665
> +#define MSM_BUS_SLAVE_PCIE_1 666
Mixed indent here ...
...
> +#define MSM_BUS_SLAVE_SRVC_SNOC 754
> +
> +#define MSM_BUS_SYSTEM_FPB_SLAVE_SYSTEM MSM_BUS_SYSTEM_SLAVE_SYSTEM_FPB
> +#define MSM_BUS_CPSS_FPB_SLAVE_SYSTEM MSM_BUS_SYSTEM_SLAVE_CPSS_FPB
and here.
...
> diff --git a/target/linux/ipq40xx/image/Makefile
> b/target/linux/ipq40xx/image/Makefile
> index ed46bca649..a13a17b3cf 100644
> --- a/target/linux/ipq40xx/image/Makefile
> +++ b/target/linux/ipq40xx/image/Makefile
> @@ -179,6 +179,20 @@ define Device/compex_wpj428
> endef
> TARGET_DEVICES += compex_wpj428
>
> +define Device/compex_wpj419
> + $(call Device/FitImage)
> + $(call Device/UbiFit)
> + DEVICE_VENDOR := Compex
> +
[OpenWrt-Devel] [PATCH v2] ath79: add support for Netgear WNR2200
This patch adds ath79 support for Netgear WNR2200.
Router was previously supported by ar71xx target only (8 MiB variant).
Netgear WNR2200 has two flash versions - 8MiB sold in EU, US etc. and
16 MiB for Russia and China markets. Apart from flash size both variants
share the same hardware specification.
Specification
=
* Description: Netgear WNR2200
* Loader: U-boot
* SOC: Atheros AR7241 (360 MHz)
* RAM: 64 MiB
* Flash: 8 MiB or 16 MiB (SPI NOR)
- U-boot binary: 256 KiB
- U-boot environment: 64 KiB
- Firmware: 7808 KiB or 16000 KiB
- ART: 64 KiB
* Ethernet: 4 x 10/100 LAN + 1 x 10/100 WAN
* Wireless: 2.4 GHz b/g/n (Atheros AR9287)
* USB: yes, 1 x USB 2.0
* Buttons:
- Reset
- WiFi (rfkill)
- WPS
* LEDs:
- Power (amber/green)
- WAN (amber/green)
- WLAN (blue)
- 4 x LAN (amber/green)
- WPS (green)
* UART: 4-pin connector JP1, 3.3V (Vcc, TX, RX, GND), 115200 8N1
* Power supply: DC 12V 1.5A
* MAC addresses: LAN on case label, WAN +1, WLAN +2
Installation
* TFTP recovery
* TFTP via U-boot prompt
* sysupgrade
* Web interface
Test build configuration
CONFIG_TARGET_ath79=y
CONFIG_TARGET_ath79_generic=y
CONFIG_TARGET_ath79_generic_DEVICE_netgear_wnr2200-8m=y
CONFIG_ALL_KMODS=y
CONFIG_DEVEL=y
CONFIG_CCACHE=y
CONFIG_COLLECT_KERNEL_DEBUG=y
CONFIG_IMAGEOPT=y
CONFIG_KERNEL_DEBUG_INFO=y
CONFIG_KERNEL_DEBUG_KERNEL=y
Signed-off-by: Michal Cieslakiewicz
---
package/boot/uboot-envtools/files/ath79 | 2 +
.../ath79/dts/ar7241_netgear_wnr2200-16m.dts | 34 +++
.../ath79/dts/ar7241_netgear_wnr2200-8m.dts | 34 +++
.../ath79/dts/ar7241_netgear_wnr2200.dtsi | 207 ++
.../generic/base-files/etc/board.d/01_leds| 12 +
.../generic/base-files/etc/board.d/02_network | 6 +
.../etc/hotplug.d/firmware/10-ath9k-eeprom| 2 +
target/linux/ath79/image/generic.mk | 34 +++
8 files changed, 331 insertions(+)
create mode 100644 target/linux/ath79/dts/ar7241_netgear_wnr2200-16m.dts
create mode 100644 target/linux/ath79/dts/ar7241_netgear_wnr2200-8m.dts
create mode 100644 target/linux/ath79/dts/ar7241_netgear_wnr2200.dtsi
diff --git a/package/boot/uboot-envtools/files/ath79
b/package/boot/uboot-envtools/files/ath79
index d5b94823fd..cc9741cedf 100644
--- a/package/boot/uboot-envtools/files/ath79
+++ b/package/boot/uboot-envtools/files/ath79
@@ -22,6 +22,8 @@ glinet,gl-ar300m-nor|\
librerouter,librerouter-v1|\
netgear,ex6400|\
netgear,ex7300|\
+netgear,wnr2200-8m|\
+netgear,wnr2200-16m|\
ocedo,koala|\
ocedo,raccoon|\
openmesh,om5p-ac-v2|\
diff --git a/target/linux/ath79/dts/ar7241_netgear_wnr2200-16m.dts
b/target/linux/ath79/dts/ar7241_netgear_wnr2200-16m.dts
new file mode 100644
index 00..d182b58c05
--- /dev/null
+++ b/target/linux/ath79/dts/ar7241_netgear_wnr2200-16m.dts
@@ -0,0 +1,34 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "ar7241_netgear_wnr2200.dtsi"
+
+/ {
+ compatible = "netgear,wnr2200-16m", "qca,ar7241";
+ model = "Netgear WNR2200 (16M)";
+};
+
+ {
+ partition@0 {
+ label = "u-boot";
+ reg = <0x0 0x4>;
+ read-only;
+ };
+
+ partition@4 {
+ label = "u-boot-env";
+ reg = <0x4 0x1>;
+ };
+
+ partition@5 {
+ label = "firmware";
+ reg = <0x5 0xfa>;
+ compatible = "netgear,uimage";
+ };
+
+ art: partition@ff {
+ label = "art";
+ reg = <0xff 0x1>;
+ read-only;
+ };
+};
diff --git a/target/linux/ath79/dts/ar7241_netgear_wnr2200-8m.dts
b/target/linux/ath79/dts/ar7241_netgear_wnr2200-8m.dts
new file mode 100644
index 00..e926c17893
--- /dev/null
+++ b/target/linux/ath79/dts/ar7241_netgear_wnr2200-8m.dts
@@ -0,0 +1,34 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "ar7241_netgear_wnr2200.dtsi"
+
+/ {
+ compatible = "netgear,wnr2200-8m", "qca,ar7241";
+ model = "Netgear WNR2200 (8M)";
+};
+
+ {
+ partition@0 {
+ label = "u-boot";
+ reg = <0x0 0x4>;
+ read-only;
+ };
+
+ partition@4 {
+ label = "u-boot-env";
+ reg = <0x4 0x1>;
+ };
+
+ partition@5 {
+ label = "firmware";
+ reg = <0x5 0x7a>;
+ compatible = "netgear,uimage";
+ };
+
+ art: partition@7f {
+ label = "art";
+ reg = <0x7f 0x1>;
+ read-only;
+ };
+};
diff --git a/target/linux/ath79/dts/ar7241_netgear_wnr2200.dtsi
b/target/linux/ath79/dts/ar7241_netgear_wnr2200.dtsi
new file mode 100644
index 00..1ce4d11835
--- /dev/null
+++
[OpenWrt-Devel] [PATCH v2] ath79: add support for Netgear WNDR4300
This patch adds ath79 support for Netgear WNDR4300.
Router was previously supported by ar71xx target only.
Note: device requires 'ar934x-nand' driver in kernel.
Specification
=
* Description: Netgear WNDR4300
* Loader: U-boot
* SOC: Atheros AR9344 (560 MHz)
* RAM: 128 MiB
* Flash: 128 MiB (NAND)
- U-boot binary: 256 KiB
- U-boot environment: 256 KiB
- ART: 256 KiB
- POT: 512 KiB
- Language: 2 MiB
- Config: 512 KiB
- Traffic Meter: 3 MiB
- Firmware: 25 MiB
- ART Backup: 256 KiB
- Reserved: 96 MiB
* Ethernet: 5 x 10/100/1000 (4 x LAN, 1 x WAN) (AR8327)
* Wireless:
- 2.4 GHz b/g/n (internal)
- 5 GHz a/n (AR9580)
* USB: yes, 1 x USB 2.0
* Buttons:
- Reset
- WiFi (rfkill)
- WPS
* LEDs:
- Power (amber/green)
- WAN (amber/green)
- WLAN 2G (green)
- WLAN 5G (blue)
- 4 x LAN (amber/green)
- USB (green)
- WPS (amber/green)
* UART: 4-pin connector JP1, 3.3V (Vcc, TX, RX, GND), 115200 8N1
* Power supply: DC 12V 2.5A
* MAC addresses: LAN=WLAN2G on case label, WAN +1, WLAN5G +2
Installation
* TFTP recovery
* TFTP via U-boot prompt
* sysupgrade
* Web interface
Note about partitioning: firmware partition offset (0x6c) is
hardcoded into vendor's u-boot, so this partition cannot be moved
and resized to include Netgear-specific flash areas (pot, language,
config, traffic_meter) not used by OpenWrt.
Test build configuration
CONFIG_TARGET_ath79=y
CONFIG_TARGET_ath79_nand=y
CONFIG_TARGET_ath79_nand_DEVICE_netgear_wndr4300=y
CONFIG_ALL_KMODS=y
CONFIG_DEVEL=y
CONFIG_CCACHE=y
CONFIG_COLLECT_KERNEL_DEBUG=y
CONFIG_IMAGEOPT=y
Signed-off-by: Michal Cieslakiewicz
---
package/boot/uboot-envtools/files/ath79 | 3 +
.../ath79/dts/ar9344_netgear_wndr4300.dts | 293 ++
target/linux/ath79/image/Makefile | 1 +
target/linux/ath79/image/nand-netgear.mk | 34 ++
.../ath79/nand/base-files/etc/board.d/01_leds | 3 +
.../nand/base-files/etc/board.d/02_network| 7 +
.../etc/hotplug.d/firmware/10-ath9k-eeprom| 13 +
.../nand/base-files/lib/upgrade/platform.sh | 1 +
8 files changed, 355 insertions(+)
create mode 100644 target/linux/ath79/dts/ar9344_netgear_wndr4300.dts
create mode 100644 target/linux/ath79/image/nand-netgear.mk
diff --git a/package/boot/uboot-envtools/files/ath79
b/package/boot/uboot-envtools/files/ath79
index cc9741cedf..5da5df2420 100644
--- a/package/boot/uboot-envtools/files/ath79
+++ b/package/boot/uboot-envtools/files/ath79
@@ -33,6 +33,9 @@ yuncore,a770)
buffalo,wzr-hp-ag300h)
ubootenv_add_uci_config "/dev/mtd3" "0x0" "0x1" "0x1"
;;
+netgear,wndr4300)
+ ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x4" "0x2"
+ ;;
qihoo,c301)
ubootenv_add_uci_config "/dev/mtd9" "0x0" "0x1" "0x1"
;;
diff --git a/target/linux/ath79/dts/ar9344_netgear_wndr4300.dts
b/target/linux/ath79/dts/ar9344_netgear_wndr4300.dts
new file mode 100644
index 00..c2c395e8cf
--- /dev/null
+++ b/target/linux/ath79/dts/ar9344_netgear_wndr4300.dts
@@ -0,0 +1,293 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include
+#include
+
+#include "ar9344.dtsi"
+
+/ {
+ compatible = "netgear,wndr4300", "qca,ar9344";
+ model = "Netgear WNDR4300";
+
+ chosen {
+ bootargs = "console=ttyS0,115200n8";
+ };
+
+ aliases {
+ led-boot = _amber;
+ led-failsafe = _amber;
+ led-running = _green;
+ led-upgrade = _amber;
+ label-mac-device =
+ };
+
+ keys {
+ compatible = "gpio-keys";
+
+ wps {
+ label = "wps";
+ linux,code = ;
+ gpios = < 12 GPIO_ACTIVE_LOW>;
+ };
+
+ reset {
+ label = "reset";
+ linux,code = ;
+ gpios = < 21 GPIO_ACTIVE_LOW>;
+ };
+
+ rfkill {
+ label = "rfkill";
+ linux,code = ;
+ gpios = < 15 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_gpio_11>;
+
+ power_green: power_green {
+ label = "netgear:green:power";
+ gpios = < 0 GPIO_ACTIVE_LOW>;
+ };
+
+ power_amber: power_amber {
+ label = "netgear:amber:power";
+ gpios = < 2 GPIO_ACTIVE_LOW>;
+ default-state = "keep";
+ };
+
+ wan_green {
+ label =
Re: [OpenWrt-Devel] [PATCH v2] ath79: add support for Netgear WNR2200
Hello, This patch supersedes previous version (also listed on patchwork: https://patchwork.ozlabs.org/patch/1181348/) and implements following changes: * scripts have been rebased to apply after base-files split * router added to uboot-envtools * device name in image header changed to lowercase to match Netgear file, now it can be accepted and flashed using vendor's firmware web interface; flashing via uboot/recovery/sysupgrade is not affected Best regards Michal ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] ath79: add support for Netgear WNDR4300
Hello, This patch supersedes WNR4300 patchset: https://patchwork.ozlabs.org/patch/1175066/ (obsolete - removed) https://patchwork.ozlabs.org/patch/1175069/ (updated to v2) It contains changes proposed by Adrian (remove redundant lan_mac setting from 02_network; change MAC label to eth0 in DTS) as well as following changes: * scripts have been rebased to apply after base-files split * dts: add internal port #6 setup in ar8327 initvals (as uboot does) so it no longer shows 10mbps half duplex in swconfig (it does not affect 5 external ports) * 10-ath9k-eeprom: ath9k_eeprom_extract changed to caldata_extract * 10-ath9k-eeprom: extract 0x440 instead of 0x800 bytes from caldata * router added to uboot-envtools nand/config-default has been removed from patch, now device bases on default kernel config for NAND because it already provides required functionality. Sysupgrade also have been fixed since old patchset and it works now. Best regards Michal ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/3] ipq40xx: Add gigadevice nandspi flash driver
On Wed, 30 Oct 2019 at 12:28, Daniel Danzberger wrote:
>
> This patch adds support for Gigadevice SPI NAND device to the mt29f stagging
> driver.
Which model of SPI NAND does this board use?
MT29F was removed in 4.21 and should not be used as upstream SPI-NAND
framework replaced it in vendor agnostic way.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/staging?h=v5.4-rc5=647ad49ca672b80a3fbf8396bd453ef68ba4916c
OpenWrt has backported support for all SPI-NAND drivers from 5.2
kernel, so please use SPI-NAND instead.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/mtd/nand/spi?h=v5.4-rc5
>
> Signed-off-by: Daniel Danzberger
> ---
> ...port-gigadevice-nandspi-flash-device.patch | 1778 +
> 1 file changed, 1778 insertions(+)
> create mode 100644
> target/linux/ipq40xx/patches-4.19/400-mtd-nand-support-gigadevice-nandspi-flash-device.patch
>
> diff --git
> a/target/linux/ipq40xx/patches-4.19/400-mtd-nand-support-gigadevice-nandspi-flash-device.patch
>
> b/target/linux/ipq40xx/patches-4.19/400-mtd-nand-support-gigadevice-nandspi-flash-device.patch
> new file mode 100644
> index 00..a3b98cd275
> --- /dev/null
> +++
> b/target/linux/ipq40xx/patches-4.19/400-mtd-nand-support-gigadevice-nandspi-flash-device.patch
> @@ -0,0 +1,1778 @@
> +diff --git a/drivers/mtd/nand/raw/nand_ids.c
> b/drivers/mtd/nand/raw/nand_ids.c
> +index 5423c3bb..31aac787 100644
> +--- a/drivers/mtd/nand/raw/nand_ids.c
> b/drivers/mtd/nand/raw/nand_ids.c
> +@@ -185,6 +185,7 @@ static const struct nand_manufacturer
> nand_manufacturers[] = {
> + {NAND_MFR_INTEL, "Intel"},
> + {NAND_MFR_ATO, "ATO"},
> + {NAND_MFR_WINBOND, "Winbond"},
> ++ {NAND_MFR_GIGA, "Gigadevice"},
> + };
> +
> + /**
> +diff --git a/drivers/staging/mt29f_spinand/Kconfig
> b/drivers/staging/mt29f_spinand/Kconfig
> +index f3f9cb3b..139c058c 100644
> +--- a/drivers/staging/mt29f_spinand/Kconfig
> b/drivers/staging/mt29f_spinand/Kconfig
> +@@ -14,3 +14,13 @@ config MTD_SPINAND_ONDIEECC
> + help
> + Internal ECC.
> + Enables Hardware ECC support for Micron SPI NAND.
> ++
> ++config MTD_SPINAND_GIGADEVICE
> ++ tristate "SPINAND Devcie Support for Gigadevice "
> ++ depends on MTD_SPINAND_MT29F
> ++ help
> ++ This enables support for accessing Gigadevice SPI NAND flash
> ++ devices.
> ++ If you have Gigadevice SPI NAND chip say yes.
> ++
> ++ If unsure, say no here.
> +diff --git a/drivers/staging/mt29f_spinand/Makefile
> b/drivers/staging/mt29f_spinand/Makefile
> +index e47af0f7..36df11e6 100644
> +--- a/drivers/staging/mt29f_spinand/Makefile
> b/drivers/staging/mt29f_spinand/Makefile
> +@@ -1 +1,2 @@
> + obj-$(CONFIG_MTD_SPINAND_MT29F) += mt29f_spinand.o
> ++obj-$(CONFIG_MTD_SPINAND_GIGADEVICE) += giga_spinand.o
> +diff --git a/drivers/staging/mt29f_spinand/giga_spinand.c
> b/drivers/staging/mt29f_spinand/giga_spinand.c
> +new file mode 100644
> +index ..a619e96d
> +--- /dev/null
> b/drivers/staging/mt29f_spinand/giga_spinand.c
> +@@ -0,0 +1,396 @@
> ++/* Copyright (c) 2015, The Linux Foundation. All rights reserved.
> ++ *
> ++ * Permission to use, copy, modify, and/or distribute this software for any
> ++ * purpose with or without fee is hereby granted, provided that the above
> ++ * copyright notice and this permission notice appear in all copies.
> ++ *
> ++ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> ++ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> ++ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> ++ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> ++ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> ++ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> ++ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> ++ *
> ++ */
> ++
> ++#include
> ++#include
> ++#include
> ++#include
> ++#include
> ++#include "giga_spinand.h"
> ++
> ++/* Only ecc un-protected fields in the spare area included */
> ++static int winbond_ooblayout_64_ecc(struct mtd_info *mtd, int section,
> ++struct mtd_oob_region *oobregion) {
> ++ if (section > 3)
> ++return -ERANGE;
> ++
> ++ oobregion->offset = (section * 16) + 8;
> ++ oobregion->length = 9;
> ++ return 0;
> ++}
> ++
> ++static int winbond_ooblayout_64_free(struct mtd_info *mtd, int section,
> ++ struct mtd_oob_region *oobregion) {
> ++ if (section > 3)
> ++return -ERANGE;
> ++
> ++ oobregion->offset = (section * 16) + 2;
> ++ oobregion->length = 2;
> ++ return 0;
> ++}
> ++
> ++static const struct mtd_ooblayout_ops winbond_ooblayout = {
> ++ .ecc = winbond_ooblayout_64_ecc,
> ++ .free = winbond_ooblayout_64_free,
> ++};
> ++
> ++static int ath79_ooblayout_64_ecc(struct mtd_info *mtd, int section,
> ++
[OpenWrt-Devel] [PATCH 1/3] ipq40xx: Add gigadevice nandspi flash driver
This patch adds support for Gigadevice SPI NAND device to the mt29f stagging
driver.
Signed-off-by: Daniel Danzberger
---
...port-gigadevice-nandspi-flash-device.patch | 1778 +
1 file changed, 1778 insertions(+)
create mode 100644
target/linux/ipq40xx/patches-4.19/400-mtd-nand-support-gigadevice-nandspi-flash-device.patch
diff --git
a/target/linux/ipq40xx/patches-4.19/400-mtd-nand-support-gigadevice-nandspi-flash-device.patch
b/target/linux/ipq40xx/patches-4.19/400-mtd-nand-support-gigadevice-nandspi-flash-device.patch
new file mode 100644
index 00..a3b98cd275
--- /dev/null
+++
b/target/linux/ipq40xx/patches-4.19/400-mtd-nand-support-gigadevice-nandspi-flash-device.patch
@@ -0,0 +1,1778 @@
+diff --git a/drivers/mtd/nand/raw/nand_ids.c b/drivers/mtd/nand/raw/nand_ids.c
+index 5423c3bb..31aac787 100644
+--- a/drivers/mtd/nand/raw/nand_ids.c
b/drivers/mtd/nand/raw/nand_ids.c
+@@ -185,6 +185,7 @@ static const struct nand_manufacturer nand_manufacturers[]
= {
+ {NAND_MFR_INTEL, "Intel"},
+ {NAND_MFR_ATO, "ATO"},
+ {NAND_MFR_WINBOND, "Winbond"},
++ {NAND_MFR_GIGA, "Gigadevice"},
+ };
+
+ /**
+diff --git a/drivers/staging/mt29f_spinand/Kconfig
b/drivers/staging/mt29f_spinand/Kconfig
+index f3f9cb3b..139c058c 100644
+--- a/drivers/staging/mt29f_spinand/Kconfig
b/drivers/staging/mt29f_spinand/Kconfig
+@@ -14,3 +14,13 @@ config MTD_SPINAND_ONDIEECC
+ help
+ Internal ECC.
+ Enables Hardware ECC support for Micron SPI NAND.
++
++config MTD_SPINAND_GIGADEVICE
++ tristate "SPINAND Devcie Support for Gigadevice "
++ depends on MTD_SPINAND_MT29F
++ help
++ This enables support for accessing Gigadevice SPI NAND flash
++ devices.
++ If you have Gigadevice SPI NAND chip say yes.
++
++ If unsure, say no here.
+diff --git a/drivers/staging/mt29f_spinand/Makefile
b/drivers/staging/mt29f_spinand/Makefile
+index e47af0f7..36df11e6 100644
+--- a/drivers/staging/mt29f_spinand/Makefile
b/drivers/staging/mt29f_spinand/Makefile
+@@ -1 +1,2 @@
+ obj-$(CONFIG_MTD_SPINAND_MT29F) += mt29f_spinand.o
++obj-$(CONFIG_MTD_SPINAND_GIGADEVICE) += giga_spinand.o
+diff --git a/drivers/staging/mt29f_spinand/giga_spinand.c
b/drivers/staging/mt29f_spinand/giga_spinand.c
+new file mode 100644
+index ..a619e96d
+--- /dev/null
b/drivers/staging/mt29f_spinand/giga_spinand.c
+@@ -0,0 +1,396 @@
++/* Copyright (c) 2015, The Linux Foundation. All rights reserved.
++ *
++ * Permission to use, copy, modify, and/or distribute this software for any
++ * purpose with or without fee is hereby granted, provided that the above
++ * copyright notice and this permission notice appear in all copies.
++ *
++ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
++ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
++ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
++ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
++ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
++ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
++ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
++ *
++ */
++
++#include
++#include
++#include
++#include
++#include
++#include "giga_spinand.h"
++
++/* Only ecc un-protected fields in the spare area included */
++static int winbond_ooblayout_64_ecc(struct mtd_info *mtd, int section,
++struct mtd_oob_region *oobregion) {
++ if (section > 3)
++return -ERANGE;
++
++ oobregion->offset = (section * 16) + 8;
++ oobregion->length = 9;
++ return 0;
++}
++
++static int winbond_ooblayout_64_free(struct mtd_info *mtd, int section,
++ struct mtd_oob_region *oobregion) {
++ if (section > 3)
++return -ERANGE;
++
++ oobregion->offset = (section * 16) + 2;
++ oobregion->length = 2;
++ return 0;
++}
++
++static const struct mtd_ooblayout_ops winbond_ooblayout = {
++ .ecc = winbond_ooblayout_64_ecc,
++ .free = winbond_ooblayout_64_free,
++};
++
++static int ath79_ooblayout_64_ecc(struct mtd_info *mtd, int section,
++struct mtd_oob_region *oobregion) {
++ if (section > 7)
++return -ERANGE;
++ switch(section) {
++case 0:
++ oobregion->offset = 64;
++ oobregion->length = 8;
++ break;
++case 1:
++ oobregion->offset = 72;
++ oobregion->length = 8;
++ break;
++case 2:
++ oobregion->offset = 80;
++ oobregion->length = 8;
++ break;
++case 3:
++ oobregion->offset = 88;
++ oobregion->length = 8;
++ break;
++case 4:
++ oobregion->offset = 96;
++ oobregion->length = 8;
++ break;
++case 5:
++ oobregion->offset = 104;
++ oobregion->length = 8;
++ break;
++case 6:
++ oobregion->offset = 112;
++ oobregion->length = 8;
++ break;
++case 7:
++ oobregion->offset =
[OpenWrt-Devel] [PATCH 0/3] ipq40xx: Add new device Compex WPJ419
These 3 patches add support for the Compex WPJ419 board. Patch 1 adds the nandspi driver for the Gigadevice flash used on the wpj419. Patch 2 fixes a reboot/shutdown hang. Patch 3 Adds the actual wpj419 device support. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/3] ipq40xx: mtd m25p80: fix hang on device shutdown
Signed-off-by: Daniel Danzberger
---
.../401-mtd-m25p80-fix-shutdown-hang.patch| 21 +++
1 file changed, 21 insertions(+)
create mode 100644
target/linux/ipq40xx/patches-4.19/401-mtd-m25p80-fix-shutdown-hang.patch
diff --git
a/target/linux/ipq40xx/patches-4.19/401-mtd-m25p80-fix-shutdown-hang.patch
b/target/linux/ipq40xx/patches-4.19/401-mtd-m25p80-fix-shutdown-hang.patch
new file mode 100644
index 00..779f7ec4af
--- /dev/null
+++ b/target/linux/ipq40xx/patches-4.19/401-mtd-m25p80-fix-shutdown-hang.patch
@@ -0,0 +1,21 @@
+diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
+index 270d3c95..39f90436 100644
+--- a/drivers/mtd/devices/m25p80.c
b/drivers/mtd/devices/m25p80.c
+@@ -256,9 +256,16 @@ static int m25p_remove(struct spi_mem *spimem)
+ static void m25p_shutdown(struct spi_mem *spimem)
+ {
+ struct m25p *flash = spi_mem_get_drvdata(spimem);
++ u8 command[1];
++
++ command[0] = 0x66;
++ spi_write(spimem->spi, command, 1);
++ command[0] = 0x99;
++ spi_write(spimem->spi, command, 1);
+
+ spi_nor_restore(>spi_nor);
+ }
++
+ /*
+ * Do NOT add to this array without reading the following:
+ *
--
2.23.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 3/3] ipq40xx: ipq4019: Add new device Compex WPJ419
This device contains 2 flash devices. One NOR (32M) and one NAND (128M).
U-boot and caldata are on the NOR, the firmware on the NAND.
SoC:IPQ4019
CPU:4x 710MHz ARMv7
RAM:256MB
FLASH: NOR:32MB NAND:128MB
ETH:2x GMAC Gigabit
POE:802.3 af/at POE, IEEE802.3af/IEEE802.3at(48-56V)
WIFI: 1x 2.4Ghz Atheros qca4019 2x2 MU-MIMO
1x 5.0Ghz Atheros qca4019 2x2 MU-MIMO
USB:1x 3.0
PCI:1x Mini PCIe
SIM:1x Slot
SD: 1x MicroSD slot
BTN:Reset
LED:- Power
- Ethernet
UART: 1x Serial Port 4 Pin Connector (UART)
1x Serial Port 6 Pin Connector (High Speed UART)
POWER: 12V 2A
Installation
Initial flashing can only be done via u-boot using the following commands:
tftpboot openwrt-ipq40xx-generic-compex_wpj419-nand-squashfs-nand-factory.ubi
nand erase.chip; nand write ${fileaddr} 0x0 ${filesize}
set fsbootargs ubi.mtd=rootfs root=/dev/ubiblock0_1 rootfstype=squashfs
saveenv
res
Signed-off-by: Daniel Danzberger
---
.../ipq40xx/base-files/etc/board.d/02_network |1 +
.../etc/hotplug.d/firmware/11-ath10k-caldata |2 +
target/linux/ipq40xx/config-4.19 |3 +
.../arch/arm/boot/dts/qcom-ipq4019-bus.dtsi | 1142 +
.../arch/arm/boot/dts/qcom-ipq4019-wpj419.dts | 371 ++
.../include/dt-bindings/msm/msm-bus-ids.h | 869 +
target/linux/ipq40xx/image/Makefile | 14 +
.../901-arm-boot-add-dts-files.patch |3 +-
8 files changed, 2404 insertions(+), 1 deletion(-)
create mode 100644
target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-bus.dtsi
create mode 100644
target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-wpj419.dts
create mode 100644
target/linux/ipq40xx/files-4.19/include/dt-bindings/msm/msm-bus-ids.h
diff --git a/target/linux/ipq40xx/base-files/etc/board.d/02_network
b/target/linux/ipq40xx/base-files/etc/board.d/02_network
index 25402b7eb4..dafd83234e 100755
--- a/target/linux/ipq40xx/base-files/etc/board.d/02_network
+++ b/target/linux/ipq40xx/base-files/etc/board.d/02_network
@@ -48,6 +48,7 @@ ipq40xx_setup_interfaces()
ucidef_set_interface_lan "eth0"
;;
avm,fritzrepeater-3000|\
+ compex,wpj419|\
compex,wpj428)
ucidef_set_interface_lan "eth0 eth1"
;;
diff --git
a/target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
b/target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index 2336ef3c7b..b18d17e422 100644
--- a/target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++ b/target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -71,6 +71,7 @@ case "$FIRMWARE" in
/usr/bin/fritz_cal_extract -i 1 -s 0x3D000 -e 0x207 -l 12064 -o
/lib/firmware/$FIRMWARE $(find_mtd_chardev "urlader1")
;;
compex,wpj428 |\
+ compex,wpj419 |\
engenius,eap1300 |\
openmesh,a42 |\
openmesh,a62 |\
@@ -134,6 +135,7 @@ case "$FIRMWARE" in
/usr/bin/fritz_cal_extract -i 1 -s 0x3C000 -e 0x208 -l 12064 -o
/lib/firmware/$FIRMWARE $(find_mtd_chardev "urlader1")
;;
compex,wpj428 |\
+ compex,wpj419 |\
engenius,eap1300 |\
openmesh,a42 |\
openmesh,a62 |\
diff --git a/target/linux/ipq40xx/config-4.19 b/target/linux/ipq40xx/config-4.19
index 8948b73ff7..3ee921abed 100644
--- a/target/linux/ipq40xx/config-4.19
+++ b/target/linux/ipq40xx/config-4.19
@@ -303,6 +303,9 @@ CONFIG_MTD_NAND_ECC=y
CONFIG_MTD_NAND_QCOM=y
CONFIG_MTD_SPI_NAND=y
CONFIG_MTD_SPI_NOR=y
+CONFIG_MTD_SPINAND_MT29F=y
+CONFIG_MTD_SPINAND_GIGADEVICE=y
+CONFIG_MTD_SPINAND_ONDIEECC=y
CONFIG_MTD_SPLIT_FIRMWARE=y
CONFIG_MTD_SPLIT_FIT_FW=y
CONFIG_MTD_UBI=y
diff --git
a/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-bus.dtsi
b/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-bus.dtsi
new file mode 100644
index 00..169505973f
--- /dev/null
+++ b/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-bus.dtsi
@@ -0,0 +1,1142 @@
+/* Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR
Re: [OpenWrt-Devel] improved handling of contributions [Was: Re: patches from 2018]
Adrian Schmutzler [2019-10-29 13:25:27]:
Hi,
> the main difference is just that I prefer some manual interference, where
> you are looking for more automation:
1. DRY
2. Avoiding manual mistakes (and introduce automated ones)
3. Time spent on the tasks which could be automated could be used in other
parts of the project
> (situation might be answered differently for bug reports).
That's exactly my point 3. above. If you wouldn't need to spend your precious
time on the repeating tasks which could be automated, then you could for
example help with bug reports, code, CI, forums, wiki or whatever part you
enjoy doing the most.
> (Despite, with PRs being autoclosed, I wouldn't be surprised if we get lots
> of duplicate PRs instead of old ones reopened, which would also increase
> maintenance efforts.)
We can take a look at this if/when this happens. I think, that actually
opening new PR (or resending patches) is desired as its more likely to bring
the necessary attention.
> > 2. change patch status from 'Needs Review / ACK' to 'Under Review' and
> > assign it randomly (to predefined set of volunteer commiters) after 60
> > days of inactivity
> >
> > - on GH label=`awaiting review`
>
> In principle, yes. However, the volunteers will need to deal with anything
> that comes on the desk.
You can always ping someone on IRC/GH and ask for another pair of eyes.
> I'd personally make that dependant on whether there are volunteers or not.
I'm 100% sure, that there are, otherwise I wouldn't propose that.
> > 3. change patch status from 'Under Review' to 'Needs Review / ACK' after
> > 90 days
> > of inactivity
> >
> > - on GH label=`stale` and remove the randomly assigned reviewer
>
> That's the same as after 30 days? (Chosen because there is no "stale"
> equivalent on PW?)
Yes, exactly.
> > 4. change patch status from 'Needs Review / ACK' to 'Rejected' after 120
> > days
> > of inactivity, sending out some meaningful mail with a link to
> > exaplanation of the currently failed merging process on the wiki
> >
> > - on GH close the PR
>
> As introduced earlier, I would require to do this manually, so at least
> someone has to have a brief look at the thing.
It's already handled in 3. and if even volunteer is not interested even to
ping someone on IRC or GitHub to take over that PR, then simply there is no
interest and you can't do much about it.
You can always merge/reject it by yourself during those ~90 days, right? :-)
The automation is just a last resort to make something happen in short time
span, avoiding us to talk in 2020 about contributions from 2018...
> Despite, if one automates, one of the crucial points will be how to measure
> "activity".
That's just implementation "detail". PW, Git{Lab,Hub} offer nice APIs, so I
believe, that there's always some way.
> And how to deal with bug reports? In contrast to feature requests, a bug
> report cannot just be closed because nobody is interested in addressing it?
And why not?
After Y days of inactivity, we could update the issue with something like
following:
"It seems like the issue is stale, please consider reading
https://openwrt.org/bugs again and adjust your bug report accrodingly.
Consider reproducing this bug on latest https://openwrt.org/releases/snapshot
in order to increase your chances... No activity in the next 14 days will make
this bug report closed with 'No response' reason."
And then close it 2 weeks later. I mean, I'm sometimes doing the same
manually, closing the old issue straight away with "ask for reopen if you can
reproduce it on latest snapshot".
-- ynezz
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH-19.07] build: fix module strip invalid
Current modpost cannot reduce the module size.
Use $(STRIP) command to replace the modpost patch,
I think to be compatibility will be better.
Signed-off-by: daxiong
---
.../linux/generic/hack-4.14/204-module_strip.patch | 216 +++--
1 file changed, 24 insertions(+), 192 deletions(-)
diff --git a/target/linux/generic/hack-4.14/204-module_strip.patch
b/target/linux/generic/hack-4.14/204-module_strip.patch
index d847adf..c22a507 100644
--- a/target/linux/generic/hack-4.14/204-module_strip.patch
+++ b/target/linux/generic/hack-4.14/204-module_strip.patch
@@ -1,104 +1,8 @@
-From a779a482fb9b9f8fcdf8b2519c789b4b9bb5dd05 Mon Sep 17 00:00:00 2001
-From: Felix Fietkau
-Date: Fri, 7 Jul 2017 16:56:48 +0200
-Subject: build: add a hack for removing non-essential module info
-
-Signed-off-by: Felix Fietkau
- include/linux/module.h | 13 -
- include/linux/moduleparam.h | 15 ---
- init/Kconfig| 7 +++
- kernel/module.c | 5 -
- scripts/mod/modpost.c | 12
- 5 files changed, 43 insertions(+), 9 deletions(-)
-
a/include/linux/module.h
-+++ b/include/linux/module.h
-@@ -158,6 +158,7 @@ extern void cleanup_module(void);
-
- /* Generic info of form tag = "info" */
- #define MODULE_INFO(tag, info) __MODULE_INFO(tag, tag, info)
-+#define MODULE_INFO_STRIP(tag, info) __MODULE_INFO_STRIP(tag, tag, info)
-
- /* For userspace: you can also call me... */
- #define MODULE_ALIAS(_alias) MODULE_INFO(alias, _alias)
-@@ -201,12 +202,12 @@ extern void cleanup_module(void);
- * Author(s), use "Name " or just "Name", for multiple
- * authors use multiple MODULE_AUTHOR() statements/lines.
- */
--#define MODULE_AUTHOR(_author) MODULE_INFO(author, _author)
-+#define MODULE_AUTHOR(_author) MODULE_INFO_STRIP(author, _author)
-
- /* What your module does. */
--#define MODULE_DESCRIPTION(_description) MODULE_INFO(description,
_description)
-+#define MODULE_DESCRIPTION(_description) MODULE_INFO_STRIP(description,
_description)
-
--#ifdef MODULE
-+#if defined(MODULE) && !defined(CONFIG_MODULE_STRIPPED)
- /* Creates an alias so file2alias.c can find device table. */
- #define MODULE_DEVICE_TABLE(type, name)
\
- extern typeof(name) __mod_##type##__##name##_device_table \
-@@ -233,7 +234,9 @@ extern typeof(name) __mod_##type##__##na
- */
-
- #if defined(MODULE) || !defined(CONFIG_SYSFS)
--#define MODULE_VERSION(_version) MODULE_INFO(version, _version)
-+#define MODULE_VERSION(_version) MODULE_INFO_STRIP(version, _version)
-+#elif defined(CONFIG_MODULE_STRIPPED)
-+#define MODULE_VERSION(_version) __MODULE_INFO_DISABLED(version)
- #else
- #define MODULE_VERSION(_version) \
- static struct module_version_attribute ___modver_attr = { \
-@@ -255,7 +258,7 @@ extern typeof(name) __mod_##type##__##na
- /* Optional firmware file (or files) needed by the module
- * format is simply firmware file name. Multiple firmware
- * files require multiple MODULE_FIRMWARE() specifiers */
--#define MODULE_FIRMWARE(_firmware) MODULE_INFO(firmware, _firmware)
-+#define MODULE_FIRMWARE(_firmware) MODULE_INFO_STRIP(firmware, _firmware)
-
- struct notifier_block;
-
a/include/linux/moduleparam.h
-+++ b/include/linux/moduleparam.h
-@@ -17,6 +17,16 @@
- /* Chosen so that structs with an unsigned long line up. */
- #define MAX_PARAM_PREFIX_LEN (64 - sizeof(unsigned long))
-
-+/* This struct is here for syntactic coherency, it is not used */
-+#define __MODULE_INFO_DISABLED(name)\
-+ struct __UNIQUE_ID(name) {}
-+
-+#ifdef CONFIG_MODULE_STRIPPED
-+#define __MODULE_INFO_STRIP(tag, name, info) __MODULE_INFO_DISABLED(name)
-+#else
-+#define __MODULE_INFO_STRIP(tag, name, info) __MODULE_INFO(tag, name, info)
-+#endif
-+
- #ifdef MODULE
- #define __MODULE_INFO(tag, name, info)
\
- static const char __UNIQUE_ID(name)[] \
-@@ -24,8 +34,7 @@ static const char __UNIQUE_ID(name)[]
- = __stringify(tag) "=" info
- #else /* !MODULE */
- /* This struct is here for syntactic coherency, it is not used */
--#define __MODULE_INFO(tag, name, info)
\
-- struct __UNIQUE_ID(name) {}
-+#define __MODULE_INFO(tag, name, info) __MODULE_INFO_DISABLED(name)
- #endif
- #define __MODULE_PARM_TYPE(name, _type)
\
- __MODULE_INFO(parmtype, name##type, #name ":" _type)
-@@ -33,7 +42,7 @@ static const char __UNIQUE_ID(name)[]
- /* One for each parameter, describing how to use it. Some files do
-multiple of these per line, so can't just use MODULE_INFO. */
- #define MODULE_PARM_DESC(_parm, desc) \
-- __MODULE_INFO(parm, _parm, #_parm ":" desc)
-+ __MODULE_INFO_STRIP(parm, _parm, #_parm ":" desc)
-
- struct kernel_param;
-
+diff --git a/init/Kconfig b/init/Kconfig
+index
[OpenWrt-Devel] [PATCH-19.07] build: fix module strip invalid
Current modpost cannot reduce the module size.
Use $(STRIP) command to replace the modpost patch,
I think to be compatibility will be better.
Signed-off-by: daxiong
---
.../linux/generic/hack-4.14/204-module_strip.patch | 220 +++--
1 file changed, 28 insertions(+), 192 deletions(-)
diff --git a/target/linux/generic/hack-4.14/204-module_strip.patch
b/target/linux/generic/hack-4.14/204-module_strip.patch
index d847adf..20ac949 100644
--- a/target/linux/generic/hack-4.14/204-module_strip.patch
+++ b/target/linux/generic/hack-4.14/204-module_strip.patch
@@ -1,104 +1,8 @@
-From a779a482fb9b9f8fcdf8b2519c789b4b9bb5dd05 Mon Sep 17 00:00:00 2001
-From: Felix Fietkau
-Date: Fri, 7 Jul 2017 16:56:48 +0200
-Subject: build: add a hack for removing non-essential module info
-
-Signed-off-by: Felix Fietkau
- include/linux/module.h | 13 -
- include/linux/moduleparam.h | 15 ---
- init/Kconfig| 7 +++
- kernel/module.c | 5 -
- scripts/mod/modpost.c | 12
- 5 files changed, 43 insertions(+), 9 deletions(-)
-
a/include/linux/module.h
-+++ b/include/linux/module.h
-@@ -158,6 +158,7 @@ extern void cleanup_module(void);
-
- /* Generic info of form tag = "info" */
- #define MODULE_INFO(tag, info) __MODULE_INFO(tag, tag, info)
-+#define MODULE_INFO_STRIP(tag, info) __MODULE_INFO_STRIP(tag, tag, info)
-
- /* For userspace: you can also call me... */
- #define MODULE_ALIAS(_alias) MODULE_INFO(alias, _alias)
-@@ -201,12 +202,12 @@ extern void cleanup_module(void);
- * Author(s), use "Name " or just "Name", for multiple
- * authors use multiple MODULE_AUTHOR() statements/lines.
- */
--#define MODULE_AUTHOR(_author) MODULE_INFO(author, _author)
-+#define MODULE_AUTHOR(_author) MODULE_INFO_STRIP(author, _author)
-
- /* What your module does. */
--#define MODULE_DESCRIPTION(_description) MODULE_INFO(description,
_description)
-+#define MODULE_DESCRIPTION(_description) MODULE_INFO_STRIP(description,
_description)
-
--#ifdef MODULE
-+#if defined(MODULE) && !defined(CONFIG_MODULE_STRIPPED)
- /* Creates an alias so file2alias.c can find device table. */
- #define MODULE_DEVICE_TABLE(type, name)
\
- extern typeof(name) __mod_##type##__##name##_device_table \
-@@ -233,7 +234,9 @@ extern typeof(name) __mod_##type##__##na
- */
-
- #if defined(MODULE) || !defined(CONFIG_SYSFS)
--#define MODULE_VERSION(_version) MODULE_INFO(version, _version)
-+#define MODULE_VERSION(_version) MODULE_INFO_STRIP(version, _version)
-+#elif defined(CONFIG_MODULE_STRIPPED)
-+#define MODULE_VERSION(_version) __MODULE_INFO_DISABLED(version)
- #else
- #define MODULE_VERSION(_version) \
- static struct module_version_attribute ___modver_attr = { \
-@@ -255,7 +258,7 @@ extern typeof(name) __mod_##type##__##na
- /* Optional firmware file (or files) needed by the module
- * format is simply firmware file name. Multiple firmware
- * files require multiple MODULE_FIRMWARE() specifiers */
--#define MODULE_FIRMWARE(_firmware) MODULE_INFO(firmware, _firmware)
-+#define MODULE_FIRMWARE(_firmware) MODULE_INFO_STRIP(firmware, _firmware)
-
- struct notifier_block;
-
a/include/linux/moduleparam.h
-+++ b/include/linux/moduleparam.h
-@@ -17,6 +17,16 @@
- /* Chosen so that structs with an unsigned long line up. */
- #define MAX_PARAM_PREFIX_LEN (64 - sizeof(unsigned long))
-
-+/* This struct is here for syntactic coherency, it is not used */
-+#define __MODULE_INFO_DISABLED(name)\
-+ struct __UNIQUE_ID(name) {}
-+
-+#ifdef CONFIG_MODULE_STRIPPED
-+#define __MODULE_INFO_STRIP(tag, name, info) __MODULE_INFO_DISABLED(name)
-+#else
-+#define __MODULE_INFO_STRIP(tag, name, info) __MODULE_INFO(tag, name, info)
-+#endif
-+
- #ifdef MODULE
- #define __MODULE_INFO(tag, name, info)
\
- static const char __UNIQUE_ID(name)[] \
-@@ -24,8 +34,7 @@ static const char __UNIQUE_ID(name)[]
- = __stringify(tag) "=" info
- #else /* !MODULE */
- /* This struct is here for syntactic coherency, it is not used */
--#define __MODULE_INFO(tag, name, info)
\
-- struct __UNIQUE_ID(name) {}
-+#define __MODULE_INFO(tag, name, info) __MODULE_INFO_DISABLED(name)
- #endif
- #define __MODULE_PARM_TYPE(name, _type)
\
- __MODULE_INFO(parmtype, name##type, #name ":" _type)
-@@ -33,7 +42,7 @@ static const char __UNIQUE_ID(name)[]
- /* One for each parameter, describing how to use it. Some files do
-multiple of these per line, so can't just use MODULE_INFO. */
- #define MODULE_PARM_DESC(_parm, desc) \
-- __MODULE_INFO(parm, _parm, #_parm ":" desc)
-+ __MODULE_INFO_STRIP(parm, _parm, #_parm ":" desc)
-
- struct kernel_param;
-
+diff --git a/init/Kconfig b/init/Kconfig
+index
