code review request for my submit netifd patch
Hi all Could someone help review the code and leave valuable comments? This is the first time I have submit a patch to openwrt, thank you very much. https://patchwork.ozlabs.org/project/openwrt/patch/2f18ab52-39b5-3546-45c1-10e5357b4...@163.com/ Best Regards Xu Junnan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/3] toolchain/gcc: remove upstreamed patch, add backport
This patch has been upstream since GCC 10. Dragan Mladjenovic (2): Emit .note.GNU-stack for soft-float linux targets. Emit .note.GNU-stack for hard-float linux targets. Link: https://gcc.gnu.org/g:a3c1e1f2ff88 Link: https://gcc.gnu.org/g:54b3d52c3cca Add backport patch to define TARGET_LIBC_GNUSTACK on musl to add .note.GNU-stack on hard-float MIPS targets. Link: https://gcc.gnu.org/g:25abbb924968 The net effect should be the exact same functionality while following upstream code instead of a custom outdated patch. Signed-off-by: Ilya Lipnitskiy --- ...-define-TARGET_LIBC_GNUSTACK-on-musl.patch | 46 .../11.2.0/930-fix-mips-noexecstack.patch | 111 -- 2 files changed, 46 insertions(+), 111 deletions(-) create mode 100644 toolchain/gcc/patches/11.2.0/011-v12-configure-define-TARGET_LIBC_GNUSTACK-on-musl.patch delete mode 100644 toolchain/gcc/patches/11.2.0/930-fix-mips-noexecstack.patch diff --git a/toolchain/gcc/patches/11.2.0/011-v12-configure-define-TARGET_LIBC_GNUSTACK-on-musl.patch b/toolchain/gcc/patches/11.2.0/011-v12-configure-define-TARGET_LIBC_GNUSTACK-on-musl.patch new file mode 100644 index ..94105bdf9f07 --- /dev/null +++ b/toolchain/gcc/patches/11.2.0/011-v12-configure-define-TARGET_LIBC_GNUSTACK-on-musl.patch @@ -0,0 +1,46 @@ +From ea650cae26da4a8fc04f0c4666f4dd776d0b5fc0 Mon Sep 17 00:00:00 2001 +From: Ilya Lipnitskiy +Date: Sun, 14 Nov 2021 21:54:25 -0800 +Subject: [PATCH] configure: define TARGET_LIBC_GNUSTACK on musl + +musl only uses PT_GNU_STACK to set default thread stack size and has no +executable stack support[0], so there is no reason not to emit the +.note.GNU-stack section on musl builds. + +[0]: https://lore.kernel.org/all/20190423192534.gn23...@brightrain.aerifal.cx/T/#u + +gcc/ChangeLog: + + * configure: Regenerate. + * configure.ac: define TARGET_LIBC_GNUSTACK on musl + +Signed-off-by: Ilya Lipnitskiy +--- + gcc/configure| 3 +++ + gcc/configure.ac | 3 +++ + 2 files changed, 6 insertions(+) + +--- a/gcc/configure b/gcc/configure +@@ -30954,6 +30954,9 @@ fi + # Check if the target LIBC handles PT_GNU_STACK. + gcc_cv_libc_gnustack=unknown + case "$target" in ++ mips*-*-linux-musl*) ++gcc_cv_libc_gnustack=yes ++;; + mips*-*-linux*) + + if test $glibc_version_major -gt 2 \ +--- a/gcc/configure.ac b/gcc/configure.ac +@@ -6788,6 +6788,9 @@ fi + # Check if the target LIBC handles PT_GNU_STACK. + gcc_cv_libc_gnustack=unknown + case "$target" in ++ mips*-*-linux-musl*) ++gcc_cv_libc_gnustack=yes ++;; + mips*-*-linux*) + GCC_GLIBC_VERSION_GTE_IFELSE([2], [31], [gcc_cv_libc_gnustack=yes], ) + ;; diff --git a/toolchain/gcc/patches/11.2.0/930-fix-mips-noexecstack.patch b/toolchain/gcc/patches/11.2.0/930-fix-mips-noexecstack.patch deleted file mode 100644 index 591dfe5a5008.. --- a/toolchain/gcc/patches/11.2.0/930-fix-mips-noexecstack.patch +++ /dev/null @@ -1,111 +0,0 @@ -From da45b3fde60095756f5f6030f6012c23a3d34429 Mon Sep 17 00:00:00 2001 -From: Andrew McDonnell -Date: Fri, 3 Oct 2014 19:09:00 +0930 -Subject: Add .note.GNU-stack section - -See http://lists.busybox.net/pipermail/uclibc/2014-October/048671.html -Below copied from https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02430.html - -Re: [Patch, MIPS] Add .note.GNU-stack section - -From: Steve Ellcey - -On Wed, 2014-09-10 at 10:15 -0700, Eric Christopher wrote: -> -> -> On Wed, Sep 10, 2014 at 9:27 AM, wrote: - -> This works except you did not update the assembly files in -> libgcc or glibc. We (Cavium) have the same patch in our tree -> for a few released versions. - -> Mind just checking yours in then Andrew? - -> Thanks! -> -eric - -I talked to Andrew about what files he changed in GCC and created and -tested this new patch. Andrew also mentioned changing some assembly -files in glibc but I don't see any use of '.section .note.GNU-stack' in -any assembly files in glibc (for any platform) so I wasn't planning on -creating a glibc to add them to mips glibc assembly language files. - -OK to check in this patch? - -Steve Ellcey -sell...@mips.com - - - -2014-09-26 Steve Ellcey - gcc/config/mips/mips.c | 3 +++ - libgcc/config/mips/crti.S | 4 - libgcc/config/mips/crtn.S | 3 +++ - libgcc/config/mips/mips16.S | 4 - libgcc/config/mips/vr4120-div.S | 4 - 5 files changed, 18 insertions(+) - a/gcc/config/mips/mips.c -+++ b/gcc/config/mips/mips.c -@@ -22890,6 +22890,9 @@ mips_asm_file_end (void) - #define TARGET_ASM_FILE_END mips_asm_file_end - - -+#undef TARGET_ASM_FILE_END -+#define TARGET_ASM_FILE_END file_end_indicate_exec_stack -+ - struct gcc_target targetm = TARGET_INITIALIZER; - - #include "gt-mips.h" a/libgcc/config/mips/crti.S -+++ b/libgcc/config/mips/crti.S -@@ -24,6 +24,10 @@ see the files COPYING3 and COPYING.RUNTI - /* An executable stack is *not* required for these functions. */ - #include
[PATCH 2/3] toolchain/gcc: replace revert with upstream fix
This will make upgrade to v11.3.0 easier and follows upstream more
closely.
Signed-off-by: Ilya Lipnitskiy
---
...leanup-range-of-address-calculations.patch | 160 --
...ld_using_range-range_of_address-PR10.patch | 114 +
2 files changed, 114 insertions(+), 160 deletions(-)
delete mode 100644
toolchain/gcc/patches/11.2.0/001-Revert-Cleanup-range-of-address-calculations.patch
create mode 100644
toolchain/gcc/patches/11.2.0/001-v11.3.0-ranger-Fix-up-fold_using_range-range_of_address-PR10.patch
diff --git
a/toolchain/gcc/patches/11.2.0/001-Revert-Cleanup-range-of-address-calculations.patch
b/toolchain/gcc/patches/11.2.0/001-Revert-Cleanup-range-of-address-calculations.patch
deleted file mode 100644
index a97e061d6b64..
---
a/toolchain/gcc/patches/11.2.0/001-Revert-Cleanup-range-of-address-calculations.patch
+++ /dev/null
@@ -1,160 +0,0 @@
-From: Felix Fietkau
-Date: Tue, 16 Nov 2021 10:39:51 +0100
-Subject: [PATCH] Revert "Cleanup range of address calculations."
-
-This reverts commit 47923622c663ffad8b14aa93706183290d4f6791.
-This commit is causing issues with offset of struct members.
-
-https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103255
- delete mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr78655.c
-
a/gcc/gimple-range.cc
-+++ b/gcc/gimple-range.cc
-@@ -431,9 +431,8 @@ gimple_ranger::range_of_range_op (irange
- m_cache.register_dependency (lhs, op2);
- }
-
-- if (gimple_code (s) == GIMPLE_ASSIGN
-- && gimple_assign_rhs_code (s) == ADDR_EXPR)
--return range_of_address (r, s);
-+ if (range_of_non_trivial_assignment (r, s))
-+return true;
-
- if (range_of_expr (range1, op1, s))
- {
-@@ -447,84 +446,48 @@ gimple_ranger::range_of_range_op (irange
- return true;
- }
-
--// Calculate the range of an assignment containing an ADDR_EXPR.
-+// Calculate the range of a non-trivial assignment. That is, is one
-+// inolving arithmetic on an SSA name (for example, an ADDR_EXPR).
- // Return the range in R.
--// If a range cannot be calculated, set it to VARYING and return true.
-+//
-+// If a range cannot be calculated, return false.
-
- bool
--gimple_ranger::range_of_address (irange , gimple *stmt)
-+gimple_ranger::range_of_non_trivial_assignment (irange , gimple *stmt)
- {
-- gcc_checking_assert (gimple_code (stmt) == GIMPLE_ASSIGN);
-- gcc_checking_assert (gimple_assign_rhs_code (stmt) == ADDR_EXPR);
-+ if (gimple_code (stmt) != GIMPLE_ASSIGN)
-+return false;
-
-- bool strict_overflow_p;
-- tree expr = gimple_assign_rhs1 (stmt);
-- poly_int64 bitsize, bitpos;
-- tree offset;
-- machine_mode mode;
-- int unsignedp, reversep, volatilep;
-- tree base = get_inner_reference (TREE_OPERAND (expr, 0), ,
-- , , , ,
-- , );
--
--
-- if (base != NULL_TREE
-- && TREE_CODE (base) == MEM_REF
-- && TREE_CODE (TREE_OPERAND (base, 0)) == SSA_NAME)
-+ tree base = gimple_range_base_of_assignment (stmt);
-+ if (base)
- {
-- tree ssa = TREE_OPERAND (base, 0);
-- gcc_checking_assert (irange::supports_type_p (TREE_TYPE (ssa)));
-- range_of_expr (r, ssa, stmt);
-- range_cast (r, TREE_TYPE (gimple_assign_rhs1 (stmt)));
--
-- poly_offset_int off = 0;
-- bool off_cst = false;
-- if (offset == NULL_TREE || TREE_CODE (offset) == INTEGER_CST)
-+ if (TREE_CODE (base) == MEM_REF)
- {
--off = mem_ref_offset (base);
--if (offset)
-- off += poly_offset_int::from (wi::to_poly_wide (offset),
--SIGNED);
--off <<= LOG2_BITS_PER_UNIT;
--off += bitpos;
--off_cst = true;
-+if (TREE_CODE (TREE_OPERAND (base, 0)) == SSA_NAME)
-+ {
-+int_range_max range1;
-+tree ssa = TREE_OPERAND (base, 0);
-+if (range_of_expr (range1, ssa, stmt))
-+ {
-+tree type = TREE_TYPE (ssa);
-+range_operator *op = range_op_handler (POINTER_PLUS_EXPR,
-+ type);
-+int_range<2> offset (TREE_OPERAND (base, 1),
-+ TREE_OPERAND (base, 1));
-+op->fold_range (r, type, range1, offset);
-+return true;
-+ }
-+ }
-+return false;
- }
-- /* If >a is equal to X, the range of X is the result. */
-- if (off_cst && known_eq (off, 0))
--return true;
-- else if (flag_delete_null_pointer_checks
-- && !TYPE_OVERFLOW_WRAPS (TREE_TYPE (expr)))
-- {
-- /* For -fdelete-null-pointer-checks -fno-wrapv-pointer we don't
-- allow going from non-NULL pointer to NULL. */
-- if(!range_includes_zero_p ())
-- return true;
-- }
-- /* If MEM_REF has a "positive" offset, consider it non-NULL
-- always, for -fdelete-null-pointer-checks also
[PATCH 3/3] toolchain/gcc: refresh gcc-11.2.0 patch
Run make toolchain/gcc/minimal/refresh (with glibc, with musl
toolchain/gcc/{initial,final}/refresh don't work)
Fixes: ab241e0937c9 ("toolchain/gcc: fix build on MacOS arm64")
Signed-off-by: Ilya Lipnitskiy
---
.../patches/11.2.0/970-macos_arm64-building-fix.patch | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/toolchain/gcc/patches/11.2.0/970-macos_arm64-building-fix.patch
b/toolchain/gcc/patches/11.2.0/970-macos_arm64-building-fix.patch
index 6572b8e55900..424899eb9cb8 100644
--- a/toolchain/gcc/patches/11.2.0/970-macos_arm64-building-fix.patch
+++ b/toolchain/gcc/patches/11.2.0/970-macos_arm64-building-fix.patch
@@ -15,11 +15,9 @@ Date: Mon Aug 16 13:16:21 2021 +0100
Reviewed-by: John Scipione
Reviewed-by: Adrien Destugues
-diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h
-index 976f9afae5..736b83ff0b 100644
--- a/gcc/config/aarch64/aarch64.h
+++ b/gcc/config/aarch64/aarch64.h
-@@ -1000,7 +1000,7 @@ extern const char *aarch64_rewrite_mcpu (int argc, const
char **argv);
+@@ -1236,7 +1236,7 @@ extern const char *aarch64_rewrite_mcpu
#define MCPU_TO_MARCH_SPEC_FUNCTIONS \
{ "rewrite_mcpu", aarch64_rewrite_mcpu },
@@ -28,8 +26,6 @@ index 976f9afae5..736b83ff0b 100644
extern const char *host_detect_local_cpu (int argc, const char **argv);
#define HAVE_LOCAL_CPU_DETECT
# define EXTRA_SPEC_FUNCTIONS \
-diff --git a/gcc/config/host-darwin.c b/gcc/config/host-darwin.c
-index 8f700eec85..b737abc006 100644
--- a/gcc/config/host-darwin.c
+++ b/gcc/config/host-darwin.c
@@ -22,6 +22,8 @@
@@ -40,8 +36,8 @@ index 8f700eec85..b737abc006 100644
+#include "hosthooks-def.h"
/* Yes, this is really supposed to work. */
- static char pch_address_space[1024*1024*1024] __attribute__((aligned (4096)));
-@@ -75,3 +77,5 @@ darwin_gt_pch_use_address (void *addr, size_t sz, int fd,
size_t off)
+ /* This allows for a pagesize of 16384, which we have on Darwin20, but should
+@@ -79,3 +81,5 @@ darwin_gt_pch_use_address (void *addr, s
return ret;
}
--
2.34.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 0/3] toolchain/gcc: clean up patches
Use upstream patches instead of custom OpenWrt ones. Refresh patches. Ilya Lipnitskiy (3): toolchain/gcc: remove upstreamed patch, add backport toolchain/gcc: replace revert with upstream fix toolchain/gcc: refresh gcc-11.2.0 patch ...leanup-range-of-address-calculations.patch | 160 -- ...ld_using_range-range_of_address-PR10.patch | 114 + ...-define-TARGET_LIBC_GNUSTACK-on-musl.patch | 46 + .../11.2.0/930-fix-mips-noexecstack.patch | 111 .../11.2.0/970-macos_arm64-building-fix.patch | 10 +- 5 files changed, 163 insertions(+), 278 deletions(-) delete mode 100644 toolchain/gcc/patches/11.2.0/001-Revert-Cleanup-range-of-address-calculations.patch create mode 100644 toolchain/gcc/patches/11.2.0/001-v11.3.0-ranger-Fix-up-fold_using_range-range_of_address-PR10.patch create mode 100644 toolchain/gcc/patches/11.2.0/011-v12-configure-define-TARGET_LIBC_GNUSTACK-on-musl.patch delete mode 100644 toolchain/gcc/patches/11.2.0/930-fix-mips-noexecstack.patch -- 2.34.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH uqmi] nas: add decoding of cell_id
Add decoding of lte_system_info_v2.cid, in --get-system-info, and
intrafrequency_lte_info_v2.global_cell_id, in --get-cell-location-info,
to enodeb_id and cell_id.
h´xyy -> enodeb_id = h´x, cell_id = h´yy
Add decoding of wcdma_system_info_v2.cid, in --get-system-info, to
rnc_id and cell_id.
h´ -> rnc_id = h´, cell_id = h´
Change order to
mcc-mnc-tac/lac-enodeb_id/rnc_id-cell_id.
Signed-off-by: Henrik Ginstmark
---
commands-nas.c | 54 +++---
1 file changed, 29 insertions(+), 25 deletions(-)
diff --git a/commands-nas.c b/commands-nas.c
index 01ca3b8..476cd61 100644
--- a/commands-nas.c
+++ b/commands-nas.c
@@ -313,9 +313,8 @@ print_system_info(uint8_t svc_status, uint8_t tsvc_status,
bool preferred, bool
bool service_cap_valid, uint8_t service_cap,
bool roaming_status_valid, uint8_t roaming_status,
bool forbidden_valid, bool forbidden,
- bool lac_valid, uint16_t lac,
- bool cid_valid, uint32_t cid,
- bool network_id_valid, char *mcc, char *mnc)
+ bool network_id_valid, char *mcc, char *mnc,
+ bool lac_valid, uint16_t lac)
{
static const char *map_service[] = {
[QMI_NAS_SERVICE_STATUS_NONE] = "none",
@@ -362,16 +361,14 @@ print_system_info(uint8_t svc_status, uint8_t
tsvc_status, bool preferred, bool
blobmsg_add_string(, "roaming_status",
map_roaming[roaming_status]);
if (forbidden_valid)
blobmsg_add_u8(, "forbidden", forbidden);
- if (lac_valid)
- blobmsg_add_u32(, "location_area_code",
(int32_t) lac);
- if (cid_valid)
- blobmsg_add_u32(, "cell_id", (int32_t) cid);
if (network_id_valid) {
blobmsg_add_string(, "mcc", mcc);
if ((uint8_t)mnc[2] == 255)
mnc[2] = 0;
blobmsg_add_string(, "mnc", mnc);
}
+ if (lac_valid)
+ blobmsg_add_u32(, "location_area_code",
(int32_t) lac);
}
}
@@ -405,13 +402,14 @@ cmd_nas_get_system_info_cb(struct qmi_dev *qmi, struct
qmi_request *req, struct
res.data.gsm_system_info_v2.roaming_status,
res.data.gsm_system_info_v2.forbidden_valid,
res.data.gsm_system_info_v2.forbidden,
- res.data.gsm_system_info_v2.lac_valid,
- res.data.gsm_system_info_v2.lac,
- res.data.gsm_system_info_v2.cid_valid,
- res.data.gsm_system_info_v2.cid,
res.data.gsm_system_info_v2.network_id_valid,
res.data.gsm_system_info_v2.mcc,
- res.data.gsm_system_info_v2.mnc);
+ res.data.gsm_system_info_v2.mnc,
+ res.data.gsm_system_info_v2.lac_valid,
+ res.data.gsm_system_info_v2.lac);
+ if (res.set.gsm_system_info_v2 &&
res.data.gsm_system_info_v2.cid_valid)
+ blobmsg_add_u32(, "cell_id",
+ res.data.gsm_system_info_v2.cid);
if (res.set.additional_gsm_system_info &&
res.data.additional_gsm_system_info.geo_system_index !=
0x)
blobmsg_add_u32(, "geo_system_index",
@@ -433,13 +431,15 @@ cmd_nas_get_system_info_cb(struct qmi_dev *qmi, struct
qmi_request *req, struct
res.data.wcdma_system_info_v2.roaming_status,
res.data.wcdma_system_info_v2.forbidden_valid,
res.data.wcdma_system_info_v2.forbidden,
- res.data.wcdma_system_info_v2.lac_valid,
- res.data.wcdma_system_info_v2.lac,
- res.data.wcdma_system_info_v2.cid_valid,
- res.data.wcdma_system_info_v2.cid,
res.data.wcdma_system_info_v2.network_id_valid,
res.data.wcdma_system_info_v2.mcc,
- res.data.wcdma_system_info_v2.mnc);
+ res.data.wcdma_system_info_v2.mnc,
+ res.data.wcdma_system_info_v2.lac_valid,
+ res.data.wcdma_system_info_v2.lac);
+ if (res.set.wcdma_system_info_v2 &&
res.data.wcdma_system_info_v2.cid_valid) {
+ blobmsg_add_u32(,
"rnc_id",res.data.wcdma_system_info_v2.cid/65536);
+
Re: 802.11v: hostapd: time_zone
Never mind - they appear to be more sporadic, and perhaps also require a network restart. Time_Zone appears in Probe Response frames only. On 2021-12-07 04:06, Paul D wrote: I tried enabling the wifi settings for 2.4 and 5Ghz.: == time_advertisement == Result: OK. Time appears in beacon frames. e.g. Tag: Time Advertisement Tag Number: Time Advertisement (69) Tag length: 17 Timing capabilities: UTC time at which the TSF timer is 0 (2) Time Value: e5070c07022b2400: current time=2021-12-07 02:44:10 Time Error: 00 Time Update Counter: 0 == time_zone == (set as CET-1CEST,M3.5.0,M10.5.0/3) Result: NOK. Time Zone never appears in beacon frames. Has there been a regression in hostapd, or... was time_zone functionality ever implemented there? Can anyone else confirm? Documentation says it should be there and working. 21.02.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 802.11v: hostapd: bss_load_update_period
Sorry - seems like it's already there :) On 2021-12-07 16:29, Paul D wrote: Could this also be picked to 21.02 branch, please? https://github.com/openwrt/openwrt/commit/85ce590705072be78c3ef7dc6b64e3b1facc892b ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
802.11v: hostapd: bss_load_update_period
Could this also be picked to 21.02 branch, please? https://github.com/openwrt/openwrt/commit/85ce590705072be78c3ef7dc6b64e3b1facc892b ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] netifd: system-linux: add dev_type info for ubus network.device status
Hi, > I have now taken a look at your suggestion. > Unfortunately, I found that not all network interfaces have set the DEVTYPE > attribute set in their uevent file. I have not yet found any information > who sets this value. Does this do the driver or the subsystem? afair it is set by the responsible driver. > [...] > The question now if this DEVTYPE is not set what should we do? I think in case of an absent DEVTYPE variable you can assume "ethernet" as fallback (cross check with /sys/class/net/*/type == 1). Another approach would be falling back to your original mapping in case DEVTYPE is not present (so 1->ethernet, 24->ppp, etc.) ~ Jo signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 2/2] dtc: support printing binary data with fdtget
From: Rafał Miłecki
It's needed for extracting binary images.
Cc: Yousong Zhou
Signed-off-by: Rafał Miłecki
---
...t-for-printing-raw-bytes-with-fdtget.patch | 78 +++
1 file changed, 78 insertions(+)
create mode 100644
package/utils/dtc/patches/0001-Support-b-format-for-printing-raw-bytes-with-fdtget.patch
diff --git
a/package/utils/dtc/patches/0001-Support-b-format-for-printing-raw-bytes-with-fdtget.patch
b/package/utils/dtc/patches/0001-Support-b-format-for-printing-raw-bytes-with-fdtget.patch
new file mode 100644
index 00..388b25e7a7
--- /dev/null
+++
b/package/utils/dtc/patches/0001-Support-b-format-for-printing-raw-bytes-with-fdtget.patch
@@ -0,0 +1,78 @@
+From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=
+Date: Mon, 6 Dec 2021 16:41:11 +0100
+Subject: [PATCH] Support 'b' format for printing raw bytes with fdtget
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+FT is sometimes used for storing raw data. That is quite common for
+U-Boot FIT images.
+
+Extracting such data is not trivial currently. Using type 's' (string)
+will replace every 0x00 (NUL) with 0x20 (space). Using type 'x' will
+print bytes but in xxd incompatible format.
+
+This commit adds support for 'b' (binary) format. Example usage:
+fdtget -t b firmware.itb /images/foo data > image.raw
+
+Signed-off-by: Rafał Miłecki
+---
+ fdtget.c | 5 +
+ util.c | 24 ++--
+ 2 files changed, 19 insertions(+), 10 deletions(-)
+
+--- a/fdtget.c
b/fdtget.c
+@@ -91,6 +91,11 @@ static int show_data(struct display_info
+ if (len == 0)
+ return 0;
+
++ if (disp->type == 'b') {
++ fwrite(data, 1, len, stdout);
++ return 0;
++ }
++
+ is_string = (disp->type) == 's' ||
+ (!disp->type && util_is_printable_string(data, len));
+ if (is_string) {
+--- a/util.c
b/util.c
+@@ -340,24 +340,28 @@ int utilfdt_decode_type(const char *fmt,
+
+ /* get the conversion qualifier */
+ *size = -1;
+- if (strchr("hlLb", *fmt)) {
+- qualifier = *fmt++;
+- if (qualifier == *fmt) {
+- switch (*fmt++) {
+-/* TODO: case 'l': qualifier = 'L'; break;*/
+- case 'h':
++ for (; *(fmt + 1); fmt++) {
++ if (!strchr("hlLb", *fmt))
++ return -1;
++ if (qualifier) {
++ if (*fmt == 'h' && qualifier == 'h')
+ qualifier = 'b';
+- break;
+- }
++ else
++ return -1;
++ } else {
++ qualifier = *fmt;
+ }
+ }
+
+ /* we should now have a type */
+- if ((*fmt == '\0') || !strchr("iuxs", *fmt))
++ if (!strchr("iuxsb", *fmt)) {
++ if (*fmt)
++ fprintf(stderr, "invalid type: %c\n", *fmt);
+ return -1;
++ }
+
+ /* convert qualifier (bhL) to byte size */
+- if (*fmt != 's')
++ if (*fmt != 's' && *fmt != 'b')
+ *size = qualifier == 'b' ? 1 :
+ qualifier == 'h' ? 2 :
+ qualifier == 'l' ? 4 : -1;
--
2.31.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/2] dtc: import package for dtc & fdt from packages feed
From: Rafał Miłecki fdt* utils are needed by targets that use U-Boot FIT images for sysupgrade. It includes all recent BCM4908 SoC routers as Broadcom switched from CFE to U-Boot. fdtget is required for extracting images (bootfs & rootfs) from Broadcom's ITB. Extracted images can be then flashed to UBI volumes. sysupgrade is core functionality so it needs dtc as part of base code base. Cc: Yousong Zhou Signed-off-by: Rafał Miłecki --- package/utils/dtc/Makefile | 93 ++ 1 file changed, 93 insertions(+) create mode 100644 package/utils/dtc/Makefile diff --git a/package/utils/dtc/Makefile b/package/utils/dtc/Makefile new file mode 100644 index 00..94534b9c5e --- /dev/null +++ b/package/utils/dtc/Makefile @@ -0,0 +1,93 @@ +# SPDX-License-Identifier: GPL-2.0 +# +# Copyright (C) 2016-2019 Yousong Zhou + +include $(TOPDIR)/rules.mk + +PKG_NAME:=dtc +PKG_VERSION:=1.6.1 +PKG_RELEASE:=$(AUTORELEASE) + +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz +PKG_HASH:=65cec529893659a49a89740bb362f507a3b94fc8cd791e76a8d6a2b6f3203473 +PKG_SOURCE_URL:=@KERNEL/software/utils/dtc + +PKG_MAINTAINER:=Yousong Zhou +PKG_LICENSE:=GPL-2.0-only +PKG_LICENSE_FILES:=GPL + +PKG_INSTALL:=1 + +include $(INCLUDE_DIR)/package.mk +include $(INCLUDE_DIR)/meson.mk + +define Package/dtc + SECTION:=utils + CATEGORY:=Utilities + TITLE:=Device Tree Compiler + URL:=https://git.kernel.org/pub/scm/utils/dtc/dtc.git +endef + +define Package/dtc/description + Device Tree Compiler for Flat Device Trees Device Tree Compiler, dtc, takes + as input a device-tree in a given format and outputs a device-tree in another + format for booting kernels on embedded systems. +endef + +define Package/dtc/install + $(INSTALL_DIR) $(1)/usr/bin + $(CP) $(PKG_INSTALL_DIR)/usr/bin/dtc $(1)/usr/bin +endef + + +# See Documentation/manual.txt for details about each utility +define Package/fdt-utils + SECTION:=utils + CATEGORY:=Utilities + TITLE:=Flat Device Tree Utilities + URL:=https://git.kernel.org/pub/scm/utils/dtc/dtc.git + DEPENDS:=+libfdt +endef + +define Package/fdt-utils/install + $(INSTALL_DIR) $(1)/usr/bin + $(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/bin/convert-dtsv0 $(1)/usr/bin + $(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/bin/fdtdump $(1)/usr/bin + $(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/bin/fdtget $(1)/usr/bin + $(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/bin/fdtput $(1)/usr/bin + $(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/bin/fdtoverlay $(1)/usr/bin +endef + + +define Package/libfdt + SECTION:=libs + CATEGORY:=Libraries + TITLE:=a utility library for reading and manipulating dtb files + URL:=https://git.kernel.org/pub/scm/utils/dtc/dtc.git +endef + +define Package/libfdt/description + This is a library containing functions for manipulating Flat Device Trees. +endef + +define Package/libfdt/install + $(INSTALL_DIR) $(1)/usr/lib + $(CP) $(PKG_INSTALL_DIR)/usr/lib/libfdt*.so* $(1)/usr/lib +endef + +MESON_ARGS += \ + -Dtools=true \ + -Dyaml=disabled \ + -Dvalgrind=disabled \ + -Dpython=disabled + +define Build/InstallDev + $(INSTALL_DIR) $(1)/usr/lib + $(INSTALL_DIR) $(1)/usr/include + $(CP) $(PKG_INSTALL_DIR)/usr/include/* $(1)/usr/include + $(CP) $(PKG_INSTALL_DIR)/usr/lib/* $(1)/usr/lib +endef + +$(eval $(call BuildPackage,dtc)) +$(eval $(call BuildPackage,fdt-utils)) +$(eval $(call BuildPackage,libfdt)) -- 2.31.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] netifd: system-linux: add dev_type info for ubus network.device status
Hello Jo imho these types are not that useful in practice (e.g. tap devices etc. are all reported as "ethernet". Maybe expose /sys/class/net/$devname/uevent DEVTYP= instead. I have now taken a look at your suggestion. Unfortunately, I found that not all network interfaces have set the DEVTYPE attribute set in their uevent file. I have not yet found any information who sets this value. Does this do the driver or the subsystem? I need to do some more research The following devices does have this DEVTYPE attribute set on my targets root@st-dev-07 /sys/class/net # cat docker0/uevent DEVTYPE=bridge INTERFACE=docker0 IFINDEX=16 root@st-dev-07 /sys/class/net # cat wlan0/uevent DEVTYPE=wlan INTERFACE=wlan0 IFINDEX=14 root@st-dev-07 /sys/class/net # cat wwan0/uevent DEVTYPE=wwan INTERFACE=wwan0 IFINDEX=5 root@VR2-120770 ~ # cat /sys/class/net/pppoe-xdsl/uevent DEVTYPE=ppp INTERFACE=pppoe-xdsl IFINDEX=2285 root@VR2-120770 ~ # The following devices does *not* have this DEVTYPE attribute set on my targets: root@st-dev-07 /sys/class/net # cat eth0/uevent INTERFACE=eth0 IFINDEX=2 root@st-dev-07 /sys/class/net # cat sit0/uevent INTERFACE=sit0 IFINDEX=7 root@st-dev-07 /sys/class/net # cat ip6_vti0/uevent INTERFACE=ip6_vti0 IFINDEX=9 The question now if this DEVTYPE is not set what should we do? Set now `dev_type` value in the ubus output til we update this in the Kernel? Regards Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
