Re: Error in Common Ubiquiti Procedures for XM AirMax devices?
On Sun, Nov 7, 2021 at 5:07 PM Joe Ayers wrote: > > Openwrt Github commit notes, Forum posts, and Documentation, refer to: > > "The mtd partitions layout for XM-type devices changed from AirOS v5.5 > to AirOS v5.6. Before installing OpenWrt, downgrade first to AirOS > 5.5." > > reference: https://openwrt.org/toh/ubiquiti/common > > While the documentation is a path to succeed loading openwrt firmware, > this commit fixed the soft-brick issue (soft-brick meaning tftp > recovery with serial cable is possible): > https://github.com/openwrt/openwrt/commit/076d58d3440f382c536ea8874f58b0df23c263bc I went looking and found that this commit is in all releases starting with 17.01.x, but not in v15.05.1 > > It is a key message, that openwrt firmware after this commit, will no > longer soft-brick the device, not communicated. > > The key misunderstanding is around the root cause due to Ubiquiti > tightening up uboot to further check partition sizes. The root cause > was identified as a bad openwrt size definition that older versions of > uboot accepted, without end user awareness. > > The reason I raise this issue is due to users in the > https//www.arednmesh.org community struggling to downgrade to AirOX > v5.5, and we spend time working with them only to do tftp > "hold-reset-button" firmware loads to succeed as quickest path. > > Note, however, there are still issues where newer Uboot versions > expect images to have particular naming conventions, which are also > addressed in later fixes: > > https://github.com/openwrt/openwrt/commit/6009b3fd586a1fd91400074080afb9545c6cf7e2 This one is in releases starting with v19.07.x, but not in v18.06.x and earlier. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 0/3] uqmi: sync libqmi and add more diagnostic commands;
On Mon, Nov 08, 2021 at 08:40:43PM +0200, Oskari Lemmelä wrote: > Thanks. I squashed it to parser commit and dropped json file modification. > > Updated patches are in same upstream branch > https://github.com/olemmela/uqmi.git Please rebase on upstream, I've already merged the series. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 0/3] uqmi: sync libqmi and add more diagnostic commands;
On 8.11.2021 12.47, Koen Vandeputte wrote:
>
> On 08.11.21 09:36, Koen Vandeputte wrote:
>>
>> On 24.10.21 17:05, Oskari Lemmela wrote:
>>> First patch updates dynamic code generator to handle newer data from
>>> libqmi project. After data is synced from libqmi project, more
>>> connection
>>> diagnostic commands are added to uqmi.
>>>
>>> Oskari Lemmela (3):
>>> uqmi: update code generator
>>> uqmi: sync data from libqmi project
>>> uqmi: add more diagnostics commands
>>>
>>> commands-nas.c | 663 +++-
>>> commands-nas.h | 10 +-
>>> commands-uim.c | 8 +-
>>> commands-wda.c | 3 +-
>>> commands-wds.c | 16 +-
>>> commands-wds.h | 2 +-
>>> data/gen-code.pl | 11 +-
>>> data/gen-common.pm | 10 +
>>> data/gen-error-list.pl | 2 +-
>>> data/gen-header.pl | 5 +-
>>> data/qmi-service-ctl.json | 40 +-
>>> data/qmi-service-dms.json | 533 +++---
>>> data/qmi-service-nas.json | 1703 +--
>>> data/qmi-service-oma.json | 52 +-
>>> data/qmi-service-pbm.json | 47 +-
>>> data/qmi-service-pds.json | 104 +-
>>> data/qmi-service-uim.json | 746 ++
>>> data/qmi-service-wda.json | 144 ++-
>>> data/qmi-service-wds.json | 2039
>>> +
>>> data/qmi-service-wms.json | 218 ++--
>>
>> I noticed the JSON files here seem edited compared to upstream to
>> avoid following original compile issue: (variables starting with a
>> number)
>>
There is 5 variables starting with number so I did took short cut and
just renamed them.
https://github.com/olemmela/uqmi/commit/ab6d00ac0f4fa22956f5c1dc9266d89d3ade983e
>>
>> /Tools/QMI/qmi-message-nas.h:820:19: error: invalid suffix
>> "gpp_eons_plmn_name" on integer constant
>> 820 | } 3gpp_eons_plmn_name;
>> | ^~~
>>
>> Maybe the perl scripts could be edited to simply prepend a "_" to
>> these vars to avoid the problem.
>> This would allow to use unmodified upstream json files which is a lot
>> less work to update it in the future.
>>
You are right. Better try keep files as close to upstream ones as
possible. There is still glib related lines
in headers files to be changed after syncing.
https://github.com/olemmela/uqmi/commit/5ee729f571e7ceab54cf33d27ef936a41c576255
https://github.com/olemmela/uqmi/commit/8d95a06037d572b5f31634fa50d4202006d5e8b4
>>
>> Regards,
>>
>> Koen
>>
>
> Patch proposal:
>
>
> diff --git a/data/gen-common.pm b/data/gen-common.pm
> index e951776..278afce 100644
> --- a/data/gen-common.pm
> +++ b/data/gen-common.pm
> @@ -32,6 +32,7 @@ sub gen_cname($) {
> my $name = shift;
>
> $name =~ s/[^a-zA-Z0-9_]/_/g;
> + $name = "_${name}" if $name =~ /^\d/;
> return lc($name);
> }
>
Thanks. I squashed it to parser commit and dropped json file modification.
Updated patches are in same upstream branch
https://github.com/olemmela/uqmi.git
>
> Regards,
>
> Koen
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH V2] bcm47xx: relocate LZMA loader
On 11/7/21 2:45 PM, Rafał Miłecki wrote:
From: Rafał Miłecki
Kernel 5.10 grew bigger than 5.4 so we need to bump BZ_TEXT_START to
allow lzma loader hanel its size.
At the same time BZ_STACK_START needs to be increased to avoid
overwriting the stack.
For a reference see:
d5cf4a5aa4a3 ("brcm47xx: relocate loader to higher address")
2909a4b78e2b ("brcm47xx: relocate the stack in loader")
Cc: Hauke Mehrtens
Signed-off-by: Rafał Miłecki
Acked-by: Hauke Mehrtens
---
target/linux/bcm47xx/image/lzma-loader/src/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/target/linux/bcm47xx/image/lzma-loader/src/Makefile
b/target/linux/bcm47xx/image/lzma-loader/src/Makefile
index a08fc05b9f..a3e7ae1c92 100644
--- a/target/linux/bcm47xx/image/lzma-loader/src/Makefile
+++ b/target/linux/bcm47xx/image/lzma-loader/src/Makefile
@@ -18,8 +18,8 @@
#
TEXT_START := 0x80001000
-BZ_TEXT_START := 0x8060
-BZ_STACK_START := 0x8070
+BZ_TEXT_START := 0x8070
+BZ_STACK_START := 0x8080
OBJCOPY := $(CROSS_COMPILE)objcopy -O binary -R .reginfo -R .note -R .comment -R .mdebug -S
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Error in Common Ubiquiti Procedures for XM AirMax devices?
On 08/11/21 02:04, Joe Ayers wrote: Openwrt Github commit notes, Forum posts, and Documentation, refer to: "The mtd partitions layout for XM-type devices changed from AirOS v5.5 to AirOS v5.6. Before installing OpenWrt, downgrade first to AirOS 5.5." reference: https://openwrt.org/toh/ubiquiti/common While the documentation is a path to succeed loading openwrt firmware, this commit fixed the soft-brick issue (soft-brick meaning tftp recovery with serial cable is possible): https://github.com/openwrt/openwrt/commit/076d58d3440f382c536ea8874f58b0df23c263bc It is a key message, that openwrt firmware after this commit, will no longer soft-brick the device, not communicated. The key misunderstanding is around the root cause due to Ubiquiti tightening up uboot to further check partition sizes. The root cause was identified as a bad openwrt size definition that older versions of uboot accepted, without end user awareness. The reason I raise this issue is due to users in the https//www.arednmesh.org community struggling to downgrade to AirOX v5.5, and we spend time working with them only to do tftp "hold-reset-button" firmware loads to succeed as quickest path. Note, however, there are still issues where newer Uboot versions expect images to have particular naming conventions, which are also addressed in later fixes: https://github.com/openwrt/openwrt/commit/6009b3fd586a1fd91400074080afb9545c6cf7e2 Thus, firmware before this time will not tftp "hold-reset-button" load due to this 2nd issue, but not soft-brick the device. I've not found the time to track down how to contact the relevant stakeholders to address this issue in the documentation, consequently, blasting out in this list in hopes of triggering someone to update the relevant openwrt documentation to add more clarity to the issue. The documentation is a wiki and it can be edited by anyone that has registered an account. If you know enough about these particular devices and want to edit that page to update the information, please contact me (at this email) or tmomas (at tm...@gmx.de) in private to get an account, or go through the forum. See the forum thread here about the "new" manual registration of new accounts in the wiki https://forum.openwrt.org/t/applying-for-openwrt-wiki-account/101671 -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 0/3] uqmi: sync libqmi and add more diagnostic commands;
On 08.11.21 09:36, Koen Vandeputte wrote:
On 24.10.21 17:05, Oskari Lemmela wrote:
First patch updates dynamic code generator to handle newer data from
libqmi project. After data is synced from libqmi project, more
connection
diagnostic commands are added to uqmi.
Oskari Lemmela (3):
uqmi: update code generator
uqmi: sync data from libqmi project
uqmi: add more diagnostics commands
commands-nas.c | 663 +++-
commands-nas.h | 10 +-
commands-uim.c | 8 +-
commands-wda.c | 3 +-
commands-wds.c | 16 +-
commands-wds.h | 2 +-
data/gen-code.pl | 11 +-
data/gen-common.pm | 10 +
data/gen-error-list.pl | 2 +-
data/gen-header.pl | 5 +-
data/qmi-service-ctl.json | 40 +-
data/qmi-service-dms.json | 533 +++---
data/qmi-service-nas.json | 1703 +--
data/qmi-service-oma.json | 52 +-
data/qmi-service-pbm.json | 47 +-
data/qmi-service-pds.json | 104 +-
data/qmi-service-uim.json | 746 ++
data/qmi-service-wda.json | 144 ++-
data/qmi-service-wds.json | 2039 +
data/qmi-service-wms.json | 218 ++--
I noticed the JSON files here seem edited compared to upstream to
avoid following original compile issue: (variables starting with a
number)
/Tools/QMI/qmi-message-nas.h:820:19: error: invalid suffix
"gpp_eons_plmn_name" on integer constant
820 | } 3gpp_eons_plmn_name;
| ^~~
Maybe the perl scripts could be edited to simply prepend a "_" to
these vars to avoid the problem.
This would allow to use unmodified upstream json files which is a lot
less work to update it in the future.
Regards,
Koen
Patch proposal:
diff --git a/data/gen-common.pm b/data/gen-common.pm
index e951776..278afce 100644
--- a/data/gen-common.pm
+++ b/data/gen-common.pm
@@ -32,6 +32,7 @@ sub gen_cname($) {
my $name = shift;
$name =~ s/[^a-zA-Z0-9_]/_/g;
+ $name = "_${name}" if $name =~ /^\d/;
return lc($name);
}
Regards,
Koen
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 0/3] uqmi: sync libqmi and add more diagnostic commands
On 24.10.21 17:05, Oskari Lemmela wrote: First patch updates dynamic code generator to handle newer data from libqmi project. After data is synced from libqmi project, more connection diagnostic commands are added to uqmi. Oskari Lemmela (3): uqmi: update code generator uqmi: sync data from libqmi project uqmi: add more diagnostics commands commands-nas.c| 663 +++- commands-nas.h| 10 +- commands-uim.c|8 +- commands-wda.c|3 +- commands-wds.c| 16 +- commands-wds.h|2 +- data/gen-code.pl | 11 +- data/gen-common.pm| 10 + data/gen-error-list.pl|2 +- data/gen-header.pl|5 +- data/qmi-service-ctl.json | 40 +- data/qmi-service-dms.json | 533 +++--- data/qmi-service-nas.json | 1703 +-- data/qmi-service-oma.json | 52 +- data/qmi-service-pbm.json | 47 +- data/qmi-service-pds.json | 104 +- data/qmi-service-uim.json | 746 ++ data/qmi-service-wda.json | 144 ++- data/qmi-service-wds.json | 2039 + data/qmi-service-wms.json | 218 ++-- I noticed the JSON files here seem edited compared to upstream to avoid following original compile issue: (variables starting with a number) /Tools/QMI/qmi-message-nas.h:820:19: error: invalid suffix "gpp_eons_plmn_name" on integer constant 820 | } 3gpp_eons_plmn_name; | ^~~ Maybe the perl scripts could be edited to simply prepend a "_" to these vars to avoid the problem. This would allow to use unmodified upstream json files which is a lot less work to update it in the future. Regards, Koen ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
