Re: [PATCH] airoha: dts: fix pcie ranges properties
> On Mon, 26 Feb 2024 at 15:07, Lorenzo Bianconi wrote: > > > > > On Fri, 5 Jan 2024 at 17:18, Lorenzo Bianconi wrote: > > > > > > > > Reduce and split pcie controller memory ranges for en7523 SoC > > > > in order to properly load a pcie card on the second port. > > > > > > > > Signed-off-by: Lorenzo Bianconi > > > > > > Sorry for it taking so long, but merged. > > > > no worries :) > > > > > > > > BTW, do you know is there anybody willing to maintain this target? > > > > since I am currently working on en7581 (even if I do not have too much free > > cycles) I can help maintaining it. > > That would be great as currently I have been doing kernel bumps > without a board to test on as > otherwise the target would be dropped. ack, fine. Am I supposed to do something in this case? Regards, Lorenzo > > Regards, > Robert > > > > Regards, > > Lorenzo > > > > > > > > Regards, > > > Robert > > > > --- > > > > target/linux/airoha/dts/en7523.dtsi | 4 ++-- > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/target/linux/airoha/dts/en7523.dtsi > > > > b/target/linux/airoha/dts/en7523.dtsi > > > > index 72478b225cbb..024a89752acb 100644 > > > > --- a/target/linux/airoha/dts/en7523.dtsi > > > > +++ b/target/linux/airoha/dts/en7523.dtsi > > > > @@ -157,7 +157,7 @@ > > > > clocks = < EN7523_CLK_PCIE>; > > > > clock-names = "sys_ck0"; > > > > bus-range = <0x00 0xff>; > > > > - ranges = <0x8200 0 0x2000 0x2000 0 > > > > 0x800>; > > > > + ranges = <0x8200 0 0x2000 0x2000 0 > > > > 0x200>; > > > > status = "disabled"; > > > > > > > > #interrupt-cells = <1>; > > > > @@ -186,7 +186,7 @@ > > > > clocks = < EN7523_CLK_PCIE>; > > > > clock-names = "sys_ck1"; > > > > bus-range = <0x00 0xff>; > > > > - ranges = <0x8200 0 0x2800 0x2800 0 > > > > 0x800>; > > > > + ranges = <0x8200 0 0x2200 0x2200 0 > > > > 0x200>; > > > > status = "disabled"; > > > > > > > > #interrupt-cells = <1>; > > > > -- > > > > 2.43.0 > > > > > > > > > > > > ___ > > > > openwrt-devel mailing list > > > > openwrt-devel@lists.openwrt.org > > > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] airoha: dts: fix pcie ranges properties
> On Fri, 5 Jan 2024 at 17:18, Lorenzo Bianconi wrote: > > > > Reduce and split pcie controller memory ranges for en7523 SoC > > in order to properly load a pcie card on the second port. > > > > Signed-off-by: Lorenzo Bianconi > > Sorry for it taking so long, but merged. no worries :) > > BTW, do you know is there anybody willing to maintain this target? since I am currently working on en7581 (even if I do not have too much free cycles) I can help maintaining it. Regards, Lorenzo > > Regards, > Robert > > --- > > target/linux/airoha/dts/en7523.dtsi | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/target/linux/airoha/dts/en7523.dtsi > > b/target/linux/airoha/dts/en7523.dtsi > > index 72478b225cbb..024a89752acb 100644 > > --- a/target/linux/airoha/dts/en7523.dtsi > > +++ b/target/linux/airoha/dts/en7523.dtsi > > @@ -157,7 +157,7 @@ > > clocks = < EN7523_CLK_PCIE>; > > clock-names = "sys_ck0"; > > bus-range = <0x00 0xff>; > > - ranges = <0x8200 0 0x2000 0x2000 0 0x800>; > > + ranges = <0x8200 0 0x2000 0x2000 0 0x200>; > > status = "disabled"; > > > > #interrupt-cells = <1>; > > @@ -186,7 +186,7 @@ > > clocks = < EN7523_CLK_PCIE>; > > clock-names = "sys_ck1"; > > bus-range = <0x00 0xff>; > > - ranges = <0x8200 0 0x2800 0x2800 0 0x800>; > > + ranges = <0x8200 0 0x2200 0x2200 0 0x200>; > > status = "disabled"; > > > > #interrupt-cells = <1>; > > -- > > 2.43.0 > > > > > > ___ > > openwrt-devel mailing list > > openwrt-devel@lists.openwrt.org > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] airoha: dts: fix pcie ranges properties
Reduce and split pcie controller memory ranges for en7523 SoC in order to properly load a pcie card on the second port. Signed-off-by: Lorenzo Bianconi --- target/linux/airoha/dts/en7523.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/target/linux/airoha/dts/en7523.dtsi b/target/linux/airoha/dts/en7523.dtsi index 72478b225cbb..024a89752acb 100644 --- a/target/linux/airoha/dts/en7523.dtsi +++ b/target/linux/airoha/dts/en7523.dtsi @@ -157,7 +157,7 @@ clocks = < EN7523_CLK_PCIE>; clock-names = "sys_ck0"; bus-range = <0x00 0xff>; - ranges = <0x8200 0 0x2000 0x2000 0 0x800>; + ranges = <0x8200 0 0x2000 0x2000 0 0x200>; status = "disabled"; #interrupt-cells = <1>; @@ -186,7 +186,7 @@ clocks = < EN7523_CLK_PCIE>; clock-names = "sys_ck1"; bus-range = <0x00 0xff>; - ranges = <0x8200 0 0x2800 0x2800 0 0x800>; + ranges = <0x8200 0 0x2200 0x2200 0 0x200>; status = "disabled"; #interrupt-cells = <1>; -- 2.43.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] mt76: fix Makefile dependencies for mt7921
Signed-off-by: Lorenzo Bianconi --- package/kernel/mt76/Makefile | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/package/kernel/mt76/Makefile b/package/kernel/mt76/Makefile index 8210478c37f1..9af329b4867d 100644 --- a/package/kernel/mt76/Makefile +++ b/package/kernel/mt76/Makefile @@ -227,16 +227,17 @@ define KernelPackage/mt7915e endef define KernelPackage/mt7921-common + $(KernelPackage/mt76-default) TITLE:=MediaTek MT7615 wireless driver common code HIDDEN:=1 - DEPENDS+=@PCI_SUPPORT +kmod-mt76-core +kmod-mt76-connac + DEPENDS+=+kmod-mt76-connac +@DRIVER_11AX_SUPPORT FILES:= $(PKG_BUILD_DIR)/mt7921/mt7921-common.ko endef define KernelPackage/mt7921s $(KernelPackage/mt76-default) TITLE:=MediaTek MT7921s wireless driver - DEPENDS+=@PCI_SUPPORT +kmod-mt76-connac +kmod-mt76-sdio +kmod-mt7921-common + DEPENDS+=+kmod-mt76-sdio +kmod-mt7921-common FILES:= $(PKG_BUILD_DIR)/mt7921/mt7921s.ko AUTOLOAD:=$(call AutoProbe,mt7921s) endef @@ -244,7 +245,7 @@ endef define KernelPackage/mt7921e $(KernelPackage/mt76-default) TITLE:=MediaTek MT7921e wireless driver - DEPENDS+=@PCI_SUPPORT +kmod-mt76-connac +kmod-mt7921-common + DEPENDS+=@PCI_SUPPORT +kmod-mt7921-common FILES:= $(PKG_BUILD_DIR)/mt7921/mt7921e.ko AUTOLOAD:=$(call AutoProbe,mt7921e) endef -- 2.33.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] mediatek: enable mtk_efuse by default
Enable by default mtk_efuse driver since it needed by mtk_thermal driver to read sensor calibration data Signed-off-by: Lorenzo Bianconi --- target/linux/mediatek/mt7622/config-4.19 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/mediatek/mt7622/config-4.19 b/target/linux/mediatek/mt7622/config-4.19 index 5e3ceb3574..8f5e3bcaef 100755 --- a/target/linux/mediatek/mt7622/config-4.19 +++ b/target/linux/mediatek/mt7622/config-4.19 @@ -401,7 +401,7 @@ CONFIG_MTD_SPLIT_UIMAGE_FW=y CONFIG_MTK_DISP_PLATFORM="" # CONFIG_MTK_DRE30_SUPPORT is not set # CONFIG_MTK_DVFSRC is not set -# CONFIG_MTK_EFUSE is not set +CONFIG_MTK_EFUSE=y # CONFIG_MTK_GED_SUPPORT is not set # CONFIG_MTK_GPS_SUPPORT is not set # CONFIG_MTK_GPU_COMMON_DVFS_SUPPORT is not set -- 2.21.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
> > > >> Hi Joe, > >> > >>> Lorenzo, I deployed an ath9k auto distance solution in April that is > >>> working for the AREDN community http://www.arednmesh.org . > >>> > >>> https://github.com/aredn/aredn_ar71xx/blob/develop/patches/712-auto-distance-settings.patch > >>> > >>> Summary of solution: > >>> > >>> * no dependency on wpa_supplicant > >>> * initial ack_to is set to max, to not enter late ack conditions > >>> * User level trigger to flip distance setting to static and back to > >>> auto when new 802.11 adhoc neighbor joins. (we archive and chart SNR > >>> values for neighbors and natural to hook in this trigger). > >> Have you initialized the ackto to the max value to remove wpa_supplicant > >> dependency or because the system is not able to trigger the 'late ack'? > >> I did not get why you need to flip the algo off/on when new 802.11 adhoc > >> neighbor joins > >> > >> Regards, > >> Lorenzo > >> > > initialized the ackto to max: > > > > A) avoidance of late-ack state > > B) not require wpa_supplicant -- not in use by our community today > > C) Suspect some conditions, e.g. low SNR Neighbors, do not trigger > > "late ack" (consistent, with observation of low SNR Neighbors sticking > > at max ack_to with my changes ) > > > > flip the algo off/on when new neighbor joins: > > > > Intended technique to reset ack_to to max. If ack_to is set to 20km > > and then a new adhoc neighbor joins at 30km, this would be a late ack > > state, and unable to detect.My early testing results showed the > > algo off/on would restart the ack_to to max and start the process over > > with the new neighbor. I trust I got it right? > > > > There are 10s to 100s of users testing this bleeding edge change from > > nightly builds, and so far, I've not found a failure case. > > Although, the findings are showing the cases where static setting has > > better throughput. > > > > Joe AE6XE > > > >>> > > > > Lorenzo, > Hi Koen, > It's been a while regarding the above. > > I can confirm the issue that if the algorithm misses the late ack's due > to low initial snr, the initial ack_to is too low to recover afterwards. > are you referring to tx side or rx side? are you able to reproduce the issue with debug enable? I guess the system will resend the assoc request/response packets so eventually we should be able tack the 'late ack' > Do you think it would be useful to start at high ack_to and let it > estimate/drop afterwards? > I think we can add more logic to take care of this issue but first I would have a clearer idea of the problem > Ps. > > I've got my 24km link back if required to do some additional testing. > cool :) Regards, Lorenzo > > Thanks, > > Koen > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
> On Thu, Apr 4, 2019 at 12:20 AM Lorenzo Bianconi
> wrote:
> >
> > > On Wed, Apr 3, 2019 at 7:40 AM Lorenzo Bianconi
> > > wrote:
> > > >
> > > > >
> > > > > On Tue, Apr 2, 2019 at 11:45 PM Lorenzo Bianconi
> > > > > wrote:
> > > > > >
> > > > > > >
> > > > > > > On Sun, Mar 31, 2019 at 11:49 PM Lorenzo Bianconi
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > >
> > > > > > > > > On Sun, Mar 31, 2019 at 12:15 PM Lorenzo Bianconi
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Sun, Mar 31, 2019 at 6:45 AM Lorenzo Bianconi
> > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > bump.
> > > > > > > > > > > >
> > > > > > > > > > > > Hi Joe,
> > > > > > > > > > > >
> > > > > > > > > > > > sorry for the delay
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Mon, Mar 18, 2019 at 10:59 PM Joe Ayers
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> Lorenzo, I have tested dynack on a (real distance
> > > > > > > > > > > > >> apart) ~60km link
> > > > > > > > > > > > >> with some success. This is the code change made:
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> --- a/drivers/net/wireless/ath/ath9k/dynack.c
> > > > > > > > > > > > >> +++ b/drivers/net/wireless/ath/ath9k/dynack.c
> > > > > > > > > > > > >> @@ -20,8 +20,9 @@
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> #define COMPUTE_TO (5 * HZ)
> > > > > > > > > > > > >> #define LATEACK_DELAY (10 * HZ)
> > > > > > > > > > > > >> -#define LATEACK_TO 256
> > > > > > > > > > > > >> -#define MAX_DELAY 300
> > > > > > > > > > > > >> +#define LATEACK_TO 1054
> > > > > > > > > > > > >> +/* AREDN max distance set to 150km */
> > > > > > > > > > > > >> +#define MAX_DELAY 1054
> > > > > > > > > > > > >> #define EWMA_LEVEL 96
> > > > > > > > > > > > >> #define EWMA_DIV 128
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> @@ -293,7 +294,8 @@
> > > > > > > > > > > > >> void ath_dynack_node_init(struct ath_hw *ah, struct
> > > > > > > > > > > > >> ath_node *an)
> > > > > > > > > > > > >> {
> > > > > > > > > > > > >> /* ackto = slottime + sifs + air delay */
> > > > > > > > > > > > >> - u32 ackto = 9 + 16 + 64;
> > > > > > > > > > > > >> + /* AREDN starting point is 20km */
> > > > > > > > > > > > >> + u32 ackto = 9 + 16 + 171;
> > > > > > > > > > > > >> struct ath_dynack *da = >dynack;
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> an->ackto = ackto;
> > > > > > > > > > > > >> @@ -328,7 +330,8 @@
> > > > > > > > > > > > >> void ath_dynack_reset(struct ath_hw *ah)
> > > > > > > > > > > > >> {
> > > > > > > > > > > > >> /* ackto = slottime + sifs + air delay
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
> On Wed, Apr 3, 2019 at 7:40 AM Lorenzo Bianconi
> wrote:
> >
> > >
> > > On Tue, Apr 2, 2019 at 11:45 PM Lorenzo Bianconi
> > > wrote:
> > > >
> > > > >
> > > > > On Sun, Mar 31, 2019 at 11:49 PM Lorenzo Bianconi
> > > > > wrote:
> > > > > >
> > > > > > >
> > > > > > > On Sun, Mar 31, 2019 at 12:15 PM Lorenzo Bianconi
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > >
> > > > > > > > > On Sun, Mar 31, 2019 at 6:45 AM Lorenzo Bianconi
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > bump.
> > > > > > > > > >
> > > > > > > > > > Hi Joe,
> > > > > > > > > >
> > > > > > > > > > sorry for the delay
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Mon, Mar 18, 2019 at 10:59 PM Joe Ayers
> > > > > > > > > > > wrote:
> > > > > > > > > > >>
> > > > > > > > > > >> Lorenzo, I have tested dynack on a (real distance
> > > > > > > > > > >> apart) ~60km link
> > > > > > > > > > >> with some success. This is the code change made:
> > > > > > > > > > >>
> > > > > > > > > > >> --- a/drivers/net/wireless/ath/ath9k/dynack.c
> > > > > > > > > > >> +++ b/drivers/net/wireless/ath/ath9k/dynack.c
> > > > > > > > > > >> @@ -20,8 +20,9 @@
> > > > > > > > > > >>
> > > > > > > > > > >> #define COMPUTE_TO (5 * HZ)
> > > > > > > > > > >> #define LATEACK_DELAY (10 * HZ)
> > > > > > > > > > >> -#define LATEACK_TO 256
> > > > > > > > > > >> -#define MAX_DELAY 300
> > > > > > > > > > >> +#define LATEACK_TO 1054
> > > > > > > > > > >> +/* AREDN max distance set to 150km */
> > > > > > > > > > >> +#define MAX_DELAY 1054
> > > > > > > > > > >> #define EWMA_LEVEL 96
> > > > > > > > > > >> #define EWMA_DIV 128
> > > > > > > > > > >>
> > > > > > > > > > >> @@ -293,7 +294,8 @@
> > > > > > > > > > >> void ath_dynack_node_init(struct ath_hw *ah, struct
> > > > > > > > > > >> ath_node *an)
> > > > > > > > > > >> {
> > > > > > > > > > >> /* ackto = slottime + sifs + air delay */
> > > > > > > > > > >> - u32 ackto = 9 + 16 + 64;
> > > > > > > > > > >> + /* AREDN starting point is 20km */
> > > > > > > > > > >> + u32 ackto = 9 + 16 + 171;
> > > > > > > > > > >> struct ath_dynack *da = >dynack;
> > > > > > > > > > >>
> > > > > > > > > > >> an->ackto = ackto;
> > > > > > > > > > >> @@ -328,7 +330,8 @@
> > > > > > > > > > >> void ath_dynack_reset(struct ath_hw *ah)
> > > > > > > > > > >> {
> > > > > > > > > > >> /* ackto = slottime + sifs + air delay */
> > > > > > > > > > >> - u32 ackto = 9 + 16 + 64;
> > > > > > > > > > >> + /* AREDN starting point is 20km */
> > > > > > > > > > >> + u32 ackto = 9 + 16 + 171;
> > > > > > > > > > >> struct ath_dynack *da = >dynack;
> > > > > > > > > > >>
> > > > > > > > > > >> da->lto = jiffies;
> > > > > > > > > > >>
> > > > > > > > > > >> Notes:
> > > > > > > > > > >>
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
>
> On Tue, Apr 2, 2019 at 11:45 PM Lorenzo Bianconi
> wrote:
> >
> > >
> > > On Sun, Mar 31, 2019 at 11:49 PM Lorenzo Bianconi
> > > wrote:
> > > >
> > > > >
> > > > > On Sun, Mar 31, 2019 at 12:15 PM Lorenzo Bianconi
> > > > > wrote:
> > > > > >
> > > > > > >
> > > > > > > On Sun, Mar 31, 2019 at 6:45 AM Lorenzo Bianconi
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > >
> > > > > > > > > bump.
> > > > > > > >
> > > > > > > > Hi Joe,
> > > > > > > >
> > > > > > > > sorry for the delay
> > > > > > > >
> > > > > > > > >
> > > > > > > > > On Mon, Mar 18, 2019 at 10:59 PM Joe Ayers
> > > > > > > > > wrote:
> > > > > > > > >>
> > > > > > > > >> Lorenzo, I have tested dynack on a (real distance apart)
> > > > > > > > >> ~60km link
> > > > > > > > >> with some success. This is the code change made:
> > > > > > > > >>
> > > > > > > > >> --- a/drivers/net/wireless/ath/ath9k/dynack.c
> > > > > > > > >> +++ b/drivers/net/wireless/ath/ath9k/dynack.c
> > > > > > > > >> @@ -20,8 +20,9 @@
> > > > > > > > >>
> > > > > > > > >> #define COMPUTE_TO (5 * HZ)
> > > > > > > > >> #define LATEACK_DELAY (10 * HZ)
> > > > > > > > >> -#define LATEACK_TO 256
> > > > > > > > >> -#define MAX_DELAY 300
> > > > > > > > >> +#define LATEACK_TO 1054
> > > > > > > > >> +/* AREDN max distance set to 150km */
> > > > > > > > >> +#define MAX_DELAY 1054
> > > > > > > > >> #define EWMA_LEVEL 96
> > > > > > > > >> #define EWMA_DIV 128
> > > > > > > > >>
> > > > > > > > >> @@ -293,7 +294,8 @@
> > > > > > > > >> void ath_dynack_node_init(struct ath_hw *ah, struct
> > > > > > > > >> ath_node *an)
> > > > > > > > >> {
> > > > > > > > >> /* ackto = slottime + sifs + air delay */
> > > > > > > > >> - u32 ackto = 9 + 16 + 64;
> > > > > > > > >> + /* AREDN starting point is 20km */
> > > > > > > > >> + u32 ackto = 9 + 16 + 171;
> > > > > > > > >> struct ath_dynack *da = >dynack;
> > > > > > > > >>
> > > > > > > > >> an->ackto = ackto;
> > > > > > > > >> @@ -328,7 +330,8 @@
> > > > > > > > >> void ath_dynack_reset(struct ath_hw *ah)
> > > > > > > > >> {
> > > > > > > > >> /* ackto = slottime + sifs + air delay */
> > > > > > > > >> - u32 ackto = 9 + 16 + 64;
> > > > > > > > >> + /* AREDN starting point is 20km */
> > > > > > > > >> + u32 ackto = 9 + 16 + 171;
> > > > > > > > >> struct ath_dynack *da = >dynack;
> > > > > > > > >>
> > > > > > > > >> da->lto = jiffies;
> > > > > > > > >>
> > > > > > > > >> Notes:
> > > > > > > > >>
> > > > > > > > >> 1) The stations are showing ack_to between 525 up to 575 A.
> > > > > > > > >> When
> > > > > > > > >> static set at 60k distance, the timeout is set to 460 S.
> > > > > > > > >> 2) significant performance improvement between these
> > > > > > > > >> settings with
> > > > > > > > >> iperf3 and back to back runs with reboot in the middle:
> > > > > > > > >>
> > > > > > > >
> > > > > > > > could you please try to attached patch? The max distance the hw
> > > > > > > > c
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
>
> On Sun, Mar 31, 2019 at 11:49 PM Lorenzo Bianconi
> wrote:
> >
> > >
> > > On Sun, Mar 31, 2019 at 12:15 PM Lorenzo Bianconi
> > > wrote:
> > > >
> > > > >
> > > > > On Sun, Mar 31, 2019 at 6:45 AM Lorenzo Bianconi
> > > > > wrote:
> > > > > >
> > > > > > >
> > > > > > > bump.
> > > > > >
> > > > > > Hi Joe,
> > > > > >
> > > > > > sorry for the delay
> > > > > >
> > > > > > >
> > > > > > > On Mon, Mar 18, 2019 at 10:59 PM Joe Ayers
> > > > > > > wrote:
> > > > > > >>
> > > > > > >> Lorenzo, I have tested dynack on a (real distance apart) ~60km
> > > > > > >> link
> > > > > > >> with some success. This is the code change made:
> > > > > > >>
> > > > > > >> --- a/drivers/net/wireless/ath/ath9k/dynack.c
> > > > > > >> +++ b/drivers/net/wireless/ath/ath9k/dynack.c
> > > > > > >> @@ -20,8 +20,9 @@
> > > > > > >>
> > > > > > >> #define COMPUTE_TO (5 * HZ)
> > > > > > >> #define LATEACK_DELAY (10 * HZ)
> > > > > > >> -#define LATEACK_TO 256
> > > > > > >> -#define MAX_DELAY 300
> > > > > > >> +#define LATEACK_TO 1054
> > > > > > >> +/* AREDN max distance set to 150km */
> > > > > > >> +#define MAX_DELAY 1054
> > > > > > >> #define EWMA_LEVEL 96
> > > > > > >> #define EWMA_DIV 128
> > > > > > >>
> > > > > > >> @@ -293,7 +294,8 @@
> > > > > > >> void ath_dynack_node_init(struct ath_hw *ah, struct ath_node
> > > > > > >> *an)
> > > > > > >> {
> > > > > > >> /* ackto = slottime + sifs + air delay */
> > > > > > >> - u32 ackto = 9 + 16 + 64;
> > > > > > >> + /* AREDN starting point is 20km */
> > > > > > >> + u32 ackto = 9 + 16 + 171;
> > > > > > >> struct ath_dynack *da = >dynack;
> > > > > > >>
> > > > > > >> an->ackto = ackto;
> > > > > > >> @@ -328,7 +330,8 @@
> > > > > > >> void ath_dynack_reset(struct ath_hw *ah)
> > > > > > >> {
> > > > > > >> /* ackto = slottime + sifs + air delay */
> > > > > > >> - u32 ackto = 9 + 16 + 64;
> > > > > > >> + /* AREDN starting point is 20km */
> > > > > > >> + u32 ackto = 9 + 16 + 171;
> > > > > > >> struct ath_dynack *da = >dynack;
> > > > > > >>
> > > > > > >> da->lto = jiffies;
> > > > > > >>
> > > > > > >> Notes:
> > > > > > >>
> > > > > > >> 1) The stations are showing ack_to between 525 up to 575 A. When
> > > > > > >> static set at 60k distance, the timeout is set to 460 S.
> > > > > > >> 2) significant performance improvement between these settings
> > > > > > >> with
> > > > > > >> iperf3 and back to back runs with reboot in the middle:
> > > > > > >>
> > > > > >
> > > > > > could you please try to attached patch? The max distance the hw can
> > > > > > support depends of channel width:
> > > > > > e.g @20MHz (HT20, 5GHz)
> > > > > >
> > > > > > max distance is ~ 61Km
> > > > > >
> > > > >
> > > > > Could these max distance specs be what the manufacture tested, not
> > > > > necessarily a hardware limitation -- just not known?
> > > > >
> > > >
> > > > https://github.com/torvalds/linux/blob/master/drivers/net/wireless/ath/ath9k/hw.c#L1006
> > > >
> > > > max timeout you can set is AR_TIME_OUT_ACK (0x3fff) / clock_rate
> > > >
> > > > > I suspect in the calculation for max_to, if the channel is 10MHz, the
> > > > > max distance can be doubled for the hardware--do the specs only
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
>
> On Sun, Mar 31, 2019 at 12:15 PM Lorenzo Bianconi
> wrote:
> >
> > >
> > > On Sun, Mar 31, 2019 at 6:45 AM Lorenzo Bianconi
> > > wrote:
> > > >
> > > > >
> > > > > bump.
> > > >
> > > > Hi Joe,
> > > >
> > > > sorry for the delay
> > > >
> > > > >
> > > > > On Mon, Mar 18, 2019 at 10:59 PM Joe Ayers wrote:
> > > > >>
> > > > >> Lorenzo, I have tested dynack on a (real distance apart) ~60km link
> > > > >> with some success. This is the code change made:
> > > > >>
> > > > >> --- a/drivers/net/wireless/ath/ath9k/dynack.c
> > > > >> +++ b/drivers/net/wireless/ath/ath9k/dynack.c
> > > > >> @@ -20,8 +20,9 @@
> > > > >>
> > > > >> #define COMPUTE_TO (5 * HZ)
> > > > >> #define LATEACK_DELAY (10 * HZ)
> > > > >> -#define LATEACK_TO 256
> > > > >> -#define MAX_DELAY 300
> > > > >> +#define LATEACK_TO 1054
> > > > >> +/* AREDN max distance set to 150km */
> > > > >> +#define MAX_DELAY 1054
> > > > >> #define EWMA_LEVEL 96
> > > > >> #define EWMA_DIV 128
> > > > >>
> > > > >> @@ -293,7 +294,8 @@
> > > > >> void ath_dynack_node_init(struct ath_hw *ah, struct ath_node *an)
> > > > >> {
> > > > >> /* ackto = slottime + sifs + air delay */
> > > > >> - u32 ackto = 9 + 16 + 64;
> > > > >> + /* AREDN starting point is 20km */
> > > > >> + u32 ackto = 9 + 16 + 171;
> > > > >> struct ath_dynack *da = >dynack;
> > > > >>
> > > > >> an->ackto = ackto;
> > > > >> @@ -328,7 +330,8 @@
> > > > >> void ath_dynack_reset(struct ath_hw *ah)
> > > > >> {
> > > > >> /* ackto = slottime + sifs + air delay */
> > > > >> - u32 ackto = 9 + 16 + 64;
> > > > >> + /* AREDN starting point is 20km */
> > > > >> + u32 ackto = 9 + 16 + 171;
> > > > >> struct ath_dynack *da = >dynack;
> > > > >>
> > > > >> da->lto = jiffies;
> > > > >>
> > > > >> Notes:
> > > > >>
> > > > >> 1) The stations are showing ack_to between 525 up to 575 A. When
> > > > >> static set at 60k distance, the timeout is set to 460 S.
> > > > >> 2) significant performance improvement between these settings with
> > > > >> iperf3 and back to back runs with reboot in the middle:
> > > > >>
> > > >
> > > > could you please try to attached patch? The max distance the hw can
> > > > support depends of channel width:
> > > > e.g @20MHz (HT20, 5GHz)
> > > >
> > > > max distance is ~ 61Km
> > > >
> > >
> > > Could these max distance specs be what the manufacture tested, not
> > > necessarily a hardware limitation -- just not known?
> > >
> >
> > https://github.com/torvalds/linux/blob/master/drivers/net/wireless/ath/ath9k/hw.c#L1006
> >
> > max timeout you can set is AR_TIME_OUT_ACK (0x3fff) / clock_rate
> >
> > > I suspect in the calculation for max_to, if the channel is 10MHz, the
> > > max distance can be doubled for the hardware--do the specs only give
> > > 20MHz values? This would be consistent with, for example, the symbol
> > > lengths are doubled when cutting the bandwidth in half, hence half the
> > > rates and still 64 bins or 64 point fft squeezed in the channel. SNR
> > > is also 3dB higher given same energy in half the bandwidth. We don't
> > > see 20MHz channels working at these long distances, rather use 10MHz
> > > for it to work. Intuitively, as I understand it, more time is needed
> > > with increased distance for reflection signals to not be received past
> > > the symbol time and increased inter-symbol interference.
> >
> > yes, but it is already done in ath9k_hw_set_clockrate()
> > https://github.com/torvalds/linux/blob/master/drivers/net/wireless/ath/ath9k/hw.c#L61
> >
> > >
> > > > @Koen: do you have any chance to test the attached patch in your
> > > > environment? Thx
> > > >
> > > > >> run 1 @ static 60
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
>
> On Sun, Mar 31, 2019 at 6:45 AM Lorenzo Bianconi
> wrote:
> >
> > >
> > > bump.
> >
> > Hi Joe,
> >
> > sorry for the delay
> >
> > >
> > > On Mon, Mar 18, 2019 at 10:59 PM Joe Ayers wrote:
> > >>
> > >> Lorenzo, I have tested dynack on a (real distance apart) ~60km link
> > >> with some success. This is the code change made:
> > >>
> > >> --- a/drivers/net/wireless/ath/ath9k/dynack.c
> > >> +++ b/drivers/net/wireless/ath/ath9k/dynack.c
> > >> @@ -20,8 +20,9 @@
> > >>
> > >> #define COMPUTE_TO (5 * HZ)
> > >> #define LATEACK_DELAY (10 * HZ)
> > >> -#define LATEACK_TO 256
> > >> -#define MAX_DELAY 300
> > >> +#define LATEACK_TO 1054
> > >> +/* AREDN max distance set to 150km */
> > >> +#define MAX_DELAY 1054
> > >> #define EWMA_LEVEL 96
> > >> #define EWMA_DIV 128
> > >>
> > >> @@ -293,7 +294,8 @@
> > >> void ath_dynack_node_init(struct ath_hw *ah, struct ath_node *an)
> > >> {
> > >> /* ackto = slottime + sifs + air delay */
> > >> - u32 ackto = 9 + 16 + 64;
> > >> + /* AREDN starting point is 20km */
> > >> + u32 ackto = 9 + 16 + 171;
> > >> struct ath_dynack *da = >dynack;
> > >>
> > >> an->ackto = ackto;
> > >> @@ -328,7 +330,8 @@
> > >> void ath_dynack_reset(struct ath_hw *ah)
> > >> {
> > >> /* ackto = slottime + sifs + air delay */
> > >> - u32 ackto = 9 + 16 + 64;
> > >> + /* AREDN starting point is 20km */
> > >> + u32 ackto = 9 + 16 + 171;
> > >> struct ath_dynack *da = >dynack;
> > >>
> > >> da->lto = jiffies;
> > >>
> > >> Notes:
> > >>
> > >> 1) The stations are showing ack_to between 525 up to 575 A. When
> > >> static set at 60k distance, the timeout is set to 460 S.
> > >> 2) significant performance improvement between these settings with
> > >> iperf3 and back to back runs with reboot in the middle:
> > >>
> >
> > could you please try to attached patch? The max distance the hw can
> > support depends of channel width:
> > e.g @20MHz (HT20, 5GHz)
> >
> > max distance is ~ 61Km
> >
>
> Could these max distance specs be what the manufacture tested, not
> necessarily a hardware limitation -- just not known?
>
https://github.com/torvalds/linux/blob/master/drivers/net/wireless/ath/ath9k/hw.c#L1006
max timeout you can set is AR_TIME_OUT_ACK (0x3fff) / clock_rate
> I suspect in the calculation for max_to, if the channel is 10MHz, the
> max distance can be doubled for the hardware--do the specs only give
> 20MHz values? This would be consistent with, for example, the symbol
> lengths are doubled when cutting the bandwidth in half, hence half the
> rates and still 64 bins or 64 point fft squeezed in the channel. SNR
> is also 3dB higher given same energy in half the bandwidth. We don't
> see 20MHz channels working at these long distances, rather use 10MHz
> for it to work. Intuitively, as I understand it, more time is needed
> with increased distance for reflection signals to not be received past
> the symbol time and increased inter-symbol interference.
yes, but it is already done in ath9k_hw_set_clockrate()
https://github.com/torvalds/linux/blob/master/drivers/net/wireless/ath/ath9k/hw.c#L61
>
> > @Koen: do you have any chance to test the attached patch in your
> > environment? Thx
> >
> > >> run 1 @ static 60km:
> > >> [ 5] 0.00-10.00 sec 7.31 MBytes 6.13 Mbits/sec0
> > >> sender
> > >> [ 5] 0.00-10.08 sec 7.16 MBytes 5.95 Mbits/sec
> > >> receiver
> > >>
> > >> run 2 @ static 60km:
> > >> [ 5] 0.00-10.00 sec 5.88 MBytes 4.93 Mbits/sec0
> > >> sender
> > >> [ 5] 0.00-10.04 sec 5.77 MBytes 4.81 Mbits/sec
> > >> receiver
> > >>
> > >> run 1 and 2 @ auto distance -- goes up to ~575us with data flow,
> > >> floats back to ~525 otherwise:
> > >> [ 5] 0.00-10.00 sec 20.0 MBytes 16.8 Mbits/sec0
> > >> sender
> > >> [ 5] 0.00-10.07 sec 19.8 MBytes 16.5 Mbits/sec
> > >> receiver
> > >>
> > >> [ 5] 0.00-10.00 sec 21.4 MBytes 18.0 Mbits/sec
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
>
> bump.
Hi Joe,
sorry for the delay
>
> On Mon, Mar 18, 2019 at 10:59 PM Joe Ayers wrote:
>>
>> Lorenzo, I have tested dynack on a (real distance apart) ~60km link
>> with some success. This is the code change made:
>>
>> --- a/drivers/net/wireless/ath/ath9k/dynack.c
>> +++ b/drivers/net/wireless/ath/ath9k/dynack.c
>> @@ -20,8 +20,9 @@
>>
>> #define COMPUTE_TO (5 * HZ)
>> #define LATEACK_DELAY (10 * HZ)
>> -#define LATEACK_TO 256
>> -#define MAX_DELAY 300
>> +#define LATEACK_TO 1054
>> +/* AREDN max distance set to 150km */
>> +#define MAX_DELAY 1054
>> #define EWMA_LEVEL 96
>> #define EWMA_DIV 128
>>
>> @@ -293,7 +294,8 @@
>> void ath_dynack_node_init(struct ath_hw *ah, struct ath_node *an)
>> {
>> /* ackto = slottime + sifs + air delay */
>> - u32 ackto = 9 + 16 + 64;
>> + /* AREDN starting point is 20km */
>> + u32 ackto = 9 + 16 + 171;
>> struct ath_dynack *da = >dynack;
>>
>> an->ackto = ackto;
>> @@ -328,7 +330,8 @@
>> void ath_dynack_reset(struct ath_hw *ah)
>> {
>> /* ackto = slottime + sifs + air delay */
>> - u32 ackto = 9 + 16 + 64;
>> + /* AREDN starting point is 20km */
>> + u32 ackto = 9 + 16 + 171;
>> struct ath_dynack *da = >dynack;
>>
>> da->lto = jiffies;
>>
>> Notes:
>>
>> 1) The stations are showing ack_to between 525 up to 575 A. When
>> static set at 60k distance, the timeout is set to 460 S.
>> 2) significant performance improvement between these settings with
>> iperf3 and back to back runs with reboot in the middle:
>>
could you please try to attached patch? The max distance the hw can
support depends of channel width:
e.g @20MHz (HT20, 5GHz)
max distance is ~ 61Km
@Koen: do you have any chance to test the attached patch in your
environment? Thx
>> run 1 @ static 60km:
>> [ 5] 0.00-10.00 sec 7.31 MBytes 6.13 Mbits/sec0 sender
>> [ 5] 0.00-10.08 sec 7.16 MBytes 5.95 Mbits/sec
>> receiver
>>
>> run 2 @ static 60km:
>> [ 5] 0.00-10.00 sec 5.88 MBytes 4.93 Mbits/sec0 sender
>> [ 5] 0.00-10.04 sec 5.77 MBytes 4.81 Mbits/sec
>> receiver
>>
>> run 1 and 2 @ auto distance -- goes up to ~575us with data flow,
>> floats back to ~525 otherwise:
>> [ 5] 0.00-10.00 sec 20.0 MBytes 16.8 Mbits/sec0 sender
>> [ 5] 0.00-10.07 sec 19.8 MBytes 16.5 Mbits/sec
>> receiver
>>
>> [ 5] 0.00-10.00 sec 21.4 MBytes 18.0 Mbits/sec0 sender
>> [ 5] 0.00-10.04 sec 21.2 MBytes 17.7 Mbits/sec
>> receiver
>>
>> 3) running wpa_supplicant and psk2
>> 4) running ibss on ch 176 with AREDN channels on top of 18.06.2
>> 5) on one reboot, one of the stations stayed down at initial 196, then
>> bumped up to ~250 range and stayed there, link not functional. Not
>> sure how to explain this value...
>>
>> Question, can this condition be true periodically while the link is
>> live or only at initial 802.11 adhoc link setup?:
>>
>> if (ieee80211_is_assoc_req(hdr->frame_control) ||
>> ieee80211_is_assoc_resp(hdr->frame_control) ||
>> ieee80211_is_auth(hdr->frame_control)) {
>>
I do not think so since AFAIK auth frames are sent just during ibss join
>> 6) Auto distance stayed at initial 196 when turning off encryption.
>>
>> Any ideas of alternative options of packets to key off in late ack
>> situation? running wpad-mini is ~500k file size and RAM consumer.
>> It would be beneficial to take wpa_supplicant out of the equation if
>> at all possible.
>>
What is mandatory are unicast frames during joining phase, maybe you can
develop an userspace daemon for this purpose
>> Joe
Regards,
Lorenzo
From 72f4ba6f6b6021fcc48d07d03407c2fdb16a46c5 Mon Sep 17 00:00:00 2001
Message-Id: <72f4ba6f6b6021fcc48d07d03407c2fdb16a46c5.1554035972.git.lore...@kernel.org>
In-Reply-To:
References:
From: Lorenzo Bianconi
Date: Sun, 31 Mar 2019 14:38:49 +0200
Subject: [PATCH] ath: dynack: set max timeout according to clockrate
Signed-off-by: Lorenzo Bianconi
---
drivers/net/wireless/ath/ath9k/dynack.c | 36 ++---
1 file changed, 26 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/dynack.c b/drivers/net/wireless/ath/ath9k/dynack.c
index f112fa5b2eac..0627111249dd 100644
--- a/drivers/net/wireless/ath/ath9k/dynack.c
+++ b/drivers/net/wireless/ath/ath9k/dynack.c
@@ -2
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
> On Tue, Mar 5, 2019 at 1:54 AM Lorenzo Bianconi > wrote: > > > > > On Mon, Mar 4, 2019 at 10:31 AM Lorenzo Bianconi > > > wrote: > > > > > > > > > On Mon, Mar 4, 2019 at 1:07 AM Lorenzo Bianconi > > > > > wrote: > > > > > > > > > > > > > Lorenzo,I've pulled out all patches related to extended ham > > > > > > > radio > > > > > > > channels and ath9k is same out of openwrt 18.06.2.I replaced > > > > > > > wpad-mini > > > > > > > with the full version and "option encryption psk2". In testing > > > > > > > between a > > > > > > > mickrotik QRT5 and LHG5 about 10m apart (roof to office), ack_to > > > > > > > will > > > > > > > float up to ~200, then settle down to ~55 -- seems about right. > > > > > > > However, > > > > > > > I do not see any late ack messages in the debug logging. > > > > > > > Shouldn't I be > > > > > > > seeing late acks? I can send full debug data on both sides of > > > > > > > the fence. > > > > > > > Is there anything that doesn't sound right in my setup? I > > > > > > > wanted to do > > > > > > > one more clean test to capture logs. > > > > > > > > > > > > Hi Joe, > > > > > > > > > > > > this is the expected behavior since 'late acks' are triggered just > > > > > > when the real > > > > > > ack-timeout is higher than the initial default value (64us IIRC). > > > > > > In other > > > > > > words 'late acks' are necessary just on pretty long links > > > > > > > > > > > > Regards, > > > > > > Lorenzo > > > > > > > > > > > > > > Hi Joe, > > > > > > > > please keep the ml in cc > > > > > > > > > > > > > > Intuitively, aren't 'late acks' expected regardless of the distance? > > > > > Is there yet another data point for the algorithm to oscillate in to > > > > > an optimal ack_to setting? For a mobile use case, with increasing > > > > > distance apart, there'd need to be a 'late ack' equivalent to trigger > > > > > increasing values? I'm fundamentally trying to understand if any > > > > > there are any limitations to be aware of when applying dynack - > > > > > mobile/fixed short/long distances, P2P/MP2P/P2MP/MP2MP. > > > > > > > > 'late ack' means that we received an ack for a packet where ack-timeout > > > > is already > > > > expired since the configured timeout was too low for the real distance. > > > > If the real ack-timeout is less than the configured initial value (64us > > > > --> ~ 10Km), > > > > it is expected to not detected any 'late acks'. In this scenario the > > > > ack timeout > > > > should just converge to a good value. > > > > If the real distance is grater than 10km we have to dump the > > > > ack-timeout in order > > > > to grab the station and estimate the real timeout (we need to dump the > > > > ack-timeout since the estimation is done through data-ack > > > > transmissions). > > > > Are we on the same page? > > > > > > > > Regards, > > > > Lorenzo > > > > > > > > > > Thanks for taking the time to get to this detail. > > > > > > Still a little fuzzy on what packets are in scope. When not late ack > > > state: xmit a 'packet' and expect an ack in return -- all data > > > 'packets' regardless if using wpa_supplicant or not? estimate and > > > update ack_to > > > > > > "in order to grab the station and estimate the real timeout" > > > Context is in a late ack state, all the acks are late "done through > > > data-ack transmissions". Thus what does it mean to "grab the station > > > and estimate" -- is this the dependency to wpa_supplicant and turning > > > to measuring the handshaking packets generated by wpa_supplicant? > > > And if I understand correctly, this state can only occur if the intial > > > ack_to is shorter than physical distance. If initial ack_to is > > &
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
> On Mon, Mar 4, 2019 at 10:31 AM Lorenzo Bianconi > wrote: > > > > > On Mon, Mar 4, 2019 at 1:07 AM Lorenzo Bianconi > > > wrote: > > > > > > > > > Lorenzo,I've pulled out all patches related to extended ham radio > > > > > channels and ath9k is same out of openwrt 18.06.2.I replaced > > > > > wpad-mini > > > > > with the full version and "option encryption psk2". In testing > > > > > between a > > > > > mickrotik QRT5 and LHG5 about 10m apart (roof to office), ack_to will > > > > > float up to ~200, then settle down to ~55 -- seems about right. > > > > > However, > > > > > I do not see any late ack messages in the debug logging. > > > > > Shouldn't I be > > > > > seeing late acks? I can send full debug data on both sides of the > > > > > fence. > > > > > Is there anything that doesn't sound right in my setup? I wanted to > > > > > do > > > > > one more clean test to capture logs. > > > > > > > > Hi Joe, > > > > > > > > this is the expected behavior since 'late acks' are triggered just when > > > > the real > > > > ack-timeout is higher than the initial default value (64us IIRC). In > > > > other > > > > words 'late acks' are necessary just on pretty long links > > > > > > > > Regards, > > > > Lorenzo > > > > > > > > Hi Joe, > > > > please keep the ml in cc > > > > > > > > Intuitively, aren't 'late acks' expected regardless of the distance? > > > Is there yet another data point for the algorithm to oscillate in to > > > an optimal ack_to setting? For a mobile use case, with increasing > > > distance apart, there'd need to be a 'late ack' equivalent to trigger > > > increasing values? I'm fundamentally trying to understand if any > > > there are any limitations to be aware of when applying dynack - > > > mobile/fixed short/long distances, P2P/MP2P/P2MP/MP2MP. > > > > 'late ack' means that we received an ack for a packet where ack-timeout is > > already > > expired since the configured timeout was too low for the real distance. > > If the real ack-timeout is less than the configured initial value (64us --> > > ~ 10Km), > > it is expected to not detected any 'late acks'. In this scenario the ack > > timeout > > should just converge to a good value. > > If the real distance is grater than 10km we have to dump the ack-timeout in > > order > > to grab the station and estimate the real timeout (we need to dump the > > ack-timeout since the estimation is done through data-ack transmissions). > > Are we on the same page? > > > > Regards, > > Lorenzo > > > > Thanks for taking the time to get to this detail. > > Still a little fuzzy on what packets are in scope. When not late ack > state: xmit a 'packet' and expect an ack in return -- all data > 'packets' regardless if using wpa_supplicant or not? estimate and > update ack_to > > "in order to grab the station and estimate the real timeout" > Context is in a late ack state, all the acks are late "done through > data-ack transmissions". Thus what does it mean to "grab the station > and estimate" -- is this the dependency to wpa_supplicant and turning > to measuring the handshaking packets generated by wpa_supplicant? > And if I understand correctly, this state can only occur if the intial > ack_to is shorter than physical distance. If initial ack_to is > greater than physical, then we never get into this state. the main idea behind dynack is to measure the delta time between packet transmission and the corresponding ack reception (~ 2 * acktimeout). To do so we need to correlate the ack with the relative data packet. This is easy if the already configured acktimeout is higher than the station distance since the related ack will arrive before the timeout expiration time. If the station distance is higher than the current acktimeout we need to know that a new station is connecting to the network since we need to dump the acktimeout in order to start estimating its distance. This is done through association/authentication packets and AFAIK they are not sent in IBSS mode if we do not run wpa_supplicant. Regards, Lorenzo > > Initial value is > /* ackto = slottime + sifs + air delay */ > u32 ackto = 9 + 16 + 64; > > In comparison, I see a static distance to ack_to relationship as: > > ack_to = (distance in meters) / 151.51515151 + 64 > > A static setting is never below 64, but with dynack, I've observed > down to 55 at 10m real distance. I assume this isn't significant to > be concerned about. > > Joe > > > > > > > BTW, here's a ~77km long distance link that recently came online in > > > Alaska in 3GHz: > > > https://www.arednmesh.org/content/site-summit-yetna-linkThese > > > devices are 5GHz motherboards with -2GHz down-converters. > > > > > > Joe 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] ath9k: fix dynack in IBSS mode
> On Mon, Mar 4, 2019 at 1:07 AM Lorenzo Bianconi > wrote: > > > > > Lorenzo,I've pulled out all patches related to extended ham radio > > > channels and ath9k is same out of openwrt 18.06.2.I replaced wpad-mini > > > with the full version and "option encryption psk2". In testing between > > > a > > > mickrotik QRT5 and LHG5 about 10m apart (roof to office), ack_to will > > > float up to ~200, then settle down to ~55 -- seems about right. However, > > > I do not see any late ack messages in the debug logging. Shouldn't I > > > be > > > seeing late acks? I can send full debug data on both sides of the fence. > > > Is there anything that doesn't sound right in my setup? I wanted to do > > > one more clean test to capture logs. > > > > Hi Joe, > > > > this is the expected behavior since 'late acks' are triggered just when the > > real > > ack-timeout is higher than the initial default value (64us IIRC). In other > > words 'late acks' are necessary just on pretty long links > > > > Regards, > > Lorenzo > > Hi Joe, please keep the ml in cc > > Intuitively, aren't 'late acks' expected regardless of the distance? > Is there yet another data point for the algorithm to oscillate in to > an optimal ack_to setting? For a mobile use case, with increasing > distance apart, there'd need to be a 'late ack' equivalent to trigger > increasing values? I'm fundamentally trying to understand if any > there are any limitations to be aware of when applying dynack - > mobile/fixed short/long distances, P2P/MP2P/P2MP/MP2MP. 'late ack' means that we received an ack for a packet where ack-timeout is already expired since the configured timeout was too low for the real distance. If the real ack-timeout is less than the configured initial value (64us --> ~ 10Km), it is expected to not detected any 'late acks'. In this scenario the ack timeout should just converge to a good value. If the real distance is grater than 10km we have to dump the ack-timeout in order to grab the station and estimate the real timeout (we need to dump the ack-timeout since the estimation is done through data-ack transmissions). Are we on the same page? Regards, Lorenzo > > BTW, here's a ~77km long distance link that recently came online in > Alaska in 3GHz: > https://www.arednmesh.org/content/site-summit-yetna-linkThese > devices are 5GHz motherboards with -2GHz down-converters. > > Joe 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] ath9k: fix dynack in IBSS mode
> Lorenzo,I've pulled out all patches related to extended ham radio > channels and ath9k is same out of openwrt 18.06.2.I replaced wpad-mini > with the full version and "option encryption psk2". In testing between a > mickrotik QRT5 and LHG5 about 10m apart (roof to office), ack_to will > float up to ~200, then settle down to ~55 -- seems about right. However, > I do not see any late ack messages in the debug logging. Shouldn't I be > seeing late acks? I can send full debug data on both sides of the fence. > Is there anything that doesn't sound right in my setup? I wanted to do > one more clean test to capture logs. Hi Joe, this is the expected behavior since 'late acks' are triggered just when the real ack-timeout is higher than the initial default value (64us IIRC). In other words 'late acks' are necessary just on pretty long links Regards, Lorenzo > > It shouldn't matter on wpad-mini or wpad, correct? The size went from > ~500k to 727k, ouch. > > Joe > > On Thu, Feb 28, 2019 at 8:48 AM Lorenzo Bianconi < > lorenzo.bianc...@redhat.com> wrote: > > > > On Thu, Feb 28, 2019 at 1:59 AM Koen Vandeputte > > > wrote: > > > > > > > > > > > > On 27.02.19 08:13, Lorenzo Bianconi wrote: > > > > >> > > > > > What I mean is just a p2p link running in AP-STA mode, I guess there > > is no > > > > > difference for users. Am I missing something? > > > > > > > > > > > The design of the out-of-box firmware for AREDN, there are many end > > > users that do not have IT skill set to change these settings at > > > /etc/config level. Although, we could create high level UI setting > > > options. The firmware is packaged so a "node" can boot live and will > > > simply work extending the network with no previous coordination of > > > config settings -- it can be in any logical network position: P2P, > > > P2MP, MP2P, MP2MP.Adding such a setting of this network position > > > could be a fallback option to consider, but not desirable. > > > > > > > >> Is dynack going to receive the late acks if I manage to run > > > > >> wpa_supplicant (wpad-mini?) in plaintext or key_mgmt=NONE mode? > > > > > What we really needs are authentication packets to trigger 'late > > acks' > > > > > in ibss mode. I think wpa_supplicant in plaintext is enough but I am > > not > > > > > 100% sure. > > > > > @Koen: could you please confirm it? > > > > > > > > Will try to test it asap. > > > > > > > > Regards, > > > > > > > > Koen > > > > > > > > > > I'm also working to test, but may not be for several days. > > > wpa_supplicant would be required on both ends? dynack is dependent on > > > ack's generated by wpa_supplicant? This is an upgrade issue of > > > people using old and and new versions of the firmware at the same time > > > across a larger network. > > > > Yes, you need it on both ends since late acks are detected on > > authentication > > messages in ibss mode and ack timeout estimation is done independently on > > each side. > > Could you please just try it on a single 50km link in order to double > > check if it > > works properly? > > > > Regards, > > Lorenzo > > > > > > > > Joe AE6XE > > 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] ath9k: fix dynack in IBSS mode
> On Thu, Feb 28, 2019 at 1:59 AM Koen Vandeputte > wrote: > > > > > > On 27.02.19 08:13, Lorenzo Bianconi wrote: > > >> > > > What I mean is just a p2p link running in AP-STA mode, I guess there is no > > > difference for users. Am I missing something? > > > > > The design of the out-of-box firmware for AREDN, there are many end > users that do not have IT skill set to change these settings at > /etc/config level. Although, we could create high level UI setting > options. The firmware is packaged so a "node" can boot live and will > simply work extending the network with no previous coordination of > config settings -- it can be in any logical network position: P2P, > P2MP, MP2P, MP2MP.Adding such a setting of this network position > could be a fallback option to consider, but not desirable. > > > >> Is dynack going to receive the late acks if I manage to run > > >> wpa_supplicant (wpad-mini?) in plaintext or key_mgmt=NONE mode? > > > What we really needs are authentication packets to trigger 'late acks' > > > in ibss mode. I think wpa_supplicant in plaintext is enough but I am not > > > 100% sure. > > > @Koen: could you please confirm it? > > > > Will try to test it asap. > > > > Regards, > > > > Koen > > > > I'm also working to test, but may not be for several days. > wpa_supplicant would be required on both ends? dynack is dependent on > ack's generated by wpa_supplicant? This is an upgrade issue of > people using old and and new versions of the firmware at the same time > across a larger network. Yes, you need it on both ends since late acks are detected on authentication messages in ibss mode and ack timeout estimation is done independently on each side. Could you please just try it on a single 50km link in order to double check if it works properly? Regards, Lorenzo > > Joe AE6XE 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] ath9k: fix dynack in IBSS mode
> On Tue, Feb 26, 2019 at 1:57 PM Lorenzo Bianconi > wrote: > > > > > On Tue, Feb 26, 2019 at 2:04 AM Lorenzo Bianconi > > > wrote: > > > > > > > > > > > > > > On 26.02.19 06:28, Joe Ayers wrote: > > > > > > On Mon, Feb 25, 2019 at 8:42 AM Koen Vandeputte > > > > > > wrote: > > > > > > > > > > > > > > On 25.02.19 17:33, Joe Ayers wrote: > > > > > > > > On Mon, Feb 25, 2019 at 1:56 AM Lorenzo Bianconi > > > > > > > > wrote: > > > > > > > > > > On 24.02.19 21:32, Joe Ayers wrote: > > > > > > > > > Hi Joe, > > > > > > > Hi Joe, > > > > > > > > > > > First of all, thanks for contributing this fix. I've > > > > > > > > > > > incorporated > > > > > > > > > > > into the http://www.arednmesh.org project, just getting > > > > > > > > > > > into our > > > > > > > > > > > nightly builds now. A comment and a couple questions... > > > > > > > > > > > > > > > > > > > > > > The MAX_DELAY was way too short for our community, had to > > > > > > > > > > > increase > > > > > > > > > > > that significantly. We commonly have long distance links > > > > > > > > > > > over 50km. > > > > > > > > > according to ath9k max configurable value in AR_TIME_OUT for > > > > > > > > > acktimeout > > > > > > > > > is 0x3fff. The max ack_to we can configure (assuming > > > > > > > > > clockrate set to > > > > > > > > > ATH9K_CLOCK_RATE_2GHZ_OFDM) is ~372us (~55km). > > > > > > > > > We can try to set MAX_DELAY to 360 (max distance ~54km). If > > > > > > > > > you confirm it > > > > > > > > > works properly I can post a patch (or you can take care of > > > > > > > > > it, up to you) > > > > > > > > > > > > > > > > > I have a current link in Southern California with settings of: > > > > > > > > > > > > > > > > distance 6m ( "463 S" ) > > > > > > > > channel width = 10MHz > > > > > > > > channel = 176 (5880) Amateur Radio licensing > > > > > > > > Ubiquiti Rocket M w/ RocketDish > > > > > > > > xmit power 27dBm > > > > > > > > > > > > > > > > It is rock solid and streams multiple HD videos and voip calls > > > > > > > > (without drop outs in the call) achieving 30db SNR and MCS15 > > > > > > > > rates. > > > > > > > > It's been live for a couple years in this mode. I don't > > > > > > > > understand > > > > > > > > how this link could operate with the performance we see if the > > > > > > > > ack_to > > > > > > > > max was 372 -- the voip quality would be terrible. > > > > > > > > > > > > > > > > I have tested (limited tests) dynack on a link showing upwards > > > > > > > > of > > > > > > > > ~"400 A", but the real distance to farthest node was about > > > > > > > > ~20km. > > > > > > > > Was wondering the discrepancy (fading, etc.?)? I had changed > > > > > > > > the > > > > > > > > starting point to 20km to work, otherwise it was stuck on the > > > > > > > > original > > > > > > > > starting point, "96 A", and didn't move. > > > > > > > > > > > > > > > > I just loaded dynack on this 60km link and it doesn't move from > > > > > > > > my new > > > > > > > > starting point of "196 A". Something in the calculation > > > > > > > > somewhere > > > > > > > > goes out of bound--to big a jump? I'll do some testing to get > > > > > > > > the > > > > > > > > dynack working on this 60km link, then lets see w
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
> On Tue, Feb 26, 2019 at 2:04 AM Lorenzo Bianconi > wrote: > > > > > > > > On 26.02.19 06:28, Joe Ayers wrote: > > > > On Mon, Feb 25, 2019 at 8:42 AM Koen Vandeputte > > > > wrote: > > > > > > > > > > On 25.02.19 17:33, Joe Ayers wrote: > > > > > > On Mon, Feb 25, 2019 at 1:56 AM Lorenzo Bianconi > > > > > > wrote: > > > > > > > > On 24.02.19 21:32, Joe Ayers wrote: > > > > > > > Hi Joe, > > > > > Hi Joe, > > > > > > > > > First of all, thanks for contributing this fix. I've > > > > > > > > > incorporated > > > > > > > > > into the http://www.arednmesh.org project, just getting into > > > > > > > > > our > > > > > > > > > nightly builds now. A comment and a couple questions... > > > > > > > > > > > > > > > > > > The MAX_DELAY was way too short for our community, had to > > > > > > > > > increase > > > > > > > > > that significantly. We commonly have long distance links > > > > > > > > > over 50km. > > > > > > > according to ath9k max configurable value in AR_TIME_OUT for > > > > > > > acktimeout > > > > > > > is 0x3fff. The max ack_to we can configure (assuming clockrate > > > > > > > set to > > > > > > > ATH9K_CLOCK_RATE_2GHZ_OFDM) is ~372us (~55km). > > > > > > > We can try to set MAX_DELAY to 360 (max distance ~54km). If you > > > > > > > confirm it > > > > > > > works properly I can post a patch (or you can take care of it, up > > > > > > > to you) > > > > > > > > > > > > > I have a current link in Southern California with settings of: > > > > > > > > > > > > distance 6m ( "463 S" ) > > > > > > channel width = 10MHz > > > > > > channel = 176 (5880) Amateur Radio licensing > > > > > > Ubiquiti Rocket M w/ RocketDish > > > > > > xmit power 27dBm > > > > > > > > > > > > It is rock solid and streams multiple HD videos and voip calls > > > > > > (without drop outs in the call) achieving 30db SNR and MCS15 rates. > > > > > > It's been live for a couple years in this mode. I don't understand > > > > > > how this link could operate with the performance we see if the > > > > > > ack_to > > > > > > max was 372 -- the voip quality would be terrible. > > > > > > > > > > > > I have tested (limited tests) dynack on a link showing upwards of > > > > > > ~"400 A", but the real distance to farthest node was about ~20km. > > > > > > Was wondering the discrepancy (fading, etc.?)? I had changed the > > > > > > starting point to 20km to work, otherwise it was stuck on the > > > > > > original > > > > > > starting point, "96 A", and didn't move. > > > > > > > > > > > > I just loaded dynack on this 60km link and it doesn't move from my > > > > > > new > > > > > > starting point of "196 A". Something in the calculation somewhere > > > > > > goes out of bound--to big a jump? I'll do some testing to get the > > > > > > dynack working on this 60km link, then lets see what it tunes to. > > > > > > Based on my earlier results, I'm wondering if it will push past 500. > > > > > > Maybe the vendor specs are only to the limit of what was tested, > > > > > > does not appear to be a true physical limit? > > > > > Could you add some debug logs from Dynack? > > > > > > > > > Debug logs test case 1 -- Ubiquiti LHG5 <8km to Rocket M5: > > > > https://drive.google.com/file/d/1PYXzjbq1DUIxdZxMm1W7g_0k5hpkKi4z/view?usp=sharing > > > > > > > > Debug log test case 2 -- Ubiquiti Rocket M5 ~60km link to another > > > > Rocket M5: > > > > https://drive.google.com/file/d/16DQSkEm0zcDCQHKuxOjM2yXlTp1QYYiE/view?usp=sharing > > > > > > > > Test case 3 (no debug data) -- Ubiquiti NanoStation link to another > > > > tower at 7.68km distance > >
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
> > On 26.02.19 06:28, Joe Ayers wrote: > > On Mon, Feb 25, 2019 at 8:42 AM Koen Vandeputte > > wrote: > > > > > > On 25.02.19 17:33, Joe Ayers wrote: > > > > On Mon, Feb 25, 2019 at 1:56 AM Lorenzo Bianconi > > > > wrote: > > > > > > On 24.02.19 21:32, Joe Ayers wrote: > > > > > Hi Joe, > > > Hi Joe, > > > > > > > First of all, thanks for contributing this fix. I've > > > > > > > incorporated > > > > > > > into the http://www.arednmesh.org project, just getting into our > > > > > > > nightly builds now. A comment and a couple questions... > > > > > > > > > > > > > > The MAX_DELAY was way too short for our community, had to increase > > > > > > > that significantly. We commonly have long distance links over > > > > > > > 50km. > > > > > according to ath9k max configurable value in AR_TIME_OUT for > > > > > acktimeout > > > > > is 0x3fff. The max ack_to we can configure (assuming clockrate set to > > > > > ATH9K_CLOCK_RATE_2GHZ_OFDM) is ~372us (~55km). > > > > > We can try to set MAX_DELAY to 360 (max distance ~54km). If you > > > > > confirm it > > > > > works properly I can post a patch (or you can take care of it, up to > > > > > you) > > > > > > > > > I have a current link in Southern California with settings of: > > > > > > > > distance 6m ( "463 S" ) > > > > channel width = 10MHz > > > > channel = 176 (5880) Amateur Radio licensing > > > > Ubiquiti Rocket M w/ RocketDish > > > > xmit power 27dBm > > > > > > > > It is rock solid and streams multiple HD videos and voip calls > > > > (without drop outs in the call) achieving 30db SNR and MCS15 rates. > > > > It's been live for a couple years in this mode. I don't understand > > > > how this link could operate with the performance we see if the ack_to > > > > max was 372 -- the voip quality would be terrible. > > > > > > > > I have tested (limited tests) dynack on a link showing upwards of > > > > ~"400 A", but the real distance to farthest node was about ~20km. > > > > Was wondering the discrepancy (fading, etc.?)? I had changed the > > > > starting point to 20km to work, otherwise it was stuck on the original > > > > starting point, "96 A", and didn't move. > > > > > > > > I just loaded dynack on this 60km link and it doesn't move from my new > > > > starting point of "196 A". Something in the calculation somewhere > > > > goes out of bound--to big a jump? I'll do some testing to get the > > > > dynack working on this 60km link, then lets see what it tunes to. > > > > Based on my earlier results, I'm wondering if it will push past 500. > > > > Maybe the vendor specs are only to the limit of what was tested, > > > > does not appear to be a true physical limit? > > > Could you add some debug logs from Dynack? > > > > > Debug logs test case 1 -- Ubiquiti LHG5 <8km to Rocket M5: > > https://drive.google.com/file/d/1PYXzjbq1DUIxdZxMm1W7g_0k5hpkKi4z/view?usp=sharing > > > > Debug log test case 2 -- Ubiquiti Rocket M5 ~60km link to another Rocket M5: > > https://drive.google.com/file/d/16DQSkEm0zcDCQHKuxOjM2yXlTp1QYYiE/view?usp=sharing > > > > Test case 3 (no debug data) -- Ubiquiti NanoStation link to another > > tower at 7.68km distance > > > > Note: test case 1, the auto distance is much higher than actual > > (static set about 8km). > > test case 2, the auto distance does not change from initial > > value, although I raised MAX_DELAY sufficiently high enough. What > > dynack.c initial variable conditions would you recommend? > > test case 3, normally set as "115 S". dynack floated from > > 196 to 344, then back to 197 A when manually monitoring the ack_to > > value in debugfs. I've seen this behavior on 3 links now. > > > > Joe AE6XE > > Hi Joe, > > In the "long" log, I'm seeing that dynack is not synced. > I'm also not seeing any late ack's coming in. > > The "Short" log looks OK and is what you should see on proper syncing. > > > Could you try following on the long link? (if possible) > > - Ensure dynack gets enabled
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
> > On 24.02.19 21:32, Joe Ayers wrote: Hi Joe, > > First of all, thanks for contributing this fix. I've incorporated > > into the http://www.arednmesh.org project, just getting into our > > nightly builds now. A comment and a couple questions... > > > > The MAX_DELAY was way too short for our community, had to increase > > that significantly. We commonly have long distance links over 50km. according to ath9k max configurable value in AR_TIME_OUT for acktimeout is 0x3fff. The max ack_to we can configure (assuming clockrate set to ATH9K_CLOCK_RATE_2GHZ_OFDM) is ~372us (~55km). We can try to set MAX_DELAY to 360 (max distance ~54km). If you confirm it works properly I can post a patch (or you can take care of it, up to you) > > > > One of our common scenarios is a P2MP -- tower or cell site with > > multiple clients. We're using adhoc mode with OLSR. I see the ack_to > > calculation is based on the furthest station. What happens when the > > furthest station is quiet for long periods of time, nothing but > > beacons and olsr 'broadcast' traffic. In this case, there wouldn't > > be any acks received back? Would it drop out of the ack_to > > calculation, until user data is active? Thus, distance would tune to > > a shorter distance for another STA with user data being transferred? > > What is the behavior in this scenario? nope, we always take into account furthest station (even if it does not tx any data frame) otherwise it will be kicked out (we need to wait it leaves the network) Regards, Lorenzo > > > > I made a small change so that '0' in /etc/config/wireless distance > > setting ended up being auto for ath9k. Did I miss an upstream patch > > to incorporate? > > > > Regards, > > Joe AE6XE > > > Hi Lorenzo, > > Ensuring that Joe gets the best possible answer, could you please reply on > above comments/questions? > > > Highly appreciated, > > Koen > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2] ramips: add mt76x0 node to RT-AC51U device tree
From: Lorenzo Bianconi
Introduce mt76x0e device tree node in RT-AC51U dts.
Define mt76x0e mtd partition and offset
Signed-off-by: Lorenzo Bianconi
---
Changes since v1:
- fix mt76 device tree node name
---
target/linux/ramips/dts/RT-AC51U.dts | 11 +++
1 file changed, 11 insertions(+)
diff --git a/target/linux/ramips/dts/RT-AC51U.dts
b/target/linux/ramips/dts/RT-AC51U.dts
index 6bed8446e5..683f17bb75 100644
--- a/target/linux/ramips/dts/RT-AC51U.dts
+++ b/target/linux/ramips/dts/RT-AC51U.dts
@@ -135,3 +135,14 @@
};
};
};
+
+ {
+ status = "okay";
+};
+
+ {
+ wifi@0,0 {
+ reg = <0x 0 0 0 0>;
+ mediatek,mtd-eeprom = < 0x8000>;
+ };
+};
--
2.19.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ramips: add mt76x0 node to RT-AC51U device tree
> Hi Lorenzo,
>
> thank you for your work on the mt76 drivers!
>
> On Mon, Oct 29, 2018 at 11:31 PM Lorenzo Bianconi
> wrote:
> >
> > Introduce mt76x0e device tree node in RT-AC51U dts.
> > Define mt76x0e mtd partition and offset
> >
> > Signed-off-by: Lorenzo Bianconi
> > ---
> > target/linux/ramips/dts/RT-AC51U.dts | 11 +++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/target/linux/ramips/dts/RT-AC51U.dts
> > b/target/linux/ramips/dts/RT-AC51U.dts
> > index 6bed8446e5..f6cc36b719 100644
> > --- a/target/linux/ramips/dts/RT-AC51U.dts
> > +++ b/target/linux/ramips/dts/RT-AC51U.dts
> > @@ -135,3 +135,14 @@
> > };
> > };
> > };
> > +
> > + {
> > + status = "okay";
> > +};
> > +
> > + {
> > + mt76@0,0 {
> this should be wifi@0,0 because node-names are supposed to represent
> the device type, not a specific "implementation"
> quote from [0]: "A node for a 3com Ethernet adapter would be use the
> name ethernet, not 3com509."
Hi Martin,
thx for the review. I will fix it in v2.
Regards,
Lorenzo
>
> > + reg = <0x 0 0 0 0>;
> > + mediatek,mtd-eeprom = < 0x8000>;
> > + };
> > +};
> > --
> > 2.19.1
> >
> >
> > ___
> > openwrt-devel mailing list
> > openwrt-devel@lists.openwrt.org
> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
> [0] https://elinux.org/Device_Tree_Usage#Node_Names
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ramips: add mt76x0 node to RT-AC51U device tree
Introduce mt76x0e device tree node in RT-AC51U dts.
Define mt76x0e mtd partition and offset
Signed-off-by: Lorenzo Bianconi
---
target/linux/ramips/dts/RT-AC51U.dts | 11 +++
1 file changed, 11 insertions(+)
diff --git a/target/linux/ramips/dts/RT-AC51U.dts
b/target/linux/ramips/dts/RT-AC51U.dts
index 6bed8446e5..f6cc36b719 100644
--- a/target/linux/ramips/dts/RT-AC51U.dts
+++ b/target/linux/ramips/dts/RT-AC51U.dts
@@ -135,3 +135,14 @@
};
};
};
+
+ {
+ status = "okay";
+};
+
+ {
+ mt76@0,0 {
+ reg = <0x 0 0 0 0>;
+ mediatek,mtd-eeprom = < 0x8000>;
+ };
+};
--
2.19.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ramips: fix WSR-1166 partition table
- Fix typo in board_data partition start address
- Increase board_data partition size in order to exploit all flash size
Signed-off-by: Lorenzo Bianconi <lorenzo.biancon...@gmail.com>
---
target/linux/ramips/dts/WSR-1166.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/target/linux/ramips/dts/WSR-1166.dts
b/target/linux/ramips/dts/WSR-1166.dts
index d1e3ef9..9743cee 100644
--- a/target/linux/ramips/dts/WSR-1166.dts
+++ b/target/linux/ramips/dts/WSR-1166.dts
@@ -50,9 +50,9 @@
reg = <0x5 0xf9>;
};
- partition@fe0 {
+ partition@fe {
label = "board_data";
- reg = <0xfe 0x1>;
+ reg = <0xfe 0x2>;
};
};
};
--
2.5.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ramips: fix typo in WHR1166D mtd size variable
Fix typo in WHR1166D mtd size variable Signed-off-by: Lorenzo Bianconi lorenzo.biancon...@gmail.com --- target/linux/ramips/image/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/ramips/image/Makefile b/target/linux/ramips/image/Makefile index 776920b..0c28216 100644 --- a/target/linux/ramips/image/Makefile +++ b/target/linux/ramips/image/Makefile @@ -859,7 +859,7 @@ whr_300hp2_mtd_size=7012352 Image/Build/Profile/WHR300HP2=$(call BuildFirmware/CustomFlash/$(1),$(1),whr-300hp2,WHR-300HP2,$(whr_300hp2_mtd_size)) Image/Build/Profile/WHR600D=$(call BuildFirmware/CustomFlash/$(1),$(1),whr-600d,WHR-600D,$(whr_300hp2_mtd_size)) whr_1166d_mtd_size=15400960 -Image/Build/Profile/WHR1166D=$(call BuildFirmware/CustomFlash/$(1),$(1),whr-1166d,WHR-1166D,$(whr_1166hd_mtd_size)) +Image/Build/Profile/WHR1166D=$(call BuildFirmware/CustomFlash/$(1),$(1),whr-1166d,WHR-1166D,$(whr_1166d_mtd_size)) dlink810l_mtd_size=6881280 Image/Build/Profile/CF-WR800N=$(call BuildFirmware/Default8M/$(1),$(1),cf-wr800n,CF-WR800N) Image/Build/Profile/DIR-810L=$(call BuildFirmware/CustomFlash/$(1),$(1),dir-810l,DIR-810L,$(dlink810l_mtd_size)) -- 2.1.4 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
