[OpenWrt-Devel] [PATCH] ramips: disable badblock shifting for MT7621 NAND
The MediaTek MT7621 NAND driver currently intransparently shifts NAND
pages when a block is marked as bad. Because of this, offsets for e.g.
caldata and MAC-addresses seem to be off.
This is, howeer, not a task for the mtd NAND driver, as the flash
translation layer is tasked with this.
This patch disables this badblock shifting. This fix was originally
proposed by Jo-Philipp Wich at
https://bugs.openwrt.org/index.php?do=details_id=1926
Fixes FS#1926 ("MTD partition offset not correctly mapped when bad
eraseblocks present")
Signed-off-by: David Bauer
---
.../ramips/patches-4.14/0039-mtd-add-mt7621-nand-support.patch | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/target/linux/ramips/patches-4.14/0039-mtd-add-mt7621-nand-support.patch
b/target/linux/ramips/patches-4.14/0039-mtd-add-mt7621-nand-support.patch
index d50e689110..03b2b36db9 100644
--- a/target/linux/ramips/patches-4.14/0039-mtd-add-mt7621-nand-support.patch
+++ b/target/linux/ramips/patches-4.14/0039-mtd-add-mt7621-nand-support.patch
@@ -3578,7 +3578,7 @@ Signed-off-by: John Crispin
+ if (!err) {
+ MSG(INIT, "[mtk_nand] probe successfully!\n");
+ nand_disable_clock();
-+ shift_on_bbt = 1;
++ shift_on_bbt = 0;
+ if (load_fact_bbt(mtd) == 0) {
+ int i;
+ for (i = 0; i < 0x100; i++)
--
2.23.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2 1/3] lua: create lua symlink for host installation
Since the binaries for both lua as well as lua5.3 contain the version
number, invocations of the "lua" binary are failing, as it's not created
anymore for the host package.
Fixes: fe59b46 ("lua: include version number in installed files")
Signed-off-by: David Bauer
---
v2:
- drop symlink creation for lua5.3
package/utils/lua/Makefile | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/package/utils/lua/Makefile b/package/utils/lua/Makefile
index a2870448bd..e376e8c472 100644
--- a/package/utils/lua/Makefile
+++ b/package/utils/lua/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
PKG_NAME:=lua
PKG_VERSION:=5.1.5
-PKG_RELEASE:=5
+PKG_RELEASE:=6
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
PKG_SOURCE_URL:=http://www.lua.org/ftp/ \
@@ -133,6 +133,8 @@ define Host/Install
$(MAKE) -C $(HOST_BUILD_DIR) \
INSTALL_TOP="$(STAGING_DIR_HOSTPKG)" \
install
+
+ $(LN) $(STAGING_DIR_HOSTPKG)/bin/lua5.1 $(STAGING_DIR_HOSTPKG)/bin/lua
endef
define Build/InstallDev
--
2.23.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Squashfs breakage lottery with UBI WAS: [PATCH RFC 2/2] amp821xx: use newly added pad-squashfs for Meraki MR24
>> Fwiw, I took a little closer look at the squashfs code. I still don't
>> quite understand it, but I sprinkled some printk()'s and got a better
>> idea of what is happening.
>>
>> With a root.squashfs of 6428672 bytes, we get the error in a call:
>
> Actually, the 6428672 bytes was from a later trial. Sorry for the
> confusion. I'm not sure what the real root.squashfs size was
> anymore. Gah. I'll need to redo it.
Here are the corresponding numbers from the retry:
root.squasfs size (from the sysupgrade.bin tarball): 6427978 bytes
squashfs_read_data(sb=(ptrval),index=0,length=6427970,next_index=16777224,output=(null))
b=0; bytes=-322; length=8; cur_index=0
>>
>>
>> squashfs_read_data(sb=(ptrval),index=0,length=6427986,next_index=16777224,output=
>> (null))
>>
>> it enters the loop at fs/squashfs/block.c:122 with b=0; bytes=-338;
>> length=8; cur_index=0
>>
>> for (b = 0; bytes < length; b++, cur_index++) {
>> bh[b] = sb_getblk(sb, cur_index);
>> if (bh[b] == NULL)
>> goto block_release;
>>
>> sb_getblk() must return NULL, because it goes to block_release and falls
>> through to print the error message and exits with an error.
--
Russell Senior, President
russ...@personaltelco.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
--
Russell Senior, President
russ...@personaltelco.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Squashfs breakage lottery with UBI WAS: [PATCH RFC 2/2] amp821xx: use newly added pad-squashfs for Meraki MR24
> Fwiw, I took a little closer look at the squashfs code. I still don't
> quite understand it, but I sprinkled some printk()'s and got a better
> idea of what is happening.
>
> With a root.squashfs of 6428672 bytes, we get the error in a call:
Actually, the 6428672 bytes was from a later trial. Sorry for the
confusion. I'm not sure what the real root.squashfs size was
anymore. Gah. I'll need to redo it.
>
>
> squashfs_read_data(sb=(ptrval),index=0,length=6427986,next_index=16777224,output=
> (null))
>
> it enters the loop at fs/squashfs/block.c:122 with b=0; bytes=-338; length=8;
> cur_index=0
>
> for (b = 0; bytes < length; b++, cur_index++) {
> bh[b] = sb_getblk(sb, cur_index);
> if (bh[b] == NULL)
> goto block_release;
>
> sb_getblk() must return NULL, because it goes to block_release and falls
> through to print the error message and exits with an error.
--
Russell Senior, President
russ...@personaltelco.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Squashfs breakage lottery with UBI WAS: [PATCH RFC 2/2] amp821xx: use newly added pad-squashfs for Meraki MR24
Fwiw, I took a little closer look at the squashfs code. I still don't
quite understand it, but I sprinkled some printk()'s and got a better
idea of what is happening.
With a root.squashfs of 6428672 bytes, we get the error in a call:
squashfs_read_data(sb=(ptrval),index=0,length=6427986,next_index=16777224,output=
(null))
it enters the loop at fs/squashfs/block.c:122 with b=0; bytes=-338; length=8;
cur_index=0
for (b = 0; bytes < length; b++, cur_index++) {
bh[b] = sb_getblk(sb, cur_index);
if (bh[b] == NULL)
goto block_release;
sb_getblk() must return NULL, because it goes to block_release and falls
through to print the error message and exits with an error.
--
Russell Senior, President
russ...@personaltelco.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [lantiq] help in supporting FRITZ!BOX 3272 (Fritz_Box_HW198))
Thank you very very much guys!! Wow - this seems a big step forward! thank you You're very kind and I apreciated your help very much. Looking at sources NOW! :) :) On Thu, 29 Aug 2019, Lars Melin wrote: Date: Thu, 29 Aug 2019 05:03:27 From: Lars Melin To: Enrico Mioso Subject: Re: [OpenWrt-Devel] [lantiq] help in supporting FRITZ!BOX 3272 (Fritz_Box_HW198)) Hi again, I just found out that Fritzbox 7272 is a 3272 where one USB port has been removed and instead there is an RJ type port for analogue telephony. Otherwise there are no differences between them so if you find resources for 7272 then you should be able to also use them for the 3272. best Lars ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [lantiq] help in supporting FRITZ!BOX 3272 (Fritz_Box_HW198))
On Thu, 29 Aug 2019 at 02:35, Enrico Mioso wrote:
> Dear Bjorn,
> Thank you very very much! You've been always helpful tome... :)
>
> thank you for pointing me at your work - it has been very useful. I was
> using as references sources from the TP-Link Archer D2.
>
> thanks to your hints and work, I arrived to some of the conclusions you
> did. Your device was booting, instead in my case I am not able to get it
> past the PMU issue.
> And even ignoring this error I end up having issues with the GPTU.
>
> I guess the FRITZ!BOX3272 is maybe of another family of devices. don't
> know, running out of ideas.
> Any hint of what I might try next?
> I didn't find GPL code for this device from AVM - but maybe it's just me.
> Any help would be really apreciated.
>
This should be it:
https://osp.avm.de/fritzbox/fritzbox-3272/source-files-FRITZ.Box_3272-06.20.tar.gz
>
> BTW - PMU activation fails in sysctrl.c, in function
> static int pmu_enable(struct clk *clk) ...
>
> Enrico
>
> On Wed, 28 Aug 2019, Bjørn Mork wrote:
>
> > Date: Wed, 28 Aug 2019 18:52:38
> > From: Bjørn Mork
> > To: Enrico Mioso
> > Cc: Martin Blumenstingl ,
> > Hauke Mehrtens , openwrt-devel@lists.openwrt.org
> > Subject: Re: [OpenWrt-Devel] [lantiq] help in supporting FRITZ!BOX 3272
> > (Fritz_Box_HW198))
> >
> > Enrico Mioso writes:
> >
> >> I am still trying to port a FRITZ!BOX3272 device to OpenWRt.
> >> I tried to grab as much informations as I could, but I am arriving to
> the conclusion I hould be doing something really wrong.
> >>
> >> First of all, the kernel panics due to a data abort at
> >> linux-4.19.66/arch/mips/lantiq/xway/sysctrl.c, line 478
> >> /* make sure to unprotect the memory region where flash is located */
> >> ltq_ebu_w32(ltq_ebu_r32(LTQ_EBU_BUSCON0) & ~EBU_WRDIS, LTQ_EBU_BUSCON0);
> > ..
> >> [SYSTEM:] AR10 on 500MHz/250MHz/250MHz
> >>
> >> ..
> >> Eva_AVM >
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> ..[
> 0.00] Linux version 4.19.66 (mrkiko@mStation) (gcc version 7.4.0
> (OpenWrt GCC 7.4.0 r10863-e1dcfe02b2)) #0 SMP Mon Aug 26 16:21:13 2019
> >> [0.00] SoC: xRX300 rev 1.2
> >
> >
> > Right, so this is AR10/xRX300. Been there, trying to get a D-Link
> > DWR-956 running, and gave up without getting the T-Shirt ;-)
> >
> > I believe the problem you are hitting right now is caused by wrong
> > address for the EBU. It is not at 0x1E105300 like for the VR9 etc, but
> > at 0x1600 on the AR10.
> >
> > So change this:
> >
> > ebu0: ebu@e105300 {
> > compatible = "lantiq,ebu-xway";
> > reg = <0xe105300 0x100>;
> > };
> >
> > into
> >
> > ebu0: ebu@600 {
> > compatible = "lantiq,ebu-xway";
> > reg = <0x600 0x100>;
> > };
> >
> >
> > I was stuck the same place for quite some time
> >
> > I pushed my abandoned DWR-956 branch here now:
> > https://github.com/bmork/OpenWrt/tree/dwr-956-wip
> > in case it is of any use to you.
> >
> > Note that this branch is a terrible mess of Work-in-Progress, meant for
> > my eyes only. And even I can't make much sense out of it anymore. So
> > you might be better off just ignoring it. Your call.
> >
> >
> >
> >
> > Bjørn
> >___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode
On 28.08.19 19:34, Joe Ayers wrote: 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 Hi Joe, Purely fyi I just pushed dynack improvements to all openwrt branches. I also noticed the issues you addressed above, and these patches fix them for me. Regards, Koen Thanks for update. Updates on performance observations, I've been recommending usage of auto settings to the AREDN community as follows: * best performance gain on Point-to-Point longer distance links (back bone links). I saw ~30% iperf improvement results on a 60km 5GHz link -- ack-to floats up under load. This was about the difference I measured on a similar 3GHz 60km link head-to-head comparison between AirOS auto distance with TDMA and openwrt static distance with CSMA. (3GHz because it takes wifi noise out of the picture.) I want to do a head-to-head comparison again to confirm, but it appears a P2P w/ auto setting CSMA in openwrt will compare similar thoughput as AirOS auto distance TDMA. * good/poor performance for Point-to-Multipoint long distance settings, up to 20km range (cell coverage). If weak SNR stations, a static setting is optimal. If quality signal, auto works good. Will try to verify this one * Poor performance for short distances, e.g. in the house. auto calculated ack_to settings are several km. Performance is much poorer than a static setting of <1km. Ack on this one. Tested on links ranging from ~500m up to 3.5km static seems to win in terms of performance until the distance goes beyond ~6km here There seems to be something going on with calculation when 'on the bench' testing with short distances. Maybe a bias needs to be applied? I notice that ack_to never drops below 64 on short distance links. (static sets it to 31 on selecting 500m) I wonder if processing delay/time and thread context switching is coming into play here on the slower ar71xx socs Will check it. The main focus of this series was to have working links and avoid breaking existing ones. I think the next round will be regarding these performance "issues" compared to static Koen Joe AE6XE ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH uqmi] nas: add --get-plmn
Martin Schiller writes:
> On 2019-08-26 21:12, Sami Olmari wrote:
>> I think the ideology behind proto handler there is to "do whatever
>> told" despite of what the state is currently,
>> maybe there is a reason for such behaviour (searches some stuff from
>> network etc).
>
> There exist 2 problems in the qmi proto handler:
>
> 1. Setting the plmn to 'auto' will implicitly lead to a (delayed)
> network re-registration, which could further lead to some timing
> related issues in the qmi proto handler.
> Let me explain this in more detail:
> After successfully calling the uqmi --set-plmn (auto) command it takes
> up to 5 (or maybe even more) seconds until the modem detaches from
> network
> and start searching for new registration.
>
> In the meantime the proto handler goes through the next steps
> ("Waiting for
> network registration", "Start network $interface" etc.).
>
> I hope you can see were this leads to.
>
> This is really a problem in Roaming scenarios, where to provider maybe
> is
> switched after the re-registration.
FWIW, I also believe this is a real problem.
The modem firmware isn't always smart. It will "do whatever told", even
if it is a completely unnecessary de-registration, network scan and
re-registration.
We can be smarter than that. We should avoid changing any persistent
(in modem nvram) setting related to network registration, unless
absolutely necessary.
> 2. The plmn setting is permanently saved in the wwan modem:
> This leads to the problem, that if you switch back from manual plmn
> selection
> to auto mode you have to set it explicitly to 'auto'.
Yes, the current handler will use whatever is stored in the modem unless
'plmn' is explictly set. This is very confusing if you set 'plmn'
temporarily, whether it is for roaming or just experimenting. Users will
rightfully assume that adding and then removing 'plmn' means 'no
change'.
Everything in the qmi proto handler should take into account that
settings might be stored in the modem nvram. Optional settings need an
explicit default, and should always be verified against the value stored
in the modem.
I believe the 'plmn' default should be 'auto'. But we can only do that
if we first add the logic to verify the current setting and avoid any
unnecessary 'uqmi --set-plmn' commands.
Bjørn
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH uqmi] nas: add --get-plmn
On 2019-08-26 21:12, Sami Olmari wrote:
I think the ideology behind proto handler there is to "do whatever
told" despite of what the state is currently,
maybe there is a reason for such behaviour (searches some stuff from
network etc).
There exist 2 problems in the qmi proto handler:
1. Setting the plmn to 'auto' will implicitly lead to a (delayed)
network re-registration, which could further lead to some timing
related issues in the qmi proto handler.
Let me explain this in more detail:
After successfully calling the uqmi --set-plmn (auto) command it takes
up to 5 (or maybe even more) seconds until the modem detaches from
network
and start searching for new registration.
In the meantime the proto handler goes through the next steps ("Waiting
for
network registration", "Start network $interface" etc.).
I hope you can see were this leads to.
This is really a problem in Roaming scenarios, where to provider maybe
is
switched after the re-registration.
2. The plmn setting is permanently saved in the wwan modem:
This leads to the problem, that if you switch back from manual plmn
selection
to auto mode you have to set it explicitly to 'auto'.
- Martin
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] umbim: add home provider query support
Ingo Feinerer writes: > This adds support to query the home provider, mainly for debugging and > information purposes. Looks nice to me. Did a simple run test just to confirm that it works as expected with my EM7455 at least: $ ./umbim -p -d /dev/cdc-wdm0 home provider_id: 24201 provider_name: TELENOR cellularclass: 0001 - gsm rssi: 0063 errorrate: 0063 The rssi and errorrate numbers are what my modem returns, but the values do look a little strange in hex... But it is consistent with other umbim output, so I guess it's the least confusing choice. For reference, this is the libmbim output: $ mbimcli -p -d /dev/cdc-wdm0 --query-home-provider [/dev/cdc-wdm0] Home provider: Provider ID: '24201' Provider name: 'TELENOR' State: 'home' Cellular class: 'gsm' RSSI: '99' Error rate: '99' You can add Reviewed-by: Bjørn Mork if that helps. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
