[PATCH] base-file: remove unused 'bootdisk' variable
This was left obsolete in:
4a0688ed7153 base-files: remove block2mtd checks from sysupgrade
Signed-off-by: Brian Norris
---
package/base-files/files/lib/upgrade/common.sh | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/package/base-files/files/lib/upgrade/common.sh
b/package/base-files/files/lib/upgrade/common.sh
index c28bae48a15c..0c78974d7c6b 100644
--- a/package/base-files/files/lib/upgrade/common.sh
+++ b/package/base-files/files/lib/upgrade/common.sh
@@ -149,7 +149,7 @@ part_magic_fat() {
}
export_bootdevice() {
- local cmdline bootdisk rootpart uuid blockdev uevent line class
+ local cmdline rootpart uuid blockdev uevent line class
local MAJOR MINOR DEVNAME DEVTYPE
if read cmdline < /proc/cmdline; then
@@ -160,12 +160,6 @@ export_bootdevice() {
;;
esac
- case "$bootdisk" in
- /dev/*)
- uevent="/sys/class/block/${bootdisk##*/}/uevent"
- ;;
- esac
-
case "$rootpart" in
PARTUUID=[a-f0-9][a-f0-9][a-f0-9][a-f0-9][a-f0-9][a-f0-9][a-f0-9][a-f0-9]-[a-f0-9][a-f0-9])
uuid="${rootpart#PARTUUID=}"
--
2.29.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 4/4] ipq40xx: add target for Google WiFi (Gale)
Google WiFi (codename: Gale) is an IPQ4019-based AP, with 2 Ethernet
ports, 2x2 2.4+5GHz WiFi, 512 MB RAM, 4 GB eMMC, and a USB type C port.
In its stock configuration, it runs a Chromium OS-based system, but you
wouldn't know it, since you can only manage it via a "cloud" +
mobile-app system.
The "v2" label is coded into the bootloader, which prefers the
"google,gale-v2" compatible string. I believe "v1" must have been
pre-release hardware.
Note: this is *not* the Google Nest WiFi, released in 2019.
I include "factory.bin" support, where we generate a GPT-based disk
image with 3 partitions -- a spare FAT partition, a kernel partition
(using the custom "Chrome OS kernel" GUID type) and a root filesystem
partition. See below for flashing instructions.
Sysupgrade is only partially working.
"FEATURES=boot-part rootfs-part" is required to get kernel and rootfs
partition sizes established. This adds extra (unused) configuration
parameters for other ipq40xx targets, so I'm not sure if this is the
"right" thing to do either.
Flashing instructions
=
[ NB: you may still need to tweak which drivers are built-in, if you
want to boot from a USB disk. ]
Chrome OS systems allow booting custom images only when transitioned
into Developer Mode. Existing sources document how to enter Developer
Mode on a Google WiFi system:
https://github.com/marcosscriven/galeforce#how-to-apply-an-image
The OpenWRT-relevant summary:
1. Flash factory.bin to a USB storage device (e.g., with 'dd')
2. Pop off the case
3. Attach a USB-C hub with power delivery
4. Press the reset button on the back until light blinks orange (>16
seconds)
5. Once blinking orange, hit the tiny bubble switch (SW7) found on the
board
6. Device will start blinking purple and restart
7. Wait until device restarts and starts blinking purple again
7. Plug in USB stick
8. Hit bubble switch again
The device should boot to OpenWRT.
If you want to persist to the eMMC, flash factory.bin to /dev/mmcblk0.
Features
I've tested:
* Ethernet, both WAN and LAN ports
* eMMC
* USB-C (hub, power-delivery, peripherals)
* LED0 (R/G/B)
* WiFi (limited testing)
* SPI flash
* Serial console: once in developer mode, console can be accessed via
the USB-C port with SuzyQable, or other similar "Closed Case
Debugging" tools:
https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/master/docs/ccd.md#suzyq-suzyqable
Not tested:
* TPM
* LED1, LED2: I'm not even confident they are actually populated
anywhere
Known not working:
* Reboot: this requires some additional TrustZone / SCM
configuration to disable Qualcomm's SDI. I have a proposal upstream,
and based on IRC chats, this might be acceptable with additional DT
logic:
[RFC PATCH] firmware: qcom_scm: disable SDI at boot
https://lore.kernel.org/linux-arm-msm/20200721080054.2803881-1-computersforpe...@gmail.com/
* SMP: enabling secondary CPUs doesn't currently work using the stock
bootloader, as the qcom_scm driver assumes newer features than this
TrustZone firmware has. I posted notes here:
[RFC] qcom_scm: IPQ4019 firmware does not support atomic API?
https://lore.kernel.org/linux-arm-msm/20200913201608.GA3162100@bDebian/
* There's a single external button, and a few useful internal GPIO
switches. I haven't hooked them up.
Additional notes
Much of the DTS is pulled from the Chrome OS kernel 3.18 branch, which
the manufacturer image uses.
Note: the manufacturer bootloader knows how to patch in calibration data
via the wifi{0,1} aliases in the DTB, so while these properties aren't
present in the DTS, they are available at runtime:
# ls -l
/sys/firmware/devicetree/base/soc/wifi@a*/qcom,ath10k-pre-calibration-data
-r--r--r--1 root root 12064 Jul 15 19:11
/sys/firmware/devicetree/base/soc/wifi@a00/qcom,ath10k-pre-calibration-data
-r--r--r--1 root root 12064 Jul 15 19:11
/sys/firmware/devicetree/base/soc/wifi@a80/qcom,ath10k-pre-calibration-data
Ethernet MAC addresses are similarly patched in via the ethernet{0,1} aliases.
Signed-off-by: Brian Norris
---
v2:
* include more verbose flashing instructions
* rename to "google_wifi" in most contexts, with "gale" only used as a
secondary name, so the bootloader can find the DTB
* other formalities (alphabetization, etc.)
---
target/linux/ipq40xx/Makefile | 2 +-
.../ipq40xx/base-files/etc/board.d/02_network | 1 +
.../base-files/lib/upgrade/platform.sh| 16 +
.../arch/arm/boot/dts/qcom-ipq4019-wifi.dts | 402 ++
target/linux/ipq40xx/image/Makefile | 13 +
.../901-arm-boot-add-dts-files.patch | 3 +-
6 files changed, 435 insertions(+), 2 deletions(-)
create mode 100644
target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-wifi.dts
diff --git a/target/linux/ipq40xx/Makefile b/target/linux/ipq40xx/Makefile
index
[PATCH v2 2/4] firmware-utils/cros-vbutil: add Chrome OS vboot kernel-signing utility
Chrom{ium,e} OS based devices use a Coreboot+Depthcharge-based firmware,
which verifies and loads a kernel packed in a verified-boot payload. The
verification tooling (both for creating and verifying payloads) is
implemented here:
https://chromium.googlesource.com/chromiumos/platform/vboot_reference
Devices running such bootloaders also tend to support a "developer
mode," where a device can be unlocked to run arbitrary kernel payloads,
using the same verified-boot format plus well-known developer keys. More
information can be found here:
https://chromium.googlesource.com/chromiumos/docs/+/master/developer_mode.md
Rather than build and package the vboot_reference utilities as part of
the base OpenWRT tools, I chose to reimplement just the portion that's
required for signing payloads. I also embed the developer key directly
in the source for convenience, though it's certainly possible to
provide other keys too, if one were to build their own firmware that
accepts it.
This tool is essentially the same as running something like this, using
the Chromium OS tooling:
vbutil_kernel --pack kernel_partition.bin \
--keyblock /usr/share/vboot/devkeys/kernel.keyblock \
--signprivate /usr/share/vboot/devkeys/kernel_data_key.vbprivk \
--version 1 \
--vmlinuz kernel.bin \
--bootloader zero.txt \
--config commnad_line.txt \
--arch ${ARCH}
I have also packaged the Chromium OS vboot_reference tooling for the
packages feed, as it can be useful beyond simply creating a bootable
image (e.g., manipulating Chromium OS specific GPT attributes, handling
other NVRAM attributes, vboot packing/unpacking/verifying):
https://github.com/openwrt/packages/pull/12829
The vboot_reference tools are released by Google under a BSD 3-clause
license. I've provided the original license text as well as a GPL-2
notice for my modifications (essentially just borrowing the data
structures and rewriting everything else).
Signed-off-by: Brian Norris
---
tools/firmware-utils/Makefile | 1 +
tools/firmware-utils/src/cros-vbutil.c | 609 +
2 files changed, 610 insertions(+)
create mode 100644 tools/firmware-utils/src/cros-vbutil.c
diff --git a/tools/firmware-utils/Makefile b/tools/firmware-utils/Makefile
index 6074ecc608d0..f4f9f233cdc2 100644
--- a/tools/firmware-utils/Makefile
+++ b/tools/firmware-utils/Makefile
@@ -30,6 +30,7 @@ define Host/Compile
$(call cc,buffalo-enc buffalo-lib,-Wall)
$(call cc,buffalo-tag buffalo-lib,-Wall)
$(call cc,buffalo-tftp buffalo-lib,-Wall)
+ $(call cc,cros-vbutil,-lcrypto -lpthread)
$(call cc,dgfirmware)
$(call cc,dgn3500sum,-Wall)
$(call cc,dns313-header,-Wall)
diff --git a/tools/firmware-utils/src/cros-vbutil.c
b/tools/firmware-utils/src/cros-vbutil.c
new file mode 100644
index ..13ba9a3245b3
--- /dev/null
+++ b/tools/firmware-utils/src/cros-vbutil.c
@@ -0,0 +1,609 @@
+/*
+ * cros-vbutil - Tool for signing kernels using the Chromium OS verified boot
+ * format, using widely-shared "developer" keys. The output of this tool is
+ * intended to be written to a GPT partition of type "Chrome OS Kernel", such
+ * that a Chromium OS bootloader can find it.
+ *
+ * Much of this is adapted from Google's vboot_reference project found here:
+ * https://chromium.googlesource.com/chromiumos/platform/vboot_reference
+ *
+ * Copyright (c) 2010 The Chromium OS Authors. All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are
+ * met:
+ *
+ ** Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ ** Redistributions in binary form must reproduce the above
+ * copyright notice, this list of conditions and the following disclaimer
+ * in the documentation and/or other materials provided with the
+ * distribution.
+ ** Neither the name of Google Inc. nor the names of its
+ * contributors may be used to endorse or promote products derived from
+ * this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ *
[PATCH v2 3/4] image-commands: support Chromium OS image-type creation
See the previous patches, which implemented the cros-vbutil
verified-boot payload-packing tool, and extended ptgen for the CrOS
kernel partition type. With these, it's now possible to package kernel +
rootfs to make disk images that can boot a Chrome OS-based system (e.g.,
Chromebooks, or even a few AP models).
gen_image_vboot.sh borrows a bit of structure from gen_image_generic.sh,
but I didn't feel it fit well to try and add new flags to the latter,
given the difference in its FAT kernel packaging and our raw kernel
partition packing.
Signed-off-by: Brian Norris
---
include/image-commands.mk | 18 ++
.../base-files/files/lib/upgrade/common.sh| 4 ++-
scripts/gen_image_vboot.sh| 36 +++
3 files changed, 57 insertions(+), 1 deletion(-)
create mode 100755 scripts/gen_image_vboot.sh
diff --git a/include/image-commands.mk b/include/image-commands.mk
index 979eafb15734..f02d8e79fce6 100644
--- a/include/image-commands.mk
+++ b/include/image-commands.mk
@@ -172,6 +172,24 @@ define Build/fit
@mv $@.new $@
endef
+define Build/cros-image
+ $(SCRIPT_DIR)/gen_image_vboot.sh \
+ $@ \
+ $(CONFIG_TARGET_KERNEL_PARTSIZE) \
+ $(CONFIG_TARGET_KERNEL_PARTSIZE) $(IMAGE_KERNEL) \
+ $(CONFIG_TARGET_ROOTFS_PARTSIZE) $(IMAGE_ROOTFS)
+endef
+
+# NB: Chrome OS bootloaders replace the '%U' in command lines with the UUID of
+# the kernel partition it chooses to boot from. This gives a flexible way to
+# consistently build and sign kernels that always use the subsequent
+# (PARTNROFF=1) partition as their rootfs.
+define Build/cros-vboot
+ $(STAGING_DIR_HOST)/bin/cros-vbutil \
+ -k $@ -c "root=PARTUUID=%U/PARTNROFF=1" -o $@.new
+ @mv $@.new $@
+endef
+
define Build/gzip
gzip -f -9n -c $@ $(1) > $@.new
@mv $@.new $@
diff --git a/package/base-files/files/lib/upgrade/common.sh
b/package/base-files/files/lib/upgrade/common.sh
index c28bae48a15c..a2ee8d1675a6 100644
--- a/package/base-files/files/lib/upgrade/common.sh
+++ b/package/base-files/files/lib/upgrade/common.sh
@@ -178,9 +178,11 @@ export_bootdevice() {
fi
done
;;
+
PARTUUID=----??01/PARTNROFF=1 | \
PARTUUID=----??02)
uuid="${rootpart#PARTUUID=}"
- uuid="${uuid%02}00"
+ uuid="${uuid%/PARTNROFF=1}"
+ uuid="${uuid%0?}00"
for disk in $(find /dev -type b); do
set -- $(dd if=$disk bs=1 skip=568
count=16 2>/dev/null | hexdump -v -e '8/1 "%02x "" "2/1 "%02x""-"6/1 "%02x"')
if [ "$4$3$2$1-$6$5-$8$7-$9" = "$uuid"
]; then
diff --git a/scripts/gen_image_vboot.sh b/scripts/gen_image_vboot.sh
new file mode 100755
index ..ae267ba3fbb9
--- /dev/null
+++ b/scripts/gen_image_vboot.sh
@@ -0,0 +1,36 @@
+#!/usr/bin/env bash
+# Copyright (C) 2021 OpenWrt.org
+set -e -x
+[ $# == 6 ] || {
+echo "SYNTAX: $0
"
+exit 1
+}
+
+OUTPUT="$1"
+BOOTPARTSIZE="$2"
+KERNELSIZE="$3"
+KERNELIMAGE="$4"
+ROOTFSSIZE="$5"
+ROOTFSIMAGE="$6"
+
+rm -f "${OUTPUT}"
+
+head=16
+sect=63
+
+# create partition table
+set $(ptgen -o "${OUTPUT}" -h $head -s $sect -g -p ${BOOTPARTSIZE}m -T
cros_kernel -p ${KERNELSIZE}m -p ${ROOTFSSIZE}m)
+
+BOOTOFFSET="$(($1 / 512))"
+BOOTSIZE="$2"
+KERNELOFFSET="$(($3 / 512))"
+KERNELSIZE="$4"
+ROOTFSOFFSET="$(($5 / 512))"
+ROOTFSSIZE="$(($6 / 512))"
+
+mkfs.fat -n boot -C "${OUTPUT}.boot" -S 512 "$((BOOTSIZE / 1024))"
+
+dd if="${OUTPUT}.boot" of="${OUTPUT}" bs=512 seek="${BOOTOFFSET}" conv=notrunc
+rm -f "${OUTPUT}.boot"
+dd if="${KERNELIMAGE}" of="${OUTPUT}" bs=512 seek="${KERNELOFFSET}"
conv=notrunc
+dd if="${ROOTFSIMAGE}" of="${OUTPUT}" bs=512 seek="${ROOTFSOFFSET}"
conv=notrunc
--
2.29.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 0/4] Add support for Chromium OS and Google WiFi
Hi,
This series adds support for both Chromium OS (or particularly, its
kernel-payload signing and disk layout) and for a device using it (the
first generation Google WiFi).
Google WiFi (code-named "Gale") is an IPQ4019-based AP. Its hardware is
decently supported by the existing ipq40xx target -- see patch 4 for
more notes. Notably missing: reboot does not work properly -- I have
some separate TrustZone/SCM-related patches I'd like to clean up to
enable this later.
I sent v1 as an "RFC" here:
http://patchwork.ozlabs.org/project/openwrt/patch/20200718205148.1743807-6-computersforpe...@gmail.com/
and since I got only mechanical feedback for the last patch, I'm now
sending a non-RFC. I leave some notes about my implementation choices
below, for reference.
Changes since v1:
* 1 patch was already merged
* patch 4 is rebased, improved (see patch 4 for notes)
Chromium OS (the open-source OS on which Google builds its Chrome OS) --
"CrOS" for short -- typically boots via Coreboot, plus Depthcharge as a
second stage. Such bootloaders utilize a verified boot toolkit [1] to
verify each subsequent stage. Of note:
1. The kernel should be placed in a GPT partition with a custom "Chrome
OS kernel" GUID type and a few custom flags (to manage the A/B
OS updates employed by Chromium OS). CrOS vboot provides the `cgpt`
utility for creating and managing such partitions.
2. That partition should hold a vboot payload, signed and packaged per
the format documented and implemented at [1]. Using the vboot
utilities, this involves the `vbutil_kernel --pack ...` command.
I chose:
(a) To extend OpenWRT's ptgen to help customize partition types,
instead of packaging vboot's `cgpt`.
(b) To adapt and reimplement the `vbutil_kernel` command as a custom
`cros-vbutil` utility, rather than packaging Google's utility.
(c) To add kernel and rootfs partition-size parameters (for customizing
my GPT), but it's not clear to me if this fits well into the
existing ipq40xx target, or if it should be done differently.
For some alternatives (especially on (b)), I did package
futility/vbutil_kernel here:
https://github.com/openwrt/packages/pull/12829
I could adapt this into tools/ instead, so OpenWRT doesn't have to carry
my re-implementation. This would carry some extra build complexity,
as the vboot tools are >10,000 lines of code, compared to my
reimplementation of a few hundred lines. The library dependencies are
similar (mostly just crypto/ssl, and potentially libuuid (for GPT)), as
the vboot project tries to keep the code semi-portable / reusable.
Packaging the vboot utilities might give us some future flexibility, if
the formats grow and change for future systems. So far, I think the
format has been pretty stable. Also, there are potentially some quirks I
missed in my port related the ${ARCH} -- I ported the ARM support, but
there may be some small tweaks I missed that are applicable only to x86
systems.
For (c): adding this to the common ipq40xx target means that there will
be a new CONFIG_TARGET_KERNEL_PARTSIZE and
CONFIG_TARGET_ROOTFS_PARTSIZE, which are only applicable to a single
device but are present for all:
FEATURES:=boot-part rootfs-part
Regards,
Brian
[1] https://chromium.googlesource.com/chromiumos/platform/vboot_reference
Brian Norris (4):
firmware-utils/ptgen: add Chromium OS kernel partition support
firmware-utils/cros-vbutil: add Chrome OS vboot kernel-signing utility
image-commands: support Chromium OS image-type creation
ipq40xx: add target for Google WiFi (Gale)
include/image-commands.mk | 18 +
.../base-files/files/lib/upgrade/common.sh| 4 +-
scripts/gen_image_vboot.sh| 36 ++
target/linux/ipq40xx/Makefile | 2 +-
.../ipq40xx/base-files/etc/board.d/02_network | 1 +
.../base-files/lib/upgrade/platform.sh| 16 +
.../arch/arm/boot/dts/qcom-ipq4019-wifi.dts | 402
target/linux/ipq40xx/image/Makefile | 13 +
.../901-arm-boot-add-dts-files.patch | 3 +-
tools/firmware-utils/Makefile | 1 +
tools/firmware-utils/src/cros-vbutil.c| 609 ++
tools/firmware-utils/src/ptgen.c | 39 +-
12 files changed, 1138 insertions(+), 6 deletions(-)
create mode 100755 scripts/gen_image_vboot.sh
create mode 100644
target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-wifi.dts
create mode 100644 tools/firmware-utils/src/cros-vbutil.c
--
2.29.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 1/4] firmware-utils/ptgen: add Chromium OS kernel partition support
Chrom{ium,e} OS (shortened as "CrOS") bootloaders use a custom GPT
partition type to locate their kernel(s), with custom attributes for
noting properties around which partition(s) should be active and how
many times they've been tried as part of their A/B in-place upgrade
system.
OpenWRT doesn't use A/B updates for upgrades (instead, just shutting
things down far enough to reprogram the necessary partitions), so all we
need to do is tell the bootloader which one is the kernel partition, and
how to use it (i.e., set the "successful" and "priority" attributes).
ptgen already supports some basic GPT partition creation, so just
add support for a '-T ' argument. Currently, this
only supports '-T cros_kernel', but it could be extended if there are
other GPT partition types needed.
For GPT attribute and GUID definitions, see the CrOS verified boot
sources:
https://chromium.googlesource.com/chromiumos/platform/vboot_reference/+/refs/heads/master/firmware/lib/cgptlib/include/cgptlib_internal.h
https://chromium.googlesource.com/chromiumos/platform/vboot_reference/+/refs/heads/master/firmware/include/gpt.h
The GUID is also recognized in fdisk, and likely other utilities, but
creation/manipulation is typically done via the 'cgpt' utility, provided
as part of the vboot_reference project.
Signed-off-by: Brian Norris
---
tools/firmware-utils/src/ptgen.c | 39 +---
1 file changed, 36 insertions(+), 3 deletions(-)
diff --git a/tools/firmware-utils/src/ptgen.c b/tools/firmware-utils/src/ptgen.c
index 223ee295611f..bc1da6d64061 100644
--- a/tools/firmware-utils/src/ptgen.c
+++ b/tools/firmware-utils/src/ptgen.c
@@ -80,6 +80,10 @@ typedef struct {
GUID_INIT( 0x21686148, 0x6449, 0x6E6F, \
0x74, 0x4E, 0x65, 0x65, 0x64, 0x45, 0x46, 0x49)
+#define GUID_PARTITION_CHROME_OS_KERNEL \
+ GUID_INIT( 0xFE3A2A5D, 0x4F32, 0x41A7, \
+ 0xB7, 0x25, 0xAC, 0xCC, 0x32, 0x85, 0xA3, 0x09)
+
#define GPT_HEADER_SIZE 92
#define GPT_ENTRY_SIZE 128
#define GPT_ENTRY_MAX 128
@@ -109,6 +113,9 @@ struct partinfo {
unsigned long start;
unsigned long size;
int type;
+ bool has_gtype;
+ guid_t gtype; /* GPT partition type */
+ uint64_t gattr; /* GPT partition attributes */
};
/* GPT Partition table header */
@@ -248,6 +255,19 @@ static inline int guid_parse(char *buf, guid_t *guid)
return 0;
}
+/* Map GPT partition types to partition GUIDs. */
+static inline bool parse_gpt_parttype(const char *type, struct partinfo *part)
+{
+ if (!strcmp(type, "cros_kernel")) {
+ part->has_gtype = true;
+ part->gtype = GUID_PARTITION_CHROME_OS_KERNEL;
+ part->gattr = (1ULL << 48) | /* priority=1 */
+ (1ULL << 56); /* success=1 */
+ return true;
+ }
+ return false;
+}
+
/* init an utf-16 string from utf-8 string */
static inline void init_utf16(char *str, uint16_t *buf, unsigned bufsize)
{
@@ -396,12 +416,15 @@ static int gen_gptable(uint32_t signature, guid_t guid,
unsigned nr)
gpte[i].end = cpu_to_le64(sect -1);
gpte[i].guid = guid;
gpte[i].guid.b[sizeof(guid_t) -1] += i + 1;
- if (parts[i].type == 0xEF || (i + 1) == (unsigned)active) {
+ if (parts[i].has_gtype) {
+ gpte[i].type = parts[i].gtype;
+ } else if (parts[i].type == 0xEF || (i + 1) ==
(unsigned)active) {
gpte[i].type = GUID_PARTITION_SYSTEM;
init_utf16("EFI System Partition", (uint16_t
*)gpte[i].name, GPT_ENTRY_NAME_SIZE / sizeof(uint16_t));
} else {
gpte[i].type = GUID_PARTITION_BASIC_DATA;
}
+ gpte[i].attr = parts[i].gattr;
if (verbose)
fprintf(stderr, "Partition %d: start=%" PRIu64 ",
end=%" PRIu64 ", size=%" PRIu64 "\n",
@@ -498,7 +521,9 @@ fail:
static void usage(char *prog)
{
- fprintf(stderr, "Usage: %s [-v] [-n] [-g] -h -s -o
[-a 0..4] [-l ] [-G ] [[-t ] -p
[@]...] \n", prog);
+ fprintf(stderr, "Usage: %s [-v] [-n] [-g] -h -s -o
\n"
+ " [-a 0..4] [-l ] [-G ]\n"
+ " [[-t | -T ] -p
[@]...] \n", prog);
exit(EXIT_FAILURE);
}
@@ -512,7 +537,7 @@ int main (int argc, char **argv)
guid_t guid = GUID_INIT( signature, 0x2211, 0x4433, \
0x55, 0x66, 0x77, 0x88, 0x99, 0xAA, 0xBB, 0x00);
- while ((ch = getopt(argc, argv, "h:s:p:a:t:o:vngl:S:G:")) != -1) {
+ while ((ch = getopt(argc, argv, "h:s:p:a:t:T:o:vngl:S:G:")) != -1) {
switch (ch) {
case 'o':
filename = optarg;
@@ -560,6 +585,14 @@ int main (int argc, char **argv)
case 'S':
RE: [PATCH] rockchip: use stable MAC-address for NanoPi R2S
> + local mac_base=$(macaddr_canonicalize "$(echo "${sd_hash}" | dd
> bs=1 count=12 2>/dev/null)")
bs=12 count=1 ?
Best
Adrian
openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/2] libnl: add libnl-cli library
Jan 16, 2021 2:19:15 AM Pavel Šimerda : On 1/16/21 12:50 PM, Petr Štetiar wrote: Pavel Šimerda [2021-01-16 00:23:01]: Hi, My perspective is that we are working on *hardware enablement* here. At least some switch chips support Link Aggregation in addition to hardware switching and VLAN filtering. This will be handled by offloading the LAG configuration from the kernel team driver. we're trying to keep the main tree minimal for details see following link: https://lists.infradead.org/pipermail/openwrt-devel/2019-August/024109.html Hey Petr, is this an idea in progress or is OpenWRT already heading towards that goal? It's an ongoing progress. If you look at the Git log multiple packages were moved over the last weeks. * The libteam package to support the team module (new package) - Submitted in PATCH 2/2. This one looks like material for packages feed. So what is the correct approach? Please see my questions below. 1) Is it okay to modify libnl to build and distribute the libnl-cli package so that I can base the libteam package on it? 2) How should I handle the netifd team module dependency on libteam to get it accepted to netifd code base? Cheers, Pavel Šimerda -- ynezz ___ 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] rockchip: use stable MAC-address for NanoPi R2S
The NanoPi R2S does not have a board specific MAC address written inside
e.g. an EEPROM, hence why it is randomly generated on first boot.
The issue with that however is the lack of a driver for the PRNG.
It often results to the same MAC address used on multiple boards by
default, as urngd is not active at this early stage resulting in low
available entropy.
There is however a semi-unique identifier available to us, which is the
CID of the used SD card. It is unique to each SD card, hence we can use
it to generate the MAC address used for LAN and WAN.
Signed-off-by: David Bauer
---
.../rockchip/armv8/base-files/etc/board.d/02_network | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/target/linux/rockchip/armv8/base-files/etc/board.d/02_network
b/target/linux/rockchip/armv8/base-files/etc/board.d/02_network
index e129fd6a67..48133c81a1 100755
--- a/target/linux/rockchip/armv8/base-files/etc/board.d/02_network
+++ b/target/linux/rockchip/armv8/base-files/etc/board.d/02_network
@@ -17,6 +17,13 @@ rockchip_setup_interfaces()
esac
}
+nanopi_r2s_generate_mac()
+{
+ local sd_hash=$(sha256sum
/sys/devices/platform/ff50.dwmmc/mmc_host/mmc0/mmc0:*/cid)
+ local mac_base=$(macaddr_canonicalize "$(echo "${sd_hash}" | dd bs=1
count=12 2>/dev/null)")
+ echo "$(macaddr_unsetbit_mc "$(macaddr_setbit_la "${mac_base}")")"
+}
+
rockchip_setup_macs()
{
local board="$1"
@@ -26,7 +33,7 @@ rockchip_setup_macs()
case "$board" in
friendlyarm,nanopi-r2s)
- wan_mac=$(macaddr_random)
+ wan_mac=$(nanopi_r2s_generate_mac)
lan_mac=$(macaddr_add "$wan_mac" +1)
;;
esac
--
2.30.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH netifd] team: add simple bonding/teaming module
On 1/16/21 1:55 PM, Petr Štetiar wrote:
Pavel Šimerda [2021-01-12 04:36:36]:
Hi,
The module requires libteam's teamd and teamdctl commands.
This looks like an alien to the OpenWrt ecosystem, basically you're using
netifd just as a launcher for teamd, teamdctl without any proper error
handling instead of ubus for configuration etc.
Hey Petr,
this is what I'm using right now to enable the hardware features that were
*absent* in OpenWRT. Would you suggest that we keep a local fork for the time
being, until someone is willing to invest their time into building a ubus
wrapper for libteam?
Cheers,
Pavel Šimerda
Signed-off-by: Pavel Šimerda
---
CMakeLists.txt | 2 +-
team.c | 178 +
2 files changed, 179 insertions(+), 1 deletion(-)
create mode 100644 team.c
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 9d19817..351e303 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -19,7 +19,7 @@ SET(SOURCES
main.c utils.c system.c tunnel.c handler.c
interface.c interface-ip.c interface-event.c
iprule.c proto.c proto-static.c proto-shell.c
- config.c device.c bridge.c veth.c vlan.c alias.c
+ config.c device.c bridge.c team.c veth.c vlan.c alias.c
macvlan.c ubus.c vlandev.c wireless.c)
diff --git a/team.c b/team.c
new file mode 100644
index 000..9b67566
--- /dev/null
+++ b/team.c
@@ -0,0 +1,178 @@
+/*
+ * netifd - network interface daemon
+ * Copyright (C) 2021 Pavel Šimerda
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "netifd.h"
+#include "device.h"
+#include "interface.h"
+#include "system.h"
+
+enum {
+ TEAM_ATTR_IFNAME,
+ __TEAM_ATTR_MAX
+};
+
+static const struct blobmsg_policy team_attrs[__TEAM_ATTR_MAX] = {
+ [TEAM_ATTR_IFNAME] = { "ifname", BLOBMSG_TYPE_ARRAY },
+};
+
+static const struct uci_blob_param_info team_attr_info[__TEAM_ATTR_MAX] = {
+ [TEAM_ATTR_IFNAME] = { .type = BLOBMSG_TYPE_STRING },
+};
+
+static const struct uci_blob_param_list team_attr_list = {
+ .n_params = __TEAM_ATTR_MAX,
+ .params = team_attrs,
+ .info = team_attr_info,
+
+ .n_next = 1,
+ .next = { _attr_list },
+};
+
+struct team_device {
+ struct device dev;
+ device_state_cb set_state;
+
+ struct blob_attr *config_data;
+ struct blob_attr *ifnames;
+
+ int pid;
+};
+
+static int
+team_set_state(struct device *dev, bool up)
+{
+ struct team_device *teamdev = container_of(dev, struct team_device,
dev);
+
+ if (up) {
+ int pid;
+ struct blob_attr *cur;
+ int rem;
+ char buffer[64];
+
+ printf("TEAM start teamd\n");
if this is needed at all, take a look around and use proper debug logging
+ pid = fork();
+ if (pid == -1)
+ return -errno;
+ if (pid == 0)
+ execlp("teamd", "teamd", "-t", dev->ifname, NULL);
this is external dependency and you lack any check for that
+ teamdev->pid = pid;
+ // TODO: Better handling of newly created devices.
better? there is no handling of anything
+ sleep(1);
+ if (teamdev->ifnames) {
+ printf("TEAM port init\n");
+ blobmsg_for_each_attr(cur, teamdev->ifnames, rem) {
+ printf("TEAM one port init\n");
+ snprintf(buffer, sizeof buffer,
+ "teamdctl %s port add %s",
+ dev->ifname,
+ blobmsg_get_string(cur));
+ system(buffer);
puting aside usage of system() for service configuration this smells, you're
passing possibly malicious input directly to system() in the service running
as root, what could go wrong?
+ }
+ }
+ teamdev->set_state(dev, up);
+ return 0;
+ } else {
+ printf("TEAM: killing %d\n", teamdev->pid);
+ if (teamdev->pid) {
+ kill(teamdev->pid, SIGTERM);
+ waitpid(teamdev->pid, NULL, 0);
+ teamdev->pid = 0;
+ }
+ return 0;
+ }
+}
+
+static enum dev_change_type
+team_reload(struct device *dev, struct blob_attr
Re: [PATCH netifd] team: add simple bonding/teaming module
Pavel Šimerda [2021-01-12 04:36:36]:
Hi,
> The module requires libteam's teamd and teamdctl commands.
This looks like an alien to the OpenWrt ecosystem, basically you're using
netifd just as a launcher for teamd, teamdctl without any proper error
handling instead of ubus for configuration etc.
> Signed-off-by: Pavel Šimerda
> ---
> CMakeLists.txt | 2 +-
> team.c | 178 +
> 2 files changed, 179 insertions(+), 1 deletion(-)
> create mode 100644 team.c
>
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index 9d19817..351e303 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -19,7 +19,7 @@ SET(SOURCES
> main.c utils.c system.c tunnel.c handler.c
> interface.c interface-ip.c interface-event.c
> iprule.c proto.c proto-static.c proto-shell.c
> - config.c device.c bridge.c veth.c vlan.c alias.c
> + config.c device.c bridge.c team.c veth.c vlan.c alias.c
> macvlan.c ubus.c vlandev.c wireless.c)
>
>
> diff --git a/team.c b/team.c
> new file mode 100644
> index 000..9b67566
> --- /dev/null
> +++ b/team.c
> @@ -0,0 +1,178 @@
> +/*
> + * netifd - network interface daemon
> + * Copyright (C) 2021 Pavel Šimerda
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2
> + * as published by the Free Software Foundation
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "netifd.h"
> +#include "device.h"
> +#include "interface.h"
> +#include "system.h"
> +
> +enum {
> + TEAM_ATTR_IFNAME,
> + __TEAM_ATTR_MAX
> +};
> +
> +static const struct blobmsg_policy team_attrs[__TEAM_ATTR_MAX] = {
> + [TEAM_ATTR_IFNAME] = { "ifname", BLOBMSG_TYPE_ARRAY },
> +};
> +
> +static const struct uci_blob_param_info team_attr_info[__TEAM_ATTR_MAX] = {
> + [TEAM_ATTR_IFNAME] = { .type = BLOBMSG_TYPE_STRING },
> +};
> +
> +static const struct uci_blob_param_list team_attr_list = {
> + .n_params = __TEAM_ATTR_MAX,
> + .params = team_attrs,
> + .info = team_attr_info,
> +
> + .n_next = 1,
> + .next = { _attr_list },
> +};
> +
> +struct team_device {
> + struct device dev;
> + device_state_cb set_state;
> +
> + struct blob_attr *config_data;
> + struct blob_attr *ifnames;
> +
> + int pid;
> +};
> +
> +static int
> +team_set_state(struct device *dev, bool up)
> +{
> + struct team_device *teamdev = container_of(dev, struct team_device,
> dev);
> +
> + if (up) {
> + int pid;
> + struct blob_attr *cur;
> + int rem;
> + char buffer[64];
> +
> + printf("TEAM start teamd\n");
if this is needed at all, take a look around and use proper debug logging
> + pid = fork();
> + if (pid == -1)
> + return -errno;
> + if (pid == 0)
> + execlp("teamd", "teamd", "-t", dev->ifname, NULL);
this is external dependency and you lack any check for that
> + teamdev->pid = pid;
> + // TODO: Better handling of newly created devices.
better? there is no handling of anything
> + sleep(1);
> + if (teamdev->ifnames) {
> + printf("TEAM port init\n");
> + blobmsg_for_each_attr(cur, teamdev->ifnames, rem) {
> + printf("TEAM one port init\n");
> + snprintf(buffer, sizeof buffer,
> + "teamdctl %s port add %s",
> + dev->ifname,
> + blobmsg_get_string(cur));
> + system(buffer);
puting aside usage of system() for service configuration this smells, you're
passing possibly malicious input directly to system() in the service running
as root, what could go wrong?
> + }
> + }
> + teamdev->set_state(dev, up);
> + return 0;
> + } else {
> + printf("TEAM: killing %d\n", teamdev->pid);
> + if (teamdev->pid) {
> + kill(teamdev->pid, SIGTERM);
> + waitpid(teamdev->pid, NULL, 0);
> + teamdev->pid = 0;
> + }
> + return 0;
> + }
> +}
> +
> +static enum dev_change_type
> +team_reload(struct device *dev, struct blob_attr *attr)
> +{
> + struct team_device *teamdev = container_of(dev, struct team_device,
> dev);
> + struct blob_attr *tb_tm[__TEAM_ATTR_MAX];
> +
> + attr = blob_memdup(attr);
> +
> +
Re: [PATCH 2/2] libteam: add library to control team devices
On 1/16/21 12:54 PM, Petr Štetiar wrote: Pavel Šimerda [2021-01-14 03:38:48]: Hi, +++ b/package/network/services/libteam/Makefile @@ -0,0 +1,30 @@ +include $(TOPDIR)/rules.mk + +PKG_NAME := libteam +PKG_FIXUP := autoreconf +PKG_BUILD_DEPENDS := libdaemon jansson libdaemon is not in the main tree, it's in the packages tree, so this package should go there as well. +Subject: [PATCH] fix build on OpenWRT/musl-libc this should be upstreamed Sure. This has been submitted to upstream but there seems to be a communication issue. https://github.com/jpirko/libteam/pull/31 -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/2] libnl: add libnl-cli library
On 1/16/21 12:50 PM, Petr Štetiar wrote: Pavel Šimerda [2021-01-16 00:23:01]: Hi, My perspective is that we are working on *hardware enablement* here. At least some switch chips support Link Aggregation in addition to hardware switching and VLAN filtering. This will be handled by offloading the LAG configuration from the kernel team driver. we're trying to keep the main tree minimal for details see following link: https://lists.infradead.org/pipermail/openwrt-devel/2019-August/024109.html Hey Petr, is this an idea in progress or is OpenWRT already heading towards that goal? * The libteam package to support the team module (new package) - Submitted in PATCH 2/2. This one looks like material for packages feed. So what is the correct approach? Please see my questions below. 1) Is it okay to modify libnl to build and distribute the libnl-cli package so that I can base the libteam package on it? 2) How should I handle the netifd team module dependency on libteam to get it accepted to netifd code base? Cheers, Pavel Šimerda -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/2] libnl: add libnl-cli library
On 1/16/21 12:25 PM, Petr Štetiar wrote: Pavel Šimerda [2021-01-14 03:38:47]: Hi, --- package/libs/libnl/Makefile | 19 ++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/package/libs/libnl/Makefile b/package/libs/libnl/Makefile index db0c65c7a7..3b9bad4533 100644 --- a/package/libs/libnl/Makefile +++ b/package/libs/libnl/Makefile @@ -52,16 +52,26 @@ $(call Package/libnl/default) DEPENDS:=+libnl-route endef +define Package/libnl-cli +$(call Package/libnl/default) + TITLE:=Netlink Library CLI + DEPENDS:=+libnl-genl +libnl-route +libnl-nf +endef + define Package/libnl $(call Package/libnl/default) TITLE:=Full Netlink Library - DEPENDS:=+libnl-genl +libnl-route +libnl-nf + DEPENDS:=+libnl-genl +libnl-route +libnl-nf +libnl-cli Why is this dependency needed? Hey, would you suggest that libnl-cli stays left out of libnl deps as an “extra” package? I have no strong opinion about that one. endef define Package/libnl-core/description Common code for all netlink libraries endef +define Package/libnl-cli/description + CLI Netlink Library Functions +endef + define Package/libnl-genl/description Generic Netlink Library Functions endef @@ -92,6 +102,7 @@ define Build/InstallDev # Copy symlinks $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-3.so $(1)/usr/lib/libnl.so + $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-cli-3.so $(1)/usr/lib/libnl.so This seems like copy issue. Thanks. Pavel Šimerda $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-genl-3.so $(1)/usr/lib/libnl-genl.so $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-nf-3.so $(1)/usr/lib/libnl-nf.so $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-route-3.so $(1)/usr/lib/libnl-route.so @@ -102,6 +113,11 @@ define Package/libnl-core/install $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-3.so.* $(1)/usr/lib/ endef +define Package/libnl-cli/install + $(INSTALL_DIR) $(1)/usr/lib + $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-cli-3.so.* $(1)/usr/lib/ +endef + define Package/libnl-genl/install $(INSTALL_DIR) $(1)/usr/lib $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-genl-3.so.* $(1)/usr/lib/ @@ -122,6 +138,7 @@ define Package/libnl/install endef $(eval $(call BuildPackage,libnl-core)) +$(eval $(call BuildPackage,libnl-cli)) $(eval $(call BuildPackage,libnl-genl)) $(eval $(call BuildPackage,libnl-route)) $(eval $(call BuildPackage,libnl-nf)) -- 2.29.2 ___ 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 2/2] libteam: add library to control team devices
Pavel Šimerda [2021-01-14 03:38:48]: Hi, > +++ b/package/network/services/libteam/Makefile > @@ -0,0 +1,30 @@ > +include $(TOPDIR)/rules.mk > + > +PKG_NAME := libteam > +PKG_FIXUP := autoreconf > +PKG_BUILD_DEPENDS := libdaemon jansson libdaemon is not in the main tree, it's in the packages tree, so this package should go there as well. > +Subject: [PATCH] fix build on OpenWRT/musl-libc this should be upstreamed -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/2] libnl: add libnl-cli library
Pavel Šimerda [2021-01-16 00:23:01]: Hi, > My perspective is that we are working on *hardware enablement* here. At > least some switch chips support Link Aggregation in addition to hardware > switching and VLAN filtering. This will be handled by offloading the LAG > configuration from the kernel team driver. we're trying to keep the main tree minimal for details see following link: https://lists.infradead.org/pipermail/openwrt-devel/2019-August/024109.html > * The libteam package to support the team module (new package) > - Submitted in PATCH 2/2. This one looks like material for packages feed. -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/2] libnl: add libnl-cli library
Pavel Šimerda [2021-01-14 03:38:47]: Hi, > --- > package/libs/libnl/Makefile | 19 ++- > 1 file changed, 18 insertions(+), 1 deletion(-) > > diff --git a/package/libs/libnl/Makefile b/package/libs/libnl/Makefile > index db0c65c7a7..3b9bad4533 100644 > --- a/package/libs/libnl/Makefile > +++ b/package/libs/libnl/Makefile > @@ -52,16 +52,26 @@ $(call Package/libnl/default) >DEPENDS:=+libnl-route > endef > > +define Package/libnl-cli > +$(call Package/libnl/default) > + TITLE:=Netlink Library CLI > + DEPENDS:=+libnl-genl +libnl-route +libnl-nf > +endef > + > define Package/libnl > $(call Package/libnl/default) >TITLE:=Full Netlink Library > - DEPENDS:=+libnl-genl +libnl-route +libnl-nf > + DEPENDS:=+libnl-genl +libnl-route +libnl-nf +libnl-cli Why is this dependency needed? > endef > > define Package/libnl-core/description > Common code for all netlink libraries > endef > > +define Package/libnl-cli/description > + CLI Netlink Library Functions > +endef > + > define Package/libnl-genl/description > Generic Netlink Library Functions > endef > @@ -92,6 +102,7 @@ define Build/InstallDev > > # Copy symlinks > $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-3.so $(1)/usr/lib/libnl.so > + $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-cli-3.so $(1)/usr/lib/libnl.so This seems like copy issue. > $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-genl-3.so > $(1)/usr/lib/libnl-genl.so > $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-nf-3.so $(1)/usr/lib/libnl-nf.so > $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-route-3.so > $(1)/usr/lib/libnl-route.so > @@ -102,6 +113,11 @@ define Package/libnl-core/install > $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-3.so.* $(1)/usr/lib/ > endef > > +define Package/libnl-cli/install > + $(INSTALL_DIR) $(1)/usr/lib > + $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-cli-3.so.* $(1)/usr/lib/ > +endef > + > define Package/libnl-genl/install > $(INSTALL_DIR) $(1)/usr/lib > $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-genl-3.so.* $(1)/usr/lib/ > @@ -122,6 +138,7 @@ define Package/libnl/install > endef > > $(eval $(call BuildPackage,libnl-core)) > +$(eval $(call BuildPackage,libnl-cli)) > $(eval $(call BuildPackage,libnl-genl)) > $(eval $(call BuildPackage,libnl-route)) > $(eval $(call BuildPackage,libnl-nf)) > -- > 2.29.2 > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/2] libnl: add libnl-cli library
Adrian Schmutzler [2021-01-14 13:10:14]: Hi, > Apart from that, do we need this in the main repo or could it also go into > packages? in this case no. -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
