Re: [PATCH] ramips: do not use GPIO function on switch pins on certain devices
Hi! On Wed, Oct 19, 2022 at 7:52 PM Arınç ÜNAL wrote: > > The pins of the MT7530 switch that translate to GPIO 0, 3, 6, 9 and 12 has > got a function, by default, which does the same thing as the netdev > trigger. Because of bridge offloading on DSA, the netdev trigger won't see > the frames between the switch ports whilst the default function will. > > Do not use the GPIO function on switch pins on devices that fall under this > category. > > Keep it for: > > mt7621_belkin_rt1800.dts: There's only one LED which is for the wan > interface and there's no bridge offloading between the "wan" interface and > other interfaces. > > mt7621_yuncore_ax820.dts: There's no bridge offloading between the "wan" > and "lan" interfaces. > > Signed-off-by: Arınç ÜNAL Applied to master. Thanks! -- Regards, Chuanhong Guo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: BCM53xx on D-Link DIR-890L - 2MB max problem
Hi! On Sun, Jan 8, 2023 at 7:38 AM Linus Walleij wrote: > I guess trying to figure out what lzma-loader does and implement > the same for ARM is the way to go, or at some point I felt like > implementing U-Boot for the BCM53xx and implement SEAMA > loading from NAND in U-Boot is maybe easier... The ARM zImage is supposed to be self-extracting, right? Is it possible to package that as an uncompressed code for u-boot? lzma-loader was created at the time when MIPS didn't have zboot support. In ramips, the lzma-loader does the same work as the kernel zboot image: It's a loader which extracts the actual kernel code to the memory. The compressed kernel is linked as a part of the lzma-loader so it doesn't need any flash access. -- Regards, Chuanhong Guo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
BCM53xx on D-Link DIR-890L - 2MB max problem
Hi, after some sweating and testing OpenWrt builds flashed to NAND on the D-Link DIR-890L and failing I realized the problem is the same as on the RAMIPS: the boot loader cannot handle an LZMA file over 2MB. Booting using TFTP in CFE works fine FWIW. There is no problem with the kernel. I understand that we need something like the lzma-loader in RAMIPS target/linux/ramips/image/lzma-loader, though I have no idea how that works. The current boot will just fail like this: seama check OK!! insize = 2097152, out size =8388608 uncompressed size = 2772175 aNowPos64 = 2085677 CodeReal: invalid data lzma decompress fail: -2 Which is the same as observed on RAMIPS. Have you run into this before or is it one of those "congratulations, you are first here, fix it!" kind of things? How come this does not affect the DIR-885? (Or does it?) I guess trying to figure out what lzma-loader does and implement the same for ARM is the way to go, or at some point I felt like implementing U-Boot for the BCM53xx and implement SEAMA loading from NAND in U-Boot is maybe easier... Yours, Linus Walleij ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 6/7] coreutils: Import from packages feed
> Le 7 janv. 2023 à 22:41, Robert Marko a écrit : > > On Sat, 7 Jan 2023 at 16:26, Thibaut VARÈNE wrote: >> >> >> >>> Le 7 janv. 2023 à 15:06, Christian Marangi a écrit : >>> >>> On Fri, Jan 06, 2023 at 11:49:44PM -0800, Brian Norris wrote: I need to express a per-target dependency on the 'base64' utility, and that's seemingly impossible to do for busybox. Pull in coreutils to make that easier. Signed-off-by: Brian Norris >>> >>> We still need to think of a correct solution for this... coreutils is an >>> option but wonder if a better one is openssl... Actually we have a small >>> tool to handle specific decryption of some stuff... Wonder if that can >>> be expanded for this task and just use wolfssl or openssl api to decode >>> base64 stuff? >> >> Using one or the other would impose (i.e. (en)force) that SSL library on >> this particular target. Do we want this, especially considering the ongoing >> conversation about mbedTLS? >> >> Also pulling an entire SSL implementation just to decode base64 seems a tad >> overkill too. > > I agree on this one, forcing usage of OpenSSL isn't ideal, coreutils > is a better option for sure. There might be an even easier/lighter way (short of enabling base64 in busybox), AWK to the rescue: https://github.com/shane-kerr/AWK-base64decode The code is clean and judging by the comment line 97, works with busybox awk. HTH T ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] iwinfo: devices: add Qualcomm Atheros IPQ8074 WiSoC
On Fri, 6 Jan 2023 at 23:43, Jo-Philipp Wich wrote: > > Hi Robert, > > I know that you're just expanding existing code (which I recently noticed for > the first time) but I think that adding more and more if/else clauses with > further hardware matches for purely cosmetic reasons* is a good way forward. > > At the very least a mechanism should be added to configure this > FDT-to-PCI-ID-to-name mapping in the devices.txt file directly. > > > *) Many hardware entries are simply added to show a fancy radio name instead >of "Generic MAC80211" radio but don't add non-defaults values such as power >offsets or antenna gains. Jo, I agree that adding more if/else isn't ideal but this is pretty much what has been done so far and I dont have time or ideas on how to improve this. And yeah, devices are added just to display the SoC name instead of the generic name and that's pretty much it. Regards, Robert > > > Regards, > Jo > > ___ > 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: [PATCH v2 6/7] coreutils: Import from packages feed
On Sat, 7 Jan 2023 at 16:26, Thibaut VARÈNE wrote: > > > > > Le 7 janv. 2023 à 15:06, Christian Marangi a écrit : > > > > On Fri, Jan 06, 2023 at 11:49:44PM -0800, Brian Norris wrote: > >> I need to express a per-target dependency on the 'base64' utility, and > >> that's seemingly impossible to do for busybox. Pull in coreutils to make > >> that easier. > >> > >> Signed-off-by: Brian Norris > > > > We still need to think of a correct solution for this... coreutils is an > > option but wonder if a better one is openssl... Actually we have a small > > tool to handle specific decryption of some stuff... Wonder if that can > > be expanded for this task and just use wolfssl or openssl api to decode > > base64 stuff? > > Using one or the other would impose (i.e. (en)force) that SSL library on this > particular target. Do we want this, especially considering the ongoing > conversation about mbedTLS? > > Also pulling an entire SSL implementation just to decode base64 seems a tad > overkill too. I agree on this one, forcing usage of OpenSSL isn't ideal, coreutils is a better option for sure. Regards, Robert > > HTH > ___ > 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
[PATCH] fw4: fix ipset comment field from bool to string
comment is documented as a string in the man page.
Ref: https://github.com/openwrt/luci/pull/6187#issuecomment-1374506633
Signed-off-by: Paul Dee
---
root/usr/share/ucode/fw4.uc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/root/usr/share/ucode/fw4.uc b/root/usr/share/ucode/fw4.uc
index 5dce90d..0393508 100644
--- a/root/usr/share/ucode/fw4.uc
+++ b/root/usr/share/ucode/fw4.uc
@@ -3191,7 +3191,7 @@ return {
enabled: [ "bool", "1" ],
reload_set: [ "bool" ],
counters: [ "bool" ],
- comment: [ "bool" ],
+ comment: [ "string" ],
name: [ "string", null, REQUIRED ],
family: [ "family", "4" ],
--
2.39.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 6/7] coreutils: Import from packages feed
> Le 7 janv. 2023 à 15:06, Christian Marangi a écrit : > > On Fri, Jan 06, 2023 at 11:49:44PM -0800, Brian Norris wrote: >> I need to express a per-target dependency on the 'base64' utility, and >> that's seemingly impossible to do for busybox. Pull in coreutils to make >> that easier. >> >> Signed-off-by: Brian Norris > > We still need to think of a correct solution for this... coreutils is an > option but wonder if a better one is openssl... Actually we have a small > tool to handle specific decryption of some stuff... Wonder if that can > be expanded for this task and just use wolfssl or openssl api to decode > base64 stuff? Using one or the other would impose (i.e. (en)force) that SSL library on this particular target. Do we want this, especially considering the ongoing conversation about mbedTLS? Also pulling an entire SSL implementation just to decode base64 seems a tad overkill too. HTH ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 6/7] coreutils: Import from packages feed
On Fri, Jan 06, 2023 at 11:49:44PM -0800, Brian Norris wrote: > I need to express a per-target dependency on the 'base64' utility, and > that's seemingly impossible to do for busybox. Pull in coreutils to make > that easier. > > Signed-off-by: Brian Norris We still need to think of a correct solution for this... coreutils is an option but wonder if a better one is openssl... Actually we have a small tool to handle specific decryption of some stuff... Wonder if that can be expanded for this task and just use wolfssl or openssl api to decode base64 stuff? Would love some feedback about this from others since it's not so trivial. > --- > * New in v2 > > > (no changes since v1) > > package/utils/coreutils/Makefile | 153 ++ > .../patches/001-no_docs_man_tests.patch | 93 +++ > 2 files changed, 246 insertions(+) > create mode 100644 package/utils/coreutils/Makefile > create mode 100644 > package/utils/coreutils/patches/001-no_docs_man_tests.patch > > diff --git a/package/utils/coreutils/Makefile > b/package/utils/coreutils/Makefile > new file mode 100644 > index ..d1af3ce962f1 > --- /dev/null > +++ b/package/utils/coreutils/Makefile > @@ -0,0 +1,153 @@ > +# > +# Copyright (C) 2008-2014 OpenWrt.org > +# > +# This is free software, licensed under the GNU General Public License v2. > +# See /LICENSE for more information. > +# > + > +include $(TOPDIR)/rules.mk > + > +PKG_NAME:=coreutils > +PKG_VERSION:=9.1 > +PKG_RELEASE:=1 > + > +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz > +PKG_SOURCE_URL:=@GNU/coreutils > +PKG_HASH:=61a1f410d78ba7e7f37a5a4f50e6d1320aca33375484a3255eddf17a38580423 > + > +PKG_MAINTAINER:=Jo-Philipp Wich > +PKG_LICENSE:=GPL-3.0-or-later > +PKG_LICENSE_FILES:=COPYING > +PKG_CPE_ID:=cpe:/a:gnu:coreutils > + > +PKG_INSTALL:=1 > +PKG_BUILD_PARALLEL:=1 > + > +include $(INCLUDE_DIR)/package.mk > + > +COREUTILS_APPLETS := \ > + base32 base64 basename basenc b2sum cat chcon chgrp chmod chown chroot > \ > + cksum comm cp csplit cut date dd df dir dircolors dirname du echo env > \ > + expand expr factor false fmt fold groups head hostid id install join > \ > + kill link ln logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl > \ > + nohup nproc numfmt od paste pathchk pinky pr printenv printf ptx pwd > \ > + readlink realpath rm rmdir runcon seq sha1sum sha224sum sha256sum > \ > + sha384sum sha512sum shred shuf sleep sort split stat stdbuf stty sum > \ > + sync tac tail tee test timeout touch tr true truncate tsort tty uname > \ > + unexpand uniq unlink uptime users vdir wc who whoami yes > + > +DIR_BIN := \ > + base64 cat chgrp chmod chown cp date dd df echo false kill link ln ls > \ > + mkdir mknod mktemp mv nice printenv pwd rm rmdir sleep stat stty sync > \ > + touch true uname > + > +DIR_USR_BIN := \ > + basename chcon cksum comm cut dirname du env expand expr factor fold > \ > + groups head hostid id install logname md5sum mkfifo nl nohup nproc od > \ > + paste printf readlink realpath runcon seq sha1sum sha256sum sha512sum > \ > + shred shuf sort split sum tac tail tee test timeout tr truncate tty > \ > + unexpand uniq unlink uptime users wc who whoami yes > + > +DIR_USR_SBIN := \ > + chroot > + > +# BusyBox does not provide these yet > +DIR_OTHERS := \ > + base32 b2sum basenc csplit dir dircolors fmt join numfmt pathchk pinky > \ > + pr ptx sha224sum sha384sum stdbuf tsort vdir > + > +$(eval $(foreach > a,$(DIR_BIN),ALTS_$(a):=300:/bin/$(a):/usr/libexec/$(a)-coreutils$(newline))) > +$(eval $(foreach > a,$(DIR_USR_BIN),ALTS_$(a):=300:/usr/bin/$(a):/usr/libexec/$(a)-coreutils$(newline))) > +$(eval $(foreach > a,$(DIR_USR_SBIN),ALTS_$(a):=300:/usr/sbin/$(a):/usr/libexec/$(a)-coreutils$(newline))) > + > +DEPENDS_sort = +libpthread > +DEPENDS_timeout = +librt > +DEPENDS_expr = +libgmp > +DEPENDS_factor = +libgmp > +DEPENDS_cp = +libacl > +DEPENDS_dir = +libacl +libcap > +DEPENDS_install = +libacl > +DEPENDS_ls = +libacl +libcap > +DEPENDS_mv = +libacl > +DEPENDS_vdir = +libacl +libcap > + > +FILES_stdbuf := usr/lib/coreutils/libstdbuf.so > + > +define Package/coreutils/Default > + SECTION:=utils > + CATEGORY:=Utilities > + TITLE:=The GNU core utilities > + URL:=http://www.gnu.org/software/coreutils/ > +endef > + > +define Package/coreutils > + $(call Package/coreutils/Default) > + TITLE:=The GNU core utilities > + MENU:=1 > +endef > + > +define Package/coreutils/description > + Full versions of standard GNU utilities. If an equivalent Busybox applet is > + available, you should consider compiling that instead as Busybox applets are > + usually smaller, at the expense of reduced functionality. > +endef > + > +define GenPlugin > + define Package/$(1) > + $(call Package/coreutils/Default) > + DEPENDS:=coreutils $(DEPENDS_$(2)) > + TITLE:=Utility $(2) from the GNU core utilities > +
[PATCH v3] ramips: add support for D-Link DAP-X1860 A1
The DAP-X1860 is a wall-plug AX1800 repeater.
Specifications:
- MT7621, 256 MiB RAM, 128 MiB SPI NAND
- MT7915 + MT7975 2x2 802.11ax (DBDC)
- Ethernet: 1 port 10/100/1000
- LED RSSI bargraph (2x green, 1x red/orange), status
and RSSI LEDs are incorrectly populated red/orange
(should be red/green according to documentation)
Installation:
- Keep reset button pressed during plug-in
- Web Recovery Updater is at 192.168.0.50
- Upload factory.bin, confirm flashing
(seems to work best with Chromium-based browsers)
Revert to OEM firmware:
- tar -xvf DAP-X1860_RevA_Firmware_101b94.bin
- openssl enc -d -md md5 -aes-256-cbc -in FWImage.st2 \
-out FWImage.st1 -k MB0dBx62oXJXDvt12lETWQ==
- tar -xvf FWImage.st1
- flash kernel_DAP-X1860.bin via Recovery
Signed-off-by: Sebastian Schaper
---
v3:
* increase KERNEL_SIZE from 4096k to 8192k
v2:
* drop uImage-relocate in favor of KERNEL_LOADADDR 0x8200
* use fit image for kernel + dtb
* rebased to latest master
.../ramips/dts/mt7621_dlink_dap-x1860-a1.dts | 197 ++
target/linux/ramips/image/mt7621.mk | 21 ++
.../mt7621/base-files/etc/board.d/01_leds | 7 +
.../mt7621/base-files/etc/board.d/02_network | 1 +
.../etc/hotplug.d/ieee80211/10_fix_wifi_mac | 7 +
.../mt7621/base-files/lib/upgrade/platform.sh | 1 +
6 files changed, 234 insertions(+)
create mode 100644 target/linux/ramips/dts/mt7621_dlink_dap-x1860-a1.dts
diff --git a/target/linux/ramips/dts/mt7621_dlink_dap-x1860-a1.dts
b/target/linux/ramips/dts/mt7621_dlink_dap-x1860-a1.dts
new file mode 100644
index 00..edc1c6544c
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_dlink_dap-x1860-a1.dts
@@ -0,0 +1,197 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "mt7621.dtsi"
+
+#include
+#include
+
+/ {
+ compatible = "dlink,dap-x1860-a1", "mediatek,mt7621-soc";
+ model = "D-Link DAP-X1860 A1";
+
+ chosen {
+ bootargs = "console=ttyS0,115200";
+ };
+
+ aliases {
+ label-mac-device =
+ led-boot = _power_orange;
+ led-failsafe = _power_red;
+ led-running = _power_orange;
+ led-upgrade = _power_red;
+ };
+
+ keys {
+ compatible = "gpio-keys";
+
+ wps {
+ label = "wps";
+ gpios = < 4 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+
+ reset {
+ label = "reset";
+ gpios = < 6 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led_power_red: power_red {
+ label = "red:power";
+ gpios = < 7 GPIO_ACTIVE_LOW>;
+ };
+
+ led_power_orange: power_orange {
+ label = "orange:power";
+ gpios = < 8 GPIO_ACTIVE_LOW>;
+ default-state = "on";
+ };
+
+ rssihigh {
+ label = "green:rssihigh";
+ gpios = < 22 GPIO_ACTIVE_LOW>;
+ };
+
+ rssimedium {
+ label = "green:rssimedium";
+ gpios = < 23 GPIO_ACTIVE_LOW>;
+ };
+
+ rssilow_orange {
+ label = "orange:rssilow";
+ gpios = < 26 GPIO_ACTIVE_LOW>;
+ };
+
+ rssilow_green {
+ label = "green:rssilow";
+ gpios = < 27 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ virtual_flash {
+ compatible = "mtd-concat";
+
+ devices = < >;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "ubi";
+ reg = <0x0 0x0>;
+ };
+ };
+ };
+};
+
+ {
+ status = "okay";
+
+ mediatek,nmbm;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "bootloader";
+ reg = <0x0 0x8>;
+ read-only;
+ };
+
+ partition@8 {
+ label = "config";
+ reg = <0x8 0x8>;
+ read-only;
+ };
+
+ factory: partition@10 {
+ label = "factory";
+ reg = <0x10 0x8>;
+ read-only;
+
+ compatible =
Re: [PATCH RFC] Revert "generic: write back netdev MAC-address to device-tree"
Christian Marangi writes:
> On Sat, Jan 07, 2023 at 01:05:42PM +0100, Rafał Miłecki wrote:
>> From: Rafał Miłecki
>>
>> This reverts commit cd39aba402ea7e7a11e173b0b5aa96e42bf1f2ac.
>>
>> Adding "mac-address" property to the device tree seems to be done to
>> allow reading it using procfs (/proc/device-tree/). It seems like a hack
>> without a proper explanation WHY do we need that.
>>
>> Reading MAC address can be done other ways including fs based:
>> cat /sys/class/net//address
>>
>> Cc: David Bauer
>> Signed-off-by: Rafał Miłecki
>> ---
>> David, everyone,
>>
>> it seems this patch never ended up being sent upstream and it sits in
>> our tree without actual explanation why do we need that.
>>
>> I was wondering if we can just drop it?
>
> I remember me dropping the patch when nvmem was introduced but that
> caused some regression as some script still used the procfs way... we
> should find and fix the affected script before dropping this.
>
> (hoping a simple grep is enough)
From package/base-files/files/lib/functions/system.sh:
get_mac_label_dt() {
local basepath="/proc/device-tree"
local macdevice="$(cat "$basepath/aliases/label-mac-device"
2>/dev/null)"
local macaddr
[ -n "$macdevice" ] || return
macaddr=$(get_mac_binary "$basepath/$macdevice/mac-address" 0
2>/dev/null)
[ -n "$macaddr" ] || macaddr=$(get_mac_binary
"$basepath/$macdevice/local-mac-address" 0 2>/dev/null)
echo $macaddr
}
Bjørn
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] ramips: add support for D-Link DAP-X1860 A1
On 01/07/23 13:04 David Bauer wrote: Considering we have 50 MB of firmware space available, enlarging the space allocated for the kernel to 8M has the potential of avoiding pain down the line if the kernel exceeds 4M in size. Hi David, I thought the same initially (c.f. v1 mail), but then went for 4096K as it was used by more devices. 8192K would feel like just delaying the issue in some way, but with a newly-added device it's probably better for now. Building an image with 8192K for testing. Best Sebastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH RFC] Revert "generic: write back netdev MAC-address to device-tree"
On Sat, Jan 07, 2023 at 01:05:42PM +0100, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> This reverts commit cd39aba402ea7e7a11e173b0b5aa96e42bf1f2ac.
>
> Adding "mac-address" property to the device tree seems to be done to
> allow reading it using procfs (/proc/device-tree/). It seems like a hack
> without a proper explanation WHY do we need that.
>
> Reading MAC address can be done other ways including fs based:
> cat /sys/class/net//address
>
> Cc: David Bauer
> Signed-off-by: Rafał Miłecki
> ---
> David, everyone,
>
> it seems this patch never ended up being sent upstream and it sits in
> our tree without actual explanation why do we need that.
>
> I was wondering if we can just drop it?
I remember me dropping the patch when nvmem was introduced but that
caused some regression as some script still used the procfs way... we
should find and fix the affected script before dropping this.
(hoping a simple grep is enough)
> ---
> ...83-of_net-add-mac-address-to-of-tree.patch | 54 --
> ...83-of_net-add-mac-address-to-of-tree.patch | 55 ---
> 2 files changed, 109 deletions(-)
> delete mode 100644
> target/linux/generic/pending-5.10/683-of_net-add-mac-address-to-of-tree.patch
> delete mode 100644
> target/linux/generic/pending-5.15/683-of_net-add-mac-address-to-of-tree.patch
>
> diff --git
> a/target/linux/generic/pending-5.10/683-of_net-add-mac-address-to-of-tree.patch
>
> b/target/linux/generic/pending-5.10/683-of_net-add-mac-address-to-of-tree.patch
> deleted file mode 100644
> index 501422551b..00
> ---
> a/target/linux/generic/pending-5.10/683-of_net-add-mac-address-to-of-tree.patch
> +++ /dev/null
> @@ -1,54 +0,0 @@
> -From: David Bauer
> -Subject: of/net: Add MAC address to of tree
> -
> -The label-mac logic relies on the mac-address property of a netdev
> -devices of-node. However, the mac address can also be stored as a
> -different property or read from e.g. an mtd device.
> -
> -Create this node when reading a mac-address from OF if it does not
> -already exist and copy the mac-address used for the device to this
> -property. This way, the MAC address can be accessed using procfs.
> -
> -Submitted-by: David Bauer
>
> - drivers/of/of_net.c | 22 ++
> - 1 files changed, 22 insertions(+)
> -
> a/drivers/of/of_net.c
> -+++ b/drivers/of/of_net.c
> -@@ -95,6 +95,27 @@ static int of_get_mac_addr_nvmem(struct
> - return 0;
> - }
> -
> -+static int of_add_mac_address(struct device_node *np, u8* addr)
> -+{
> -+struct property *prop;
> -+
> -+prop = kzalloc(sizeof(*prop), GFP_KERNEL);
> -+if (!prop)
> -+return -ENOMEM;
> -+
> -+prop->name = "mac-address";
> -+prop->length = ETH_ALEN;
> -+prop->value = kmemdup(addr, ETH_ALEN, GFP_KERNEL);
> -+if (!prop->value || of_update_property(np, prop))
> -+goto free;
> -+
> -+return 0;
> -+free:
> -+kfree(prop->value);
> -+kfree(prop);
> -+return -ENOMEM;
> -+}
> -+
> - /**
> - * Search the device tree for the best MAC address to use. 'mac-address' is
> - * checked first, because that is supposed to contain to "most recent" MAC
> -@@ -171,6 +192,7 @@ found:
> - addr[5] = (mac_val >> 0) & 0xff;
> - }
> -
> -+of_add_mac_address(np, addr);
> - return ret;
> - }
> - EXPORT_SYMBOL(of_get_mac_address);
> diff --git
> a/target/linux/generic/pending-5.15/683-of_net-add-mac-address-to-of-tree.patch
>
> b/target/linux/generic/pending-5.15/683-of_net-add-mac-address-to-of-tree.patch
> deleted file mode 100644
> index f7ef06a14a..00
> ---
> a/target/linux/generic/pending-5.15/683-of_net-add-mac-address-to-of-tree.patch
> +++ /dev/null
> @@ -1,55 +0,0 @@
> -From 8585756342caa6d27008d1ad0c18023e4211a40a Mon Sep 17 00:00:00 2001
> -From: OpenWrt community
> -Date: Wed, 13 Jul 2022 12:22:48 +0200
> -Subject: [PATCH] of/of_net: write back netdev MAC-address to device-tree
> -
> -The label-mac logic relies on the mac-address property of a netdev
> -devices of-node. However, the mac address can also be stored as a
> -different property or read from e.g. an mtd device.
> -
> -Create this node when reading a mac-address from OF if it does not
> -already exist and copy the mac-address used for the device to this
> -property. This way, the MAC address can be accessed using procfs.
> -
>
> - net/core/of_net.c | 22 ++
> - 1 file changed, 22 insertions(+)
> -
> a/net/core/of_net.c
> -+++ b/net/core/of_net.c
> -@@ -95,6 +95,27 @@ static int of_get_mac_addr_nvmem(struct
> - return 0;
> - }
> -
> -+static int of_add_mac_address(struct device_node *np, u8* addr)
> -+{
> -+struct property *prop;
> -+
> -+prop = kzalloc(sizeof(*prop), GFP_KERNEL);
> -+if (!prop)
> -+return -ENOMEM;
> -+
> -+prop->name = "mac-address";
> -+prop->length = ETH_ALEN;
> -+prop->value = kmemdup(addr, ETH_ALEN, GFP_KERNEL);
> -+
Re: [PATCH v2] ramips: add support for D-Link DAP-X1860 A1
Hi Sebastian,
On 1/7/23 12:56, Sebastian Schaper wrote:
[...]
+_default {
+ gpio {
+ groups = "uart2";
+ function = "gpio";
+ };
+};
diff --git a/target/linux/ramips/image/mt7621.mk
b/target/linux/ramips/image/mt7621.mk
index dd49583bf4..6492748aed 100644
--- a/target/linux/ramips/image/mt7621.mk
+++ b/target/linux/ramips/image/mt7621.mk
@@ -479,6 +479,27 @@ define Device/cudy_x6
endef
TARGET_DEVICES += cudy_x6
+define Device/dlink_dap-x1860-a1
+ $(Device/dsa-migration)
+ IMAGE_SIZE := 53248k
+ DEVICE_VENDOR := D-Link
+ DEVICE_MODEL := DAP-X1860
+ DEVICE_VARIANT := A1
+ UBINIZE_OPTS := -E 5
+ BLOCKSIZE := 128k
+ PAGESIZE := 2048
+ KERNEL_SIZE := 4096k
Considering we have 50 MB of firmware space available, enlarging the
space allocated for the kernel to 8M has the potential of avoiding pain
down the line if the kernel exceeds 4M in size.
Best
David
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH RFC] Revert "generic: write back netdev MAC-address to device-tree"
From: Rafał Miłecki
This reverts commit cd39aba402ea7e7a11e173b0b5aa96e42bf1f2ac.
Adding "mac-address" property to the device tree seems to be done to
allow reading it using procfs (/proc/device-tree/). It seems like a hack
without a proper explanation WHY do we need that.
Reading MAC address can be done other ways including fs based:
cat /sys/class/net//address
Cc: David Bauer
Signed-off-by: Rafał Miłecki
---
David, everyone,
it seems this patch never ended up being sent upstream and it sits in
our tree without actual explanation why do we need that.
I was wondering if we can just drop it?
---
...83-of_net-add-mac-address-to-of-tree.patch | 54 --
...83-of_net-add-mac-address-to-of-tree.patch | 55 ---
2 files changed, 109 deletions(-)
delete mode 100644
target/linux/generic/pending-5.10/683-of_net-add-mac-address-to-of-tree.patch
delete mode 100644
target/linux/generic/pending-5.15/683-of_net-add-mac-address-to-of-tree.patch
diff --git
a/target/linux/generic/pending-5.10/683-of_net-add-mac-address-to-of-tree.patch
b/target/linux/generic/pending-5.10/683-of_net-add-mac-address-to-of-tree.patch
deleted file mode 100644
index 501422551b..00
---
a/target/linux/generic/pending-5.10/683-of_net-add-mac-address-to-of-tree.patch
+++ /dev/null
@@ -1,54 +0,0 @@
-From: David Bauer
-Subject: of/net: Add MAC address to of tree
-
-The label-mac logic relies on the mac-address property of a netdev
-devices of-node. However, the mac address can also be stored as a
-different property or read from e.g. an mtd device.
-
-Create this node when reading a mac-address from OF if it does not
-already exist and copy the mac-address used for the device to this
-property. This way, the MAC address can be accessed using procfs.
-
-Submitted-by: David Bauer
- drivers/of/of_net.c | 22 ++
- 1 files changed, 22 insertions(+)
-
a/drivers/of/of_net.c
-+++ b/drivers/of/of_net.c
-@@ -95,6 +95,27 @@ static int of_get_mac_addr_nvmem(struct
- return 0;
- }
-
-+static int of_add_mac_address(struct device_node *np, u8* addr)
-+{
-+ struct property *prop;
-+
-+ prop = kzalloc(sizeof(*prop), GFP_KERNEL);
-+ if (!prop)
-+ return -ENOMEM;
-+
-+ prop->name = "mac-address";
-+ prop->length = ETH_ALEN;
-+ prop->value = kmemdup(addr, ETH_ALEN, GFP_KERNEL);
-+ if (!prop->value || of_update_property(np, prop))
-+ goto free;
-+
-+ return 0;
-+free:
-+ kfree(prop->value);
-+ kfree(prop);
-+ return -ENOMEM;
-+}
-+
- /**
- * Search the device tree for the best MAC address to use. 'mac-address' is
- * checked first, because that is supposed to contain to "most recent" MAC
-@@ -171,6 +192,7 @@ found:
- addr[5] = (mac_val >> 0) & 0xff;
- }
-
-+ of_add_mac_address(np, addr);
- return ret;
- }
- EXPORT_SYMBOL(of_get_mac_address);
diff --git
a/target/linux/generic/pending-5.15/683-of_net-add-mac-address-to-of-tree.patch
b/target/linux/generic/pending-5.15/683-of_net-add-mac-address-to-of-tree.patch
deleted file mode 100644
index f7ef06a14a..00
---
a/target/linux/generic/pending-5.15/683-of_net-add-mac-address-to-of-tree.patch
+++ /dev/null
@@ -1,55 +0,0 @@
-From 8585756342caa6d27008d1ad0c18023e4211a40a Mon Sep 17 00:00:00 2001
-From: OpenWrt community
-Date: Wed, 13 Jul 2022 12:22:48 +0200
-Subject: [PATCH] of/of_net: write back netdev MAC-address to device-tree
-
-The label-mac logic relies on the mac-address property of a netdev
-devices of-node. However, the mac address can also be stored as a
-different property or read from e.g. an mtd device.
-
-Create this node when reading a mac-address from OF if it does not
-already exist and copy the mac-address used for the device to this
-property. This way, the MAC address can be accessed using procfs.
-
- net/core/of_net.c | 22 ++
- 1 file changed, 22 insertions(+)
-
a/net/core/of_net.c
-+++ b/net/core/of_net.c
-@@ -95,6 +95,27 @@ static int of_get_mac_addr_nvmem(struct
- return 0;
- }
-
-+static int of_add_mac_address(struct device_node *np, u8* addr)
-+{
-+ struct property *prop;
-+
-+ prop = kzalloc(sizeof(*prop), GFP_KERNEL);
-+ if (!prop)
-+ return -ENOMEM;
-+
-+ prop->name = "mac-address";
-+ prop->length = ETH_ALEN;
-+ prop->value = kmemdup(addr, ETH_ALEN, GFP_KERNEL);
-+ if (!prop->value || of_update_property(np, prop))
-+ goto free;
-+
-+ return 0;
-+free:
-+ kfree(prop->value);
-+ kfree(prop);
-+ return -ENOMEM;
-+}
-+
- /**
- * of_get_mac_address()
- * @np: Caller's Device Node
-@@ -175,6 +196,7 @@ found:
- addr[5] = (mac_val >> 0) & 0xff;
- }
-
-+ of_add_mac_address(np, addr);
- return ret;
- }
- EXPORT_SYMBOL(of_get_mac_address);
--
2.34.1
___
Re: [PATCH] ramips: add support for D-Link DAP-X1860 A1
On 01/06/23 19:52, Hauke Mehrtens wrote: Why do you need uImage-relocate and can not use the standard Build/uImage? You have to set KERNEL_LOADADDR to 0x8100. Thanks for the hint, I had initially tried several load addresses with the same effect, the kernel would either decompress but the system would just halt, or the decompress would fail (crc error) if the offsets overlap, i.e. decompress would overwrite the source. I now used 0x8200 as with several other devices, which works fine. Also switched to the fit boilerplate that is shared by many of these devices. Factory flashing, sysupgrade and initramfs via tftp were tested successfully. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2] ramips: add support for D-Link DAP-X1860 A1
The DAP-X1860 is a wall-plug AX1800 repeater.
Specifications:
- MT7621, 256 MiB RAM, 128 MiB SPI NAND
- MT7915 + MT7975 2x2 802.11ax (DBDC)
- Ethernet: 1 port 10/100/1000
- LED RSSI bargraph (2x green, 1x red/orange), status
and RSSI LEDs are incorrectly populated red/orange
(should be red/green according to documentation)
Installation:
- Keep reset button pressed during plug-in
- Web Recovery Updater is at 192.168.0.50
- Upload factory.bin, confirm flashing
(seems to work best with Chromium-based browsers)
Revert to OEM firmware:
- tar -xvf DAP-X1860_RevA_Firmware_101b94.bin
- openssl enc -d -md md5 -aes-256-cbc -in FWImage.st2 \
-out FWImage.st1 -k MB0dBx62oXJXDvt12lETWQ==
- tar -xvf FWImage.st1
- flash kernel_DAP-X1860.bin via Recovery
Signed-off-by: Sebastian Schaper
---
v2:
* drop uImage-relocate in favor of KERNEL_LOADADDR 0x8200
* use fit image for kernel + dtb
* rebased to latest master
.../ramips/dts/mt7621_dlink_dap-x1860-a1.dts | 197 ++
target/linux/ramips/image/mt7621.mk | 21 ++
.../mt7621/base-files/etc/board.d/01_leds | 7 +
.../mt7621/base-files/etc/board.d/02_network | 1 +
.../etc/hotplug.d/ieee80211/10_fix_wifi_mac | 7 +
.../mt7621/base-files/lib/upgrade/platform.sh | 1 +
6 files changed, 234 insertions(+)
create mode 100644 target/linux/ramips/dts/mt7621_dlink_dap-x1860-a1.dts
diff --git a/target/linux/ramips/dts/mt7621_dlink_dap-x1860-a1.dts
b/target/linux/ramips/dts/mt7621_dlink_dap-x1860-a1.dts
new file mode 100644
index 00..8c156c17ce
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_dlink_dap-x1860-a1.dts
@@ -0,0 +1,197 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "mt7621.dtsi"
+
+#include
+#include
+
+/ {
+ compatible = "dlink,dap-x1860-a1", "mediatek,mt7621-soc";
+ model = "D-Link DAP-X1860 A1";
+
+ chosen {
+ bootargs = "console=ttyS0,115200";
+ };
+
+ aliases {
+ label-mac-device =
+ led-boot = _power_orange;
+ led-failsafe = _power_red;
+ led-running = _power_orange;
+ led-upgrade = _power_red;
+ };
+
+ keys {
+ compatible = "gpio-keys";
+
+ wps {
+ label = "wps";
+ gpios = < 4 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+
+ reset {
+ label = "reset";
+ gpios = < 6 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led_power_red: power_red {
+ label = "red:power";
+ gpios = < 7 GPIO_ACTIVE_LOW>;
+ };
+
+ led_power_orange: power_orange {
+ label = "orange:power";
+ gpios = < 8 GPIO_ACTIVE_LOW>;
+ default-state = "on";
+ };
+
+ rssihigh {
+ label = "green:rssihigh";
+ gpios = < 22 GPIO_ACTIVE_LOW>;
+ };
+
+ rssimedium {
+ label = "green:rssimedium";
+ gpios = < 23 GPIO_ACTIVE_LOW>;
+ };
+
+ rssilow_orange {
+ label = "orange:rssilow";
+ gpios = < 26 GPIO_ACTIVE_LOW>;
+ };
+
+ rssilow_green {
+ label = "green:rssilow";
+ gpios = < 27 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ virtual_flash {
+ compatible = "mtd-concat";
+
+ devices = < >;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "ubi";
+ reg = <0x0 0x0>;
+ };
+ };
+ };
+};
+
+ {
+ status = "okay";
+
+ mediatek,nmbm;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "bootloader";
+ reg = <0x0 0x8>;
+ read-only;
+ };
+
+ partition@8 {
+ label = "config";
+ reg = <0x8 0x8>;
+ read-only;
+ };
+
+ factory: partition@10 {
+ label = "factory";
+ reg = <0x10 0x8>;
+ read-only;
+
+ compatible = "nvmem-cells";
+ #address-cells = <1>;
Re: [PATCH] realtek: don't relocate kernel on HPE 1920 series
On Thu, 2023-01-05 at 22:36 +0100, Jan Hoffmann wrote: > This is no longer needed now that the kernel is built with a load > address that matches the one hard-coded in the bootloader. > > Signed-off-by: Jan Hoffmann > --- Thanks for keeping things up to date! Merged to master. Best, Sander ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 7/7] ipq806x: Initial TP-Link and ASUS OnHub support
TP-Link and ASUS OnHub devices are very similar, sharing many of the same characteristics and much of their Device Tree. They both run a version of ChromeOS for their factory firmware, and so installation instructions look very similar to Google Wifi [1]. Things that work: * Ethernet * WiFi (2.4 and 5 GHz) * LEDs * USB * eMMC * Serial console (if you wire it up yourself) * 1 CPU * Speaker; I think I've worked out the kinks (with the parent patches, and tweaking pin configuration a bit) Things that don't work: * The second CPU; bringing up the second CPU seems to hang right now, so I disable it with "maxcpus=1". == Installation instructions summary == 1. Flash *-factory.bin to a USB drive (e.g., with `dd`) 2. Enter Developer Mode 3. Insert USB drive, to boot OpenWrt from USB 4. Copy the same *-factory.bin over to device, and flash it to eMMC to make OpenWrt permanent == Developer mode (Step 2) == To enter Developer Mode [2], follow these steps: 1. Unplug power 2. Gain access to the "developer switch" through the bottom of the device 3. Plug a USB keyboard into the device's USB port 4. Hold down the "reset switch" (near the USB port / power plug) 5. Plug power back in 6. The LED on the device should turn white, then blink orange, then red. Release the reset switch. 7. Press CTRL+D on the keyboard. The LED should now start blinking purple. 8. Press and release the hidden "developer switch" under the device. 9. The device should reboot, and start blinking purple again. You have successfully entered developer mode. 10. Unplug power These instructions are derived from: https://www.exploitee.rs/index.php/Rooting_The_Google_OnHub#Enabling_%22Developer_Mode%22_on_the_OnHub https://www.exploitee.rs/index.php/Asus_OnHub#Enabling_%22Developer_Mode%22_on_the_OnHub ~~Finding the developer switch:~~ for TP-Link, the developer switch is on the bottom of the device, underneath some of the rubber padding and a screw. For ASUS, remove the entire base, via 4 screws under the rubber feet. See the Exploitee instructions for more info and photos. == Booting from USB (Step 3) == After entering developer mode: 1. Unplug power 2. Insert USB drive with OpenWrt factory.bin 3. Plug power; after a few seconds, the device should start blinking purple 4. Press the hidden developer switch under the device to boot to USB; you should see some activity lights (if you have any) on your USB drive 5. Depending on your configuration, the router's LED(s) should come on. You're now running OpenWrt off a USB stick. == Making OpenWrt permanent (on eMMC) (Step 4) == Once you're running OpenWrt via USB: 1. Connect Ethernet to the LAN port; router's LAN address should be at 192.168.1.1 2. Connect another system to the router's LAN, and copy the factory.bin image over, via SCP and SSH: scp -O openwrt-ipq806x-chromium-tplink_onhub-squashfs-factory.bin root@192.168.1.1: ssh root@192.168.1.1 -C "dd if=/dev/zero bs=512 seek=7552991 of=/dev/mmcblk0 count=33 && \ dd if=/root/openwrt-ipq806x-chromium-tplink_onhub-squashfs-factory.bin of=/dev/mmcblk0" 3. Reboot and remove the USB drive. == Developer mode beep == Note that every time you boot the OnHub in developer mode, the device will play a loud "beep" after a few seconds. This is described in the Chromium docs [2], and is intended to make it clear that the device is not running Google software. It is nontrivial to completely disable this beep, although it's possible to "acknowledge" developer mode (and skip the beep) by using a USB keyboard to press CTRL+D every time you boot. [1] https://openwrt.org/toh/google/wifi [2] https://chromium.googlesource.com/chromiumos/docs/+/HEAD/developer_mode.md Signed-off-by: Brian Norris --- * There might be better ways to handle the multi-color LED support, but for now, each color is a separate LED * A variety of people have been interested in this work, and a few have tested versions of it already: https://forum.openwrt.org/t/onhub-tp-link-tgr1900-future-support/17899 * This is dependent on an fstools change, to ensure it can find our 'rootfs_data' properly: [PATCH fstools v2] partname: Ignore root=PARTUUID... https://patchwork.ozlabs.org/project/openwrt/patch/20230107020424.1703752-1-computersforpe...@gmail.com/ Changes in v2: * Drop custom ath10k base64 property * Provide base64 caldata parsing via /etc/hotplug.d/firmware/11-ath10k-caldata instead * add coreutils-base64 dependency * add 3rd (rootfs_data) partition, to better handle sysupgrade and utilize the whole disk target/linux/ipq806x/Makefile | 4 +- .../ipq806x/base-files/etc/board.d/01_leds| 11 + .../ipq806x/base-files/etc/board.d/02_network | 6 + .../etc/hotplug.d/firmware/11-ath10k-caldata | 35 ++ .../base-files/lib/upgrade/platform.sh| 19 + target/linux/ipq806x/chromium/config-default | 13 + target/linux/ipq806x/chromium/target.mk |
[PATCH v2 6/7] coreutils: Import from packages feed
I need to express a per-target dependency on the 'base64' utility, and that's seemingly impossible to do for busybox. Pull in coreutils to make that easier. Signed-off-by: Brian Norris --- * New in v2 (no changes since v1) package/utils/coreutils/Makefile | 153 ++ .../patches/001-no_docs_man_tests.patch | 93 +++ 2 files changed, 246 insertions(+) create mode 100644 package/utils/coreutils/Makefile create mode 100644 package/utils/coreutils/patches/001-no_docs_man_tests.patch diff --git a/package/utils/coreutils/Makefile b/package/utils/coreutils/Makefile new file mode 100644 index ..d1af3ce962f1 --- /dev/null +++ b/package/utils/coreutils/Makefile @@ -0,0 +1,153 @@ +# +# Copyright (C) 2008-2014 OpenWrt.org +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# + +include $(TOPDIR)/rules.mk + +PKG_NAME:=coreutils +PKG_VERSION:=9.1 +PKG_RELEASE:=1 + +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz +PKG_SOURCE_URL:=@GNU/coreutils +PKG_HASH:=61a1f410d78ba7e7f37a5a4f50e6d1320aca33375484a3255eddf17a38580423 + +PKG_MAINTAINER:=Jo-Philipp Wich +PKG_LICENSE:=GPL-3.0-or-later +PKG_LICENSE_FILES:=COPYING +PKG_CPE_ID:=cpe:/a:gnu:coreutils + +PKG_INSTALL:=1 +PKG_BUILD_PARALLEL:=1 + +include $(INCLUDE_DIR)/package.mk + +COREUTILS_APPLETS := \ + base32 base64 basename basenc b2sum cat chcon chgrp chmod chown chroot \ + cksum comm cp csplit cut date dd df dir dircolors dirname du echo env \ + expand expr factor false fmt fold groups head hostid id install join \ + kill link ln logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl \ + nohup nproc numfmt od paste pathchk pinky pr printenv printf ptx pwd \ + readlink realpath rm rmdir runcon seq sha1sum sha224sum sha256sum \ + sha384sum sha512sum shred shuf sleep sort split stat stdbuf stty sum \ + sync tac tail tee test timeout touch tr true truncate tsort tty uname \ + unexpand uniq unlink uptime users vdir wc who whoami yes + +DIR_BIN := \ + base64 cat chgrp chmod chown cp date dd df echo false kill link ln ls \ + mkdir mknod mktemp mv nice printenv pwd rm rmdir sleep stat stty sync \ + touch true uname + +DIR_USR_BIN := \ + basename chcon cksum comm cut dirname du env expand expr factor fold \ + groups head hostid id install logname md5sum mkfifo nl nohup nproc od \ + paste printf readlink realpath runcon seq sha1sum sha256sum sha512sum \ + shred shuf sort split sum tac tail tee test timeout tr truncate tty \ + unexpand uniq unlink uptime users wc who whoami yes + +DIR_USR_SBIN := \ + chroot + +# BusyBox does not provide these yet +DIR_OTHERS := \ + base32 b2sum basenc csplit dir dircolors fmt join numfmt pathchk pinky \ + pr ptx sha224sum sha384sum stdbuf tsort vdir + +$(eval $(foreach a,$(DIR_BIN),ALTS_$(a):=300:/bin/$(a):/usr/libexec/$(a)-coreutils$(newline))) +$(eval $(foreach a,$(DIR_USR_BIN),ALTS_$(a):=300:/usr/bin/$(a):/usr/libexec/$(a)-coreutils$(newline))) +$(eval $(foreach a,$(DIR_USR_SBIN),ALTS_$(a):=300:/usr/sbin/$(a):/usr/libexec/$(a)-coreutils$(newline))) + +DEPENDS_sort = +libpthread +DEPENDS_timeout = +librt +DEPENDS_expr = +libgmp +DEPENDS_factor = +libgmp +DEPENDS_cp = +libacl +DEPENDS_dir = +libacl +libcap +DEPENDS_install = +libacl +DEPENDS_ls = +libacl +libcap +DEPENDS_mv = +libacl +DEPENDS_vdir = +libacl +libcap + +FILES_stdbuf := usr/lib/coreutils/libstdbuf.so + +define Package/coreutils/Default + SECTION:=utils + CATEGORY:=Utilities + TITLE:=The GNU core utilities + URL:=http://www.gnu.org/software/coreutils/ +endef + +define Package/coreutils + $(call Package/coreutils/Default) + TITLE:=The GNU core utilities + MENU:=1 +endef + +define Package/coreutils/description + Full versions of standard GNU utilities. If an equivalent Busybox applet is + available, you should consider compiling that instead as Busybox applets are + usually smaller, at the expense of reduced functionality. +endef + +define GenPlugin + define Package/$(1) + $(call Package/coreutils/Default) + DEPENDS:=coreutils $(DEPENDS_$(2)) + TITLE:=Utility $(2) from the GNU core utilities + ALTERNATIVES:=$(ALTS_$(2)) + endef + + define Package/$(1)/description + Full version of standard GNU $(2) utility. + endef +endef + +$(foreach a,$(COREUTILS_APPLETS),$(eval $(call GenPlugin,coreutils-$(a),$(a + +CONFIGURE_VARS += \ + gl_cv_func_mbrtowc_incomplete_state=yes \ + gl_cv_func_mbrtowc_retval=yes \ + gl_cv_func_wcrtomb_retval=yes \ + ac_cv_header_selinux_context_h=no \ + ac_cv_header_selinux_flash_h=no \ + ac_cv_header_selinux_selinux_h=no \ + ac_cv_search_setfilecon=no + +CONFIGURE_ARGS += \ + --disable-xattr \ + --enable-install-program=su \ + --enable-threads=posix \ + --enable-acl \ +
[PATCH v2 5/7] ipq806x: Add kmod-sound-soc-ipq8064-storm
For IPQ8064 systems based off the "Google Storm" reference platform, such as the TP-Link OnHub. Signed-off-by: Brian Norris --- Changes in v2: * Drop CONFIG_IPQ_LCC_806X=y, and merge CONFIG_IPQ_LCC_806X=m into this package * Move package to the ipq806x target * Slim AutoLoad list; switch to AutoProbe target/linux/ipq806x/modules.mk | 29 + 1 file changed, 29 insertions(+) diff --git a/target/linux/ipq806x/modules.mk b/target/linux/ipq806x/modules.mk index 605504b0c338..a2b844d0f03c 100644 --- a/target/linux/ipq806x/modules.mk +++ b/target/linux/ipq806x/modules.mk @@ -14,3 +14,32 @@ define KernelPackage/phy-qcom-ipq806x-usb/description endef $(eval $(call KernelPackage,phy-qcom-ipq806x-usb)) + + +define KernelPackage/sound-soc-ipq8064-storm + TITLE:=Qualcomm IPQ8064 SoC support for Google Storm + DEPENDS:=@TARGET_ipq806x +kmod-sound-soc-core + KCONFIG:=\ + CONFIG_IPQ_LCC_806X \ + CONFIG_SND_SOC_QCOM \ + CONFIG_SND_SOC_STORM \ + CONFIG_SND_SOC_APQ8016_SBC=n \ + CONFIG_SND_SOC_SC7180=n + FILES:=\ + $(LINUX_DIR)/drivers/clk/qcom/lcc-ipq806x.ko \ + $(LINUX_DIR)/sound/soc/codecs/snd-soc-max98357a.ko \ + $(LINUX_DIR)/sound/soc/qcom/snd-soc-lpass-cpu.ko \ + $(LINUX_DIR)/sound/soc/qcom/snd-soc-lpass-ipq806x.ko \ + $(LINUX_DIR)/sound/soc/qcom/snd-soc-lpass-platform.ko \ + $(LINUX_DIR)/sound/soc/qcom/snd-soc-storm.ko + AUTOLOAD:=$(call AutoProbe,lcc-ipq806x \ + snd-soc-max98357a snd-soc-lpass-ipq806x snd-soc-storm) + $(call AddDepends/sound) +endef + +define KernelPackage/sound-soc-ipq8064-storm/description + Provides sound support for the Google Storm platform, with a Qualcomm IPQ8064 + SoC. +endef + +$(eval $(call KernelPackage,sound-soc-ipq8064-storm)) -- 2.39.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 4/7] ipq806x: ASoC: qcom: lpass-cpu: Fix fallback SD line index handling
This fixes device tree registration for 'qcom,lpass-cpu' as used by
qcom-ipq8064 SoCs, and allows speaker audio to function.
This patch has been submitted (and merged, for -next; likely v6.3)
upstream.
Signed-off-by: Brian Norris
---
Changes in v2:
* Add upstream (-next) notes
* Renumber to 0xx-v6.3-*.patch
...cpu-Fix-fallback-SD-line-index-handl.patch | 42 +++
1 file changed, 42 insertions(+)
create mode 100644
target/linux/ipq806x/patches-5.15/007-v6.3-ASoC-qcom-lpass-cpu-Fix-fallback-SD-line-index-handl.patch
diff --git
a/target/linux/ipq806x/patches-5.15/007-v6.3-ASoC-qcom-lpass-cpu-Fix-fallback-SD-line-index-handl.patch
b/target/linux/ipq806x/patches-5.15/007-v6.3-ASoC-qcom-lpass-cpu-Fix-fallback-SD-line-index-handl.patch
new file mode 100644
index ..099dc606114e
--- /dev/null
+++
b/target/linux/ipq806x/patches-5.15/007-v6.3-ASoC-qcom-lpass-cpu-Fix-fallback-SD-line-index-handl.patch
@@ -0,0 +1,42 @@
+From: Brian Norris
+Date: Thu, 15 Dec 2022 01:33:45 -0800
+Subject: [PATCH] ASoC: qcom: lpass-cpu: Fix fallback SD line index handling
+
+[[ Submitted upstream as:
+
https://lore.kernel.org/all/20221231061545.2110253-1-computersforpe...@gmail.com/
+ Currently queued for -next (v6.3?) as:
+ 000bca8d706d ASoC: qcom: lpass-cpu: Fix fallback SD line index handling
+]]
+
+These indices should reference the ID placed within the dai_driver
+array, not the indices of the array itself.
+
+This fixes commit 4ff028f6c108 ("ASoC: qcom: lpass-cpu: Make I2S SD
+lines configurable"), which among others, broke IPQ8064 audio
+(sound/soc/qcom/lpass-ipq806x.c) because it uses ID 4 but we'd stop
+initializing the mi2s_playback_sd_mode and mi2s_capture_sd_mode arrays
+at ID 0.
+
+Fixes: 4ff028f6c108 ("ASoC: qcom: lpass-cpu: Make I2S SD lines configurable")
+Cc:
+Signed-off-by: Brian Norris
+---
+ sound/soc/qcom/lpass-cpu.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/sound/soc/qcom/lpass-cpu.c
b/sound/soc/qcom/lpass-cpu.c
+@@ -851,10 +851,11 @@ static void of_lpass_cpu_parse_dai_data(
+ struct lpass_data *data)
+ {
+ struct device_node *node;
+- int ret, id;
++ int ret, i, id;
+
+ /* Allow all channels by default for backwards compatibility */
+- for (id = 0; id < data->variant->num_dai; id++) {
++ for (i = 0; i < data->variant->num_dai; i++) {
++ id = data->variant->dai_driver[i].id;
+ data->mi2s_playback_sd_mode[id] = LPAIF_I2SCTL_MODE_8CH;
+ data->mi2s_capture_sd_mode[id] = LPAIF_I2SCTL_MODE_8CH;
+ }
--
2.39.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 3/7] ipq806x: config-5.15: Normalize
Refresh target config with `make kernel_menuconfig`, then save the result. This drops missing symbols or otherwise accounts for defaults. It should not change any functionality. Signed-off-by: Brian Norris --- Changes in v2: * Improve description target/linux/ipq806x/config-5.15 | 20 +++- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/target/linux/ipq806x/config-5.15 b/target/linux/ipq806x/config-5.15 index 72017e7528f1..0bd6dde11cbc 100644 --- a/target/linux/ipq806x/config-5.15 +++ b/target/linux/ipq806x/config-5.15 @@ -34,13 +34,14 @@ CONFIG_ARM_CPU_SUSPEND=y # CONFIG_ARM_CPU_TOPOLOGY is not set CONFIG_ARM_GIC=y CONFIG_ARM_HAS_SG_CHAIN=y +# CONFIG_ARM_IPQ806X_FAB_DEVFREQ is not set +# CONFIG_ARM_KRAIT_CACHE_DEVFREQ is not set CONFIG_ARM_L1_CACHE_SHIFT=6 CONFIG_ARM_L1_CACHE_SHIFT_6=y CONFIG_ARM_MODULE_PLTS=y CONFIG_ARM_PATCH_IDIV=y CONFIG_ARM_PATCH_PHYS_VIRT=y # CONFIG_ARM_QCOM_CPUFREQ_HW is not set -CONFIG_ARM_QCOM_CPUFREQ_KRAIT=y CONFIG_ARM_QCOM_CPUFREQ_NVMEM=y CONFIG_ARM_QCOM_SPM_CPUIDLE=y # CONFIG_ARM_SMMU is not set @@ -98,13 +99,11 @@ CONFIG_CRC16=y # CONFIG_CRC32_SARWATE is not set CONFIG_CRC32_SLICEBY8=y CONFIG_CRC8=y -CONFIG_CRYPTO_BLAKE2S=y CONFIG_CRYPTO_DEFLATE=y CONFIG_CRYPTO_DEV_QCOM_RNG=y CONFIG_CRYPTO_DRBG=y CONFIG_CRYPTO_DRBG_HMAC=y CONFIG_CRYPTO_DRBG_MENU=y -CONFIG_CRYPTO_GF128MUL=y CONFIG_CRYPTO_HASH_INFO=y CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_HW=y @@ -112,7 +111,6 @@ CONFIG_CRYPTO_JITTERENTROPY=y CONFIG_CRYPTO_LIB_BLAKE2S_GENERIC=y CONFIG_CRYPTO_LIB_SHA256=y CONFIG_CRYPTO_LZO=y -CONFIG_CRYPTO_NULL2=y CONFIG_CRYPTO_RNG=y CONFIG_CRYPTO_RNG2=y CONFIG_CRYPTO_SHA256=y @@ -127,8 +125,6 @@ CONFIG_DEVFREQ_GOV_PASSIVE=y # CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND is not set # CONFIG_DEVFREQ_GOV_USERSPACE is not set # CONFIG_DEVFREQ_THERMAL is not set -# CONFIG_ARM_KRAIT_CACHE_DEVFREQ is not set -# CONFIG_ARM_IPQ806X_FAB_DEVFREQ is not set CONFIG_DMADEVICES=y CONFIG_DMA_ENGINE=y CONFIG_DMA_OF=y @@ -143,6 +139,7 @@ CONFIG_DWMAC_IPQ806X=y CONFIG_DYNAMIC_DEBUG=y CONFIG_EDAC_ATOMIC_SCRUB=y CONFIG_EDAC_SUPPORT=y +CONFIG_ETHERNET_PACKET_MANGLE=y CONFIG_FIXED_PHY=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_FWNODE_MDIO=y @@ -152,10 +149,12 @@ CONFIG_GENERIC_BUG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CPU_AUTOPROBE=y +CONFIG_GENERIC_CPU_VULNERABILITIES=y CONFIG_GENERIC_EARLY_IOREMAP=y CONFIG_GENERIC_GETTIMEOFDAY=y CONFIG_GENERIC_IDLE_POLL_SETUP=y CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y +CONFIG_GENERIC_IRQ_MIGRATION=y CONFIG_GENERIC_IRQ_MULTI_HANDLER=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_SHOW_LEVEL=y @@ -173,6 +172,7 @@ CONFIG_GENERIC_STRNCPY_FROM_USER=y CONFIG_GENERIC_STRNLEN_USER=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_VDSO_32=y +CONFIG_GLOB=y CONFIG_GPIOLIB_IRQCHIP=y CONFIG_GPIO_CDEV=y CONFIG_GRO_CELLS=y @@ -185,6 +185,7 @@ CONFIG_HAS_IOPORT_MAP=y CONFIG_HAVE_SMP=y CONFIG_HIGHMEM=y # CONFIG_HIGHPTE is not set +CONFIG_HOTPLUG_CPU=y CONFIG_HWMON=y CONFIG_HWSPINLOCK=y CONFIG_HWSPINLOCK_QCOM=y @@ -214,12 +215,12 @@ CONFIG_IRQ_FASTEOI_HIERARCHY_HANDLERS=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_IRQ_WORK=y CONFIG_KMAP_LOCAL=y +CONFIG_KMAP_LOCAL_NON_LINEAR_PTE_ARRAY=y CONFIG_KPSS_XCC=y CONFIG_KRAITCC=y CONFIG_KRAIT_CLOCKS=y CONFIG_KRAIT_L2_ACCESSORS=y CONFIG_LIBFDT=y -CONFIG_LLD_VERSION=0 CONFIG_LOCK_DEBUGGING_SUPPORT=y CONFIG_LOCK_SPIN_ON_OWNER=y CONFIG_LZO_COMPRESS=y @@ -300,6 +301,7 @@ CONFIG_NR_CPUS=2 CONFIG_NVMEM=y CONFIG_NVMEM_QCOM_QFPROM=y # CONFIG_NVMEM_SPMI_SDAM is not set +CONFIG_NVMEM_SYSFS=y CONFIG_OF=y CONFIG_OF_ADDRESS=y CONFIG_OF_EARLY_FLATTREE=y @@ -308,7 +310,6 @@ CONFIG_OF_GPIO=y CONFIG_OF_IRQ=y CONFIG_OF_KOBJ=y CONFIG_OF_MDIO=y -CONFIG_OF_NET=y CONFIG_OLD_SIGACTION=y CONFIG_OLD_SIGSUSPEND3=y CONFIG_PADATA=y @@ -397,7 +398,7 @@ CONFIG_QCOM_SCM=y # CONFIG_QCOM_SCM_DOWNLOAD_MODE_DEFAULT is not set CONFIG_QCOM_SMEM=y # CONFIG_QCOM_SMSM is not set -# CONFIG_QCOM_SOCINFO is not set +CONFIG_QCOM_SOCINFO=y CONFIG_QCOM_TCSR=y CONFIG_QCOM_TSENS=y CONFIG_QCOM_WDT=y @@ -452,6 +453,7 @@ CONFIG_SMP_ON_UP=y # CONFIG_SM_VIDEOCC_8150 is not set # CONFIG_SM_VIDEOCC_8250 is not set CONFIG_SOCK_RX_QUEUE_MAPPING=y +CONFIG_SOC_BUS=y CONFIG_SPARSE_IRQ=y CONFIG_SPI=y CONFIG_SPI_MASTER=y -- 2.39.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 2/7] ipq806x: Point to externally compiled dtbs in recipes
Similar to commit 4d8b42d8a777 ("ipq40xx: point to externally compiled
dtbs in recipes").
Currently, we patch our DTS files into the kernel source tree, so the
kernel build process will produce DTBs for us. The kernel-to-DTS
dependency can cause buildroot to perform excessive rebuilds of the
kernel though, which slows down device development iteration.
Buildroot also compiles DTBs on its own, to
$(KDIR)/image-$(DEVICE_DTS).dtb. With small adjustments, we can leverage
this, and stop patching DTS files into the kernel Makefile at the same
time.
Signed-off-by: Brian Norris
---
Changes in v2:
* Improve commit description
target/linux/ipq806x/image/Makefile | 5 +--
.../0069-arm-boot-add-dts-files.patch | 43 ---
.../0069-arm-boot-add-dts-files.patch | 43 ---
3 files changed, 2 insertions(+), 89 deletions(-)
delete mode 100644
target/linux/ipq806x/patches-5.10/0069-arm-boot-add-dts-files.patch
delete mode 100644
target/linux/ipq806x/patches-5.15/0069-arm-boot-add-dts-files.patch
diff --git a/target/linux/ipq806x/image/Makefile
b/target/linux/ipq806x/image/Makefile
index f4f829b35c65..8c1fc88010cd 100644
--- a/target/linux/ipq806x/image/Makefile
+++ b/target/linux/ipq806x/image/Makefile
@@ -5,7 +5,6 @@ include $(INCLUDE_DIR)/image.mk
define Device/Default
PROFILES := Default
- KERNEL_DEPENDS = $$(wildcard $(DTS_DIR)/$$(DEVICE_DTS).dts)
KERNEL_LOADADDR = 0x42208000
DEVICE_DTS = $$(SOC)-$(lastword $(subst _, ,$(1)))
DEVICE_DTS_CONFIG := config@1
@@ -22,13 +21,13 @@ endef
define Device/FitImage
KERNEL_SUFFIX := -fit-uImage.itb
- KERNEL = kernel-bin | gzip | fit gzip $$(DTS_DIR)/$$(DEVICE_DTS).dtb
+ KERNEL = kernel-bin | gzip | fit gzip $$(KDIR)/image-$$(DEVICE_DTS).dtb
KERNEL_NAME := Image
endef
define Device/FitImageLzma
KERNEL_SUFFIX := -fit-uImage.itb
- KERNEL = kernel-bin | lzma | fit lzma $$(DTS_DIR)/$$(DEVICE_DTS).dtb
+ KERNEL = kernel-bin | lzma | fit lzma $$(KDIR)/image-$$(DEVICE_DTS).dtb
KERNEL_NAME := Image
endef
diff --git
a/target/linux/ipq806x/patches-5.10/0069-arm-boot-add-dts-files.patch
b/target/linux/ipq806x/patches-5.10/0069-arm-boot-add-dts-files.patch
deleted file mode 100644
index 4c42f40e3d78..
--- a/target/linux/ipq806x/patches-5.10/0069-arm-boot-add-dts-files.patch
+++ /dev/null
@@ -1,43 +0,0 @@
-From 8f68331e14dff9a101f2d0e1d6bec84a031f27ee Mon Sep 17 00:00:00 2001
-From: John Crispin
-Date: Thu, 9 Mar 2017 11:03:18 +0100
-Subject: [PATCH 69/69] arm: boot: add dts files
-
-Signed-off-by: John Crispin
- arch/arm/boot/dts/Makefile | 8
- 1 file changed, 8 insertions(+)
-
a/arch/arm/boot/dts/Makefile
-+++ b/arch/arm/boot/dts/Makefile
-@@ -909,8 +909,30 @@ dtb-$(CONFIG_ARCH_QCOM) += \
- qcom-ipq4019-ap.dk04.1-c3.dtb \
- qcom-ipq4019-ap.dk07.1-c1.dtb \
- qcom-ipq4019-ap.dk07.1-c2.dtb \
-+ qcom-ipq8062-wg2600hp3.dtb \
- qcom-ipq8064-ap148.dtb \
- qcom-ipq8064-rb3011.dtb \
-+ qcom-ipq8064-c2600.dtb \
-+ qcom-ipq8064-d7800.dtb \
-+ qcom-ipq8064-db149.dtb \
-+ qcom-ipq8064-ap161.dtb \
-+ qcom-ipq8064-ea7500-v1.dtb \
-+ qcom-ipq8064-ea8500.dtb \
-+ qcom-ipq8064-g10.dtb \
-+ qcom-ipq8064-r7500.dtb \
-+ qcom-ipq8064-r7500v2.dtb \
-+ qcom-ipq8064-unifi-ac-hd.dtb \
-+ qcom-ipq8064-wg2600hp.dtb \
-+ qcom-ipq8064-wpq864.dtb \
-+ qcom-ipq8064-wxr-2533dhp.dtb \
-+ qcom-ipq8065-nbg6817.dtb \
-+ qcom-ipq8065-r7800.dtb \
-+ qcom-ipq8065-rt4230w-rev6.dtb \
-+ qcom-ipq8065-tr4400-v2.dtb \
-+ qcom-ipq8065-xr500.dtb \
-+ qcom-ipq8068-ecw5410.dtb \
-+ qcom-ipq8068-mr42.dtb \
-+ qcom-ipq8068-mr52.dtb \
- qcom-msm8660-surf.dtb \
- qcom-msm8960-cdp.dtb \
- qcom-msm8974-fairphone-fp2.dtb \
diff --git
a/target/linux/ipq806x/patches-5.15/0069-arm-boot-add-dts-files.patch
b/target/linux/ipq806x/patches-5.15/0069-arm-boot-add-dts-files.patch
deleted file mode 100644
index 698df248fb57..
--- a/target/linux/ipq806x/patches-5.15/0069-arm-boot-add-dts-files.patch
+++ /dev/null
@@ -1,43 +0,0 @@
-From 8f68331e14dff9a101f2d0e1d6bec84a031f27ee Mon Sep 17 00:00:00 2001
-From: John Crispin
-Date: Thu, 9 Mar 2017 11:03:18 +0100
-Subject: [PATCH 69/69] arm: boot: add dts files
-
-Signed-off-by: John Crispin
- arch/arm/boot/dts/Makefile | 8
- 1 file changed, 8 insertions(+)
-
a/arch/arm/boot/dts/Makefile
-+++ b/arch/arm/boot/dts/Makefile
-@@ -957,8 +957,30 @@ dtb-$(CONFIG_ARCH_QCOM) += \
- qcom-ipq4019-ap.dk04.1-c3.dtb \
- qcom-ipq4019-ap.dk07.1-c1.dtb \
- qcom-ipq4019-ap.dk07.1-c2.dtb \
-+ qcom-ipq8062-wg2600hp3.dtb \
- qcom-ipq8064-ap148.dtb \
- qcom-ipq8064-rb3011.dtb \
-+ qcom-ipq8064-c2600.dtb \
-+ qcom-ipq8064-d7800.dtb \
-+ qcom-ipq8064-db149.dtb \
-+ qcom-ipq8064-ap161.dtb
[PATCH v2 1/7] base-files: Remove nand.sh dependency from emmc upgrade
emmc_do_upgrade() relies on identify() from the nand.sh upgrade helper.
This only works because FEATURES=emmc targets also tend to include
FEATURES=nand.
Rename identify_magic() to identify_magic_long() to match the common.sh
style and make it clear it pairs with other *_long() variants (and not,
say *_word()).
Signed-off-by: Brian Norris
---
(no changes since v1)
.../base-files/files/lib/upgrade/common.sh| 27
package/base-files/files/lib/upgrade/emmc.sh | 2 +-
package/base-files/files/lib/upgrade/nand.sh | 32 ++-
3 files changed, 30 insertions(+), 31 deletions(-)
diff --git a/package/base-files/files/lib/upgrade/common.sh
b/package/base-files/files/lib/upgrade/common.sh
index 5af061f6a439..53b8865a5788 100644
--- a/package/base-files/files/lib/upgrade/common.sh
+++ b/package/base-files/files/lib/upgrade/common.sh
@@ -127,6 +127,33 @@ get_magic_fat32() {
(get_image "$@" | dd bs=1 count=5 skip=82) 2>/dev/null
}
+identify_magic_long() {
+ local magic=$1
+ case "$magic" in
+ "55424923")
+ echo "ubi"
+ ;;
+ "31181006")
+ echo "ubifs"
+ ;;
+ "68737173")
+ echo "squashfs"
+ ;;
+ "d00dfeed")
+ echo "fit"
+ ;;
+ "4349"*)
+ echo "combined"
+ ;;
+ "1f8b"*)
+ echo "gzip"
+ ;;
+ *)
+ echo "unknown $magic"
+ ;;
+ esac
+}
+
part_magic_efi() {
local magic=$(get_magic_gpt "$@")
[ "$magic" = "EFI PART" ]
diff --git a/package/base-files/files/lib/upgrade/emmc.sh
b/package/base-files/files/lib/upgrade/emmc.sh
index c3b02864aa91..49cffe1c658b 100644
--- a/package/base-files/files/lib/upgrade/emmc.sh
+++ b/package/base-files/files/lib/upgrade/emmc.sh
@@ -58,7 +58,7 @@ emmc_copy_config() {
}
emmc_do_upgrade() {
- local file_type=$(identify $1)
+ local file_type=$(identify_magic_long "$(get_magic_long "$1")")
case "$file_type" in
"fit") emmc_upgrade_fit $1;;
diff --git a/package/base-files/files/lib/upgrade/nand.sh
b/package/base-files/files/lib/upgrade/nand.sh
index a8e3cab0b8b1..a1dbd6e2663d 100644
--- a/package/base-files/files/lib/upgrade/nand.sh
+++ b/package/base-files/files/lib/upgrade/nand.sh
@@ -65,40 +65,12 @@ get_magic_long_tar() {
(tar xO${3}f "$1" "$2" | dd bs=4 count=1 | hexdump -v -n 4 -e '1/1
"%02x"') 2> /dev/null
}
-identify_magic() {
- local magic=$1
- case "$magic" in
- "55424923")
- echo "ubi"
- ;;
- "31181006")
- echo "ubifs"
- ;;
- "68737173")
- echo "squashfs"
- ;;
- "d00dfeed")
- echo "fit"
- ;;
- "4349"*)
- echo "combined"
- ;;
- "1f8b"*)
- echo "gzip"
- ;;
- *)
- echo "unknown $magic"
- ;;
- esac
-}
-
-
identify() {
- identify_magic $(nand_get_magic_long "$@")
+ identify_magic_long $(nand_get_magic_long "$@")
}
identify_tar() {
- identify_magic $(get_magic_long_tar "$@")
+ identify_magic_long $(get_magic_long_tar "$@")
}
identify_if_gzip() {
--
2.39.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
