Re: [OpenWrt-Devel] [PATCH v4] export KERNEL_INITRAMFS_IMAGE
`Build/ubnt-erx-factory-kernel` in `target\linux\ramips\image\Makefile` references `$(KERNEL_INITRAMFS_IMAGE)` which is not exported Signed-off-by: YounJae Rho --- tested with git am in trunk commit 57693a7c8 include/image.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/image.mk b/include/image.mk index 5ef8002..62ea0e7 100644 --- a/include/image.mk +++ b/include/image.mk @@ -454,7 +454,7 @@ define Device/ExportVar endef define Device/Export - $(foreach var,$(DEVICE_VARS) DEVICE_NAME KERNEL KERNEL_INITRAMFS,$(call Device/ExportVar,$(1),$(var))) + $(foreach var,$(DEVICE_VARS) DEVICE_NAME KERNEL KERNEL_INITRAMFS KERNEL_INITR AMFS_IMAGE,$(call Device/ExportVar,$(1),$(var))) $(1) : FILESYSTEM:=$(2) endef -- 2.5.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v3] export KERNEL_INITRAMFS_IMAGE
`Build/ubnt-erx-factory-kernel` in `target\linux\ramips\image\Makefile` references `$(KERNEL_INITRAMFS_IMAGE)` which is not exported Signed-off-by: YounJae Rho --- tested with git am in trunk commit 57693a7c8 include/image.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/image.mk b/include/image.mk index 5ef8002..053bb08 100644 --- a/include/image.mk +++ b/include/image.mk @@ -454,7 +454,7 @@ define Device/ExportVar endef define Device/Export - $(foreach var,$(DEVICE_VARS) DEVICE_NAME KERNEL KERNEL_INITRAMFS,$(call Devic e/ExportVar,$(1),$(var))) + $(foreach var,$(DEVICE_VARS) DEVICE_NAME KERNEL KERNEL_INITRAMFS KERNEL_INITR AMFS_IMAGE,$(call Device/ExportVar,$(1),$(var))) $(1) : FILESYSTEM:=$(2) endef -- 2.5.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/1 v2] package/libs/libtool: rename to libltdl
On 2016-01-04 02:23, Heinrich Schuchardt wrote: > On 04.01.2016 01:43, Felix Fietkau wrote: >> On 2016-01-04 01:34, Heinrich Schuchardt wrote: >>> Source package libtool is used to package libltdl. >>> Unfortunately binary libtoolize is missing. >>> Packaging libtoolize would depend on package file which is in the >>> packages feed. >>> Felix Fietkau suggested to rename source libtool to libltdl >>> and to create a new package libtool in packages. >>> >>> This patch contains the renaming. >>> >>> version 2 >>> Renaming must occur inside Makefile too. >> That Build/Prepare code is rather weird. How about leaving PKG_NAME >> alone, removing Build/Prepare and just setting: >> PKG_BUILD_DIR:=$(BUILD_DIR)/libltdl/$(PKG_NAME)-$(PKG_VERSION) >> >> - Felix >> > Does variable PKG_NAME have no significance outside? There were some instances where it was used that might have triggered some rare race conditions, but I just fixed those in r48110. > Doesn't it have to match the directory name? It doesn't. > What I want to avoid is that if I create > devel/libtool/Makefile with PKG_NAME=libtool > in feed packages I get any interference. You can safely do that. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/1 v2] package/libs/libtool: rename to libltdl
On 04.01.2016 01:43, Felix Fietkau wrote: > On 2016-01-04 01:34, Heinrich Schuchardt wrote: >> Source package libtool is used to package libltdl. >> Unfortunately binary libtoolize is missing. >> Packaging libtoolize would depend on package file which is in the >> packages feed. >> Felix Fietkau suggested to rename source libtool to libltdl >> and to create a new package libtool in packages. >> >> This patch contains the renaming. >> >> version 2 >> Renaming must occur inside Makefile too. > That Build/Prepare code is rather weird. How about leaving PKG_NAME > alone, removing Build/Prepare and just setting: > PKG_BUILD_DIR:=$(BUILD_DIR)/libltdl/$(PKG_NAME)-$(PKG_VERSION) > > - Felix > Does variable PKG_NAME have no significance outside? Doesn't it have to match the directory name? What I want to avoid is that if I create devel/libtool/Makefile with PKG_NAME=libtool in feed packages I get any interference. Unfortunately wiki.openwrt.org does not really explain this. It seems that something like you propose has already be done in package/kernel/lantiq/ltq-adsl-fw/Makefile Best regards Heinrich ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/3] firmware-utils: add support for TP-Link Archer C2600 to tplink-safeloader
Add support for TP-Link Archer C2600 to tplink-safeloader including partition
table and additional SupportList strings. Both factory and sysupgrade images
are supported.
Signed-off-by: Josh Bendavid
---
tools/firmware-utils/src/tplink-safeloader.c | 114 ++-
1 file changed, 111 insertions(+), 3 deletions(-)
diff --git a/tools/firmware-utils/src/tplink-safeloader.c
b/tools/firmware-utils/src/tplink-safeloader.c
index 77a894b..f43ffd5 100644
--- a/tools/firmware-utils/src/tplink-safeloader.c
+++ b/tools/firmware-utils/src/tplink-safeloader.c
@@ -105,6 +105,8 @@ static const uint8_t md5_salt[16] = {
/** Vendor information for CPE210/220/510/520 */
static const char cpe510_vendor[] = "CPE510(TP-LINK|UN|N300-5):1.0\r\n";
+/** Vendor information for C2600 */
+static const char c2600_vendor[] = "";
/**
The flash partition table for CPE210/220/510/520;
@@ -128,6 +130,39 @@ static const struct flash_partition_entry
cpe510_partitions[] = {
};
/**
+The flash partition table for C2600;
+it is the same as the one used by the stock images.
+*/
+static const struct flash_partition_entry c2600_partitions[] = {
+{"SBL1", 0x0, 0x2},
+{"MIBIB", 0x2, 0x2},
+{"SBL2", 0x4, 0x2},
+{"SBL3", 0x6, 0x3},
+{"DDRCONFIG", 0x9, 0x1},
+{"SSD", 0xa, 0x1},
+{"TZ", 0xb, 0x3},
+{"RPM", 0xe, 0x2},
+{"fs-uboot", 0x10, 0x7},
+{"uboot-env", 0x17, 0x4},
+{"radio", 0x1b, 0x4},
+{"os-image", 0x1f, 0x20},
+{"file-system", 0x3f, 0x1b0},
+{"default-mac", 0x1ef, 0x00200},
+{"pin", 0x1ef0200, 0x00200},
+{"product-info", 0x1ef0400, 0x0fc00},
+{"partition-table", 0x1f0, 0x1},
+{"soft-version", 0x1f1, 0x1},
+{"support-list", 0x1f2, 0x1},
+{"profile", 0x1f3, 0x1},
+{"default-config", 0x1f4, 0x1},
+{"user-config", 0x1f5, 0x4},
+{"qos-db", 0x1f9, 0x4},
+{"usb-config", 0x1fd, 0x1},
+{"log", 0x1fe, 0x2},
+ {NULL, 0, 0}
+};
+
+/**
The support list for CPE210/220/510/520
*/
static const char cpe510_support_list[] =
@@ -141,6 +176,13 @@ static const char cpe510_support_list[] =
"CPE220(TP-LINK|UN|N300-2):1.0\r\n"
"CPE220(TP-LINK|UN|N300-2):1.1\r\n";
+/**
+ The support list for C2600
+*/
+static const char c2600_support_list[] =
+ "SupportList:\r\n"
+ "{product_name:Archer C2600,product_ver:1.0.0,special_id:}\r\n";
+
#define error(_ret, _errno, _str, ...) \
do {\
fprintf(stderr, _str ": %s\n", ## __VA_ARGS__, \
@@ -240,14 +282,14 @@ static struct image_partition_entry
make_soft_version(uint32_t rev) {
}
/** Generates the support-list partition */
-static struct image_partition_entry make_support_list(const char
*support_list) {
+static struct image_partition_entry make_support_list(const char
*support_list, bool trailzero) {
size_t len = strlen(support_list);
struct image_partition_entry entry =
alloc_image_partition("support-list", len + 9);
put32(entry.data, len);
memset(entry.data+4, 0, 4);
memcpy(entry.data+8, support_list, len);
- entry.data[len+8] = '\xff';
+ entry.data[len+8] = trailzero ? '\x00' : '\xff';
return entry;
}
@@ -436,6 +478,37 @@ static void * generate_sysupgrade_image(const struct
flash_partition_entry *flas
return image;
}
+static void * generate_sysupgrade_image_c2600(const struct
flash_partition_entry *flash_parts, const struct image_partition_entry
*image_parts, size_t *len) {
+ const struct flash_partition_entry *flash_os_image = &flash_parts[11];
+ const struct flash_partition_entry *flash_file_system =
&flash_parts[12];
+
+ const struct image_partition_entry *image_os_image = &image_parts[3];
+ const struct image_partition_entry *image_file_system = &image_parts[4];
+
+ assert(strcmp(flash_os_image->name, "os-image") == 0);
+ assert(strcmp(flash_file_system->name, "file-system") == 0);
+
+ assert(strcmp(image_os_image->name, "os-image") == 0);
+ assert(strcmp(image_file_system->name, "file-system") == 0);
+
+ if (image_os_image->size > flash_os_image->size)
+ error(1, 0, "kernel image too big (more than %u bytes)",
(unsigned)flash_os_image->size);
+ if (image_file_system->size > flash_file_system->size)
+ error(1, 0, "rootfs image too big (more than %u bytes)",
(unsigned)flash_file_system->size);
+
+ *len = flash_file_system->base - flash_os_image->base +
image_file_system->size;
+
+ uint8_t *image = malloc(*len);
+ if (!image)
+ error(1, err
[OpenWrt-Devel] [PATCH 1/3] ipq806x: add support for TP-Link Archer C2600 to makefiles, configs, scripts and device tree
Add initial support for Archer C2600 to Makefiles, profiles, led/network
config, and hotplug script. Together with firmware-utils and mac80211 patches
this is sufficient to build a working factory image flashable both from stock
web ui and bootloader tftp recovery. Sysupgrade is working as well. Added
hotplug script is adapted from existing script for ar71xx which copies wireless
calibration data from ART partition in flash to appropriate place in
/lib/firmware. The device tree file is similar to the current ap148 dts, with
sata and nand removed, and buttons/led's added.
Working: Wired network, wireless (both bands), power/status/lan/wan/usb led's
Not working: wireless status led's (these are not controlled through gpio, but
rather through the QCA9980 pcie chips). Also there is no way to set the wan
led to orange, which is possible in the stock firmware. Kernel 4.1 build does
not boot currently.
Not tested: Hardware buttons.
Signed-off-by: Josh Bendavid
---
.../linux/ipq806x/base-files/etc/board.d/01_leds | 7 +
.../ipq806x/base-files/etc/board.d/02_network | 3 +-
.../etc/hotplug.d/firmware/11-ath10k-caldata | 66 +
target/linux/ipq806x/base-files/lib/ipq806x.sh | 3 +
.../ipq806x/base-files/lib/upgrade/platform.sh | 34 ++-
target/linux/ipq806x/image/Makefile| 24 +-
...qcom-add-TP-Link-Archer-C2600-device-tree.patch | 300 +
...qcom-add-TP-Link-Archer-C2600-device-tree.patch | 300 +
target/linux/ipq806x/profiles/tplink.mk| 20 ++
9 files changed, 754 insertions(+), 3 deletions(-)
create mode 100644
target/linux/ipq806x/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
create mode 100644
target/linux/ipq806x/patches-3.18/711-ARM-qcom-add-TP-Link-Archer-C2600-device-tree.patch
create mode 100644
target/linux/ipq806x/patches-4.1/711-ARM-qcom-add-TP-Link-Archer-C2600-device-tree.patch
create mode 100644 target/linux/ipq806x/profiles/tplink.mk
diff --git a/target/linux/ipq806x/base-files/etc/board.d/01_leds
b/target/linux/ipq806x/base-files/etc/board.d/01_leds
index 07b5b06..46070ad6 100755
--- a/target/linux/ipq806x/base-files/etc/board.d/01_leds
+++ b/target/linux/ipq806x/base-files/etc/board.d/01_leds
@@ -19,6 +19,13 @@ r7500)
ucidef_set_led_default "wps" "WPS" "r7500:white:wps" "0"
ucidef_set_led_default "rfkill" "rfkill" "r7500:white:rfkill" "0"
;;
+c2600)
+ ucidef_set_led_usbdev "usb1" "USB 1" "usb_2:blue" "2-1"
+ ucidef_set_led_usbdev "usb2" "USB 2" "usb_4:blue" "4-1"
+ ucidef_set_led_netdev "wan" "WAN" "wan:blue" "eth0"
+ ucidef_set_led_netdev "lan" "LAN" "lan:blue" "br-lan"
+ ucidef_set_led_default "general" "general" "ledgnr:blue" "1"
+ ;;
*)
;;
esac
diff --git a/target/linux/ipq806x/base-files/etc/board.d/02_network
b/target/linux/ipq806x/base-files/etc/board.d/02_network
index 1302a55..9f061e4 100755
--- a/target/linux/ipq806x/base-files/etc/board.d/02_network
+++ b/target/linux/ipq806x/base-files/etc/board.d/02_network
@@ -13,7 +13,8 @@ board=$(ipq806x_board_name)
case "$board" in
ap148 |\
-r7500)
+r7500 |\
+c2600)
ucidef_add_switch "switch0" \
"1:lan" "2:lan" "3:lan" "4:lan" "6@eth1" "5:wan" "0@eth0"
;;
diff --git
a/target/linux/ipq806x/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
b/target/linux/ipq806x/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
new file mode 100644
index 000..7a423de
--- /dev/null
+++ b/target/linux/ipq806x/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -0,0 +1,66 @@
+#!/bin/sh
+
+ath10kcal_die() {
+ echo "ath10cal: " "$*"
+ exit 1
+}
+
+ath10kcal_from_file() {
+ local source=$1
+ local offset=$2
+ local count=$3
+
+ dd if=$source of=/lib/firmware/$FIRMWARE bs=1 skip=$offset count=$count
2>/dev/null || \
+ ath10kcal_die "failed to extract calibration data from $source"
+}
+
+ath10kcal_extract() {
+ local part=$1
+ local offset=$2
+ local count=$3
+ local mtd
+
+ mtd=$(find_mtd_chardev $part)
+ [ -n "$mtd" ] || \
+ ath10kcal_die "no mtd device found for partition $part"
+
+ dd if=$mtd of=/lib/firmware/$FIRMWARE bs=1 skip=$offset count=$count
2>/dev/null || \
+ ath10kcal_die "failed to extract calibration data from $mtd"
+}
+
+ath10kcal_patch_mac() {
+ local mac=$1
+
+ [ -z "$mac" ] && return
+
+ macaddr_2bin $mac | dd of=/lib/firmware/$FIRMWARE conv=notrunc bs=1
seek=6 count=6
+}
+
+[ -e /lib/firmware/$FIRMWARE ] && exit 0
+
+. /lib/ipq806x.sh
+. /lib/functions.sh
+. /lib/functions/system.sh
+
+board=$(ipq806x_board_name)
+
+
+case "$FIRMWARE" in
+"ath10k/cal-pci-:01:00.0.bin")
+ case $board in
+ c2600)
+ ath10kcal_extract "0:ART" 4096 12064
+ ;;
+ esac
+ ;;
+"ath10k/cal-pci-0001:01:00.0.bin")
+ case $board i
Re: [OpenWrt-Devel] [PATCH 1/1 v2] package/libs/libtool: rename to libltdl
On 2016-01-04 01:34, Heinrich Schuchardt wrote: > Source package libtool is used to package libltdl. > Unfortunately binary libtoolize is missing. > Packaging libtoolize would depend on package file which is in the > packages feed. > Felix Fietkau suggested to rename source libtool to libltdl > and to create a new package libtool in packages. > > This patch contains the renaming. > > version 2 > Renaming must occur inside Makefile too. That Build/Prepare code is rather weird. How about leaving PKG_NAME alone, removing Build/Prepare and just setting: PKG_BUILD_DIR:=$(BUILD_DIR)/libltdl/$(PKG_NAME)-$(PKG_VERSION) - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/1 v2] package/libs/libtool: rename to libltdl
Source package libtool is used to package libltdl. Unfortunately binary libtoolize is missing. Packaging libtoolize would depend on package file which is in the packages feed. Felix Fietkau suggested to rename source libtool to libltdl and to create a new package libtool in packages. This patch contains the renaming. version 2 Renaming must occur inside Makefile too. Signed-off-by: Heinrich Schuchardt --- package/libs/libltdl/Makefile | 60 ++ .../libs/libltdl/patches/160-passthrough-ssp.patch | 11 package/libs/libtool/Makefile | 52 --- .../libs/libtool/patches/160-passthrough-ssp.patch | 11 4 files changed, 71 insertions(+), 63 deletions(-) create mode 100644 package/libs/libltdl/Makefile create mode 100644 package/libs/libltdl/patches/160-passthrough-ssp.patch delete mode 100644 package/libs/libtool/Makefile delete mode 100644 package/libs/libtool/patches/160-passthrough-ssp.patch diff --git a/package/libs/libltdl/Makefile b/package/libs/libltdl/Makefile new file mode 100644 index 000..3401caa --- /dev/null +++ b/package/libs/libltdl/Makefile @@ -0,0 +1,60 @@ +# +# Copyright (C) 2006 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:=libltdl +PKG_VERSION:=2.4 +PKG_RELEASE:=1 + +PKG_SOURCE:=libtool-$(PKG_VERSION).tar.gz +PKG_SOURCE_URL:=@GNU/libtool +PKG_MD5SUM:=b32b04148ecdd7344abc6fe8bd1bb021 + +PKG_LICENSE:=GPL-2.0+ +PKG_LICENSE_FILES:=COPYING + +PKG_BUILD_PARALLEL:=0 + +include $(INCLUDE_DIR)/package.mk + +CONFIGURE_PREFIX=$(STAGING_DIR)/host +export GLOBAL_LIBDIR=$(STAGING_DIR)/usr/lib + +define Package/libltdl + SECTION:=libs + CATEGORY:=Libraries + TITLE:=A generic dynamic object loading library + URL:=http://www.gnu.org/software/libtool/ +endef + +define Build/Prepare + rm -rf $(PKG_BUILD_DIR) + mkdir -p $(PKG_BUILD_DIR) + $(TAR) -C $(PKG_BUILD_DIR) \ + -xzf $(DL_DIR)/libtool-$(PKG_VERSION).tar.gz --strip 1 + $(Build/Patch) +endef + +define Build/InstallDev + $(MAKE) -C $(PKG_BUILD_DIR) \ + bindir="$(2)/bin" \ + datadir="$(2)/share" \ + prefix="$(2)" \ + exec_prefix="$(2)" \ + install + $(INSTALL_DIR) $(1)/usr/lib $(1)/usr/include + mv $(2)/lib/* $(1)/usr/lib/ + mv $(2)/include/* $(1)/usr/include/ +endef + +define Package/libltdl/install + $(INSTALL_DIR) $(1)/usr/lib + $(CP) $(PKG_BUILD_DIR)/libltdl/.libs/libltdl.so.* $(1)/usr/lib/ +endef + +$(eval $(call BuildPackage,libltdl)) diff --git a/package/libs/libltdl/patches/160-passthrough-ssp.patch b/package/libs/libltdl/patches/160-passthrough-ssp.patch new file mode 100644 index 000..6fcbe68 --- /dev/null +++ b/package/libs/libltdl/patches/160-passthrough-ssp.patch @@ -0,0 +1,11 @@ +--- a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh +@@ -5051,7 +5051,7 @@ func_mode_link () + # -O*, -flto*, -fwhopr*, -fuse-linker-plugin GCC link-time optimization + -64|-mips[0-9]|-r[0-9][0-9]*|-xarch=*|-xtarget=*|+DA*|+DD*|-q*|-m*| \ + -t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|@*|-tp=*|--sysroot=*| \ +- -O*|-flto*|-fwhopr*|-fuse-linker-plugin) ++ -O*|-flto*|-fwhopr*|-fuse-linker-plugin|-fstack-protector*) + func_quote_for_eval "$arg" + arg="$func_quote_for_eval_result" + func_append compile_command " $arg" diff --git a/package/libs/libtool/Makefile b/package/libs/libtool/Makefile deleted file mode 100644 index 8091081..000 --- a/package/libs/libtool/Makefile +++ /dev/null @@ -1,52 +0,0 @@ -# -# Copyright (C) 2006 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:=libtool -PKG_VERSION:=2.4 -PKG_RELEASE:=1 - -PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz -PKG_SOURCE_URL:=@GNU/libtool -PKG_MD5SUM:=b32b04148ecdd7344abc6fe8bd1bb021 - -PKG_LICENSE:=GPL-2.0+ -PKG_LICENSE_FILES:=COPYING - -PKG_BUILD_PARALLEL:=0 - -include $(INCLUDE_DIR)/package.mk - -CONFIGURE_PREFIX=$(STAGING_DIR)/host -export GLOBAL_LIBDIR=$(STAGING_DIR)/usr/lib - -define Package/libltdl - SECTION:=libs - CATEGORY:=Libraries - TITLE:=A generic dynamic object loading library - URL:=http://www.gnu.org/software/libtool/ -endef - -define Build/InstallDev - $(MAKE) -C $(PKG_BUILD_DIR) \ - bindir="$(2)/bin" \ - datadir="$(2)/share" \ - prefix="$(2)" \ - exec_prefix="$(2)" \ - install - $(INSTALL_DIR) $(1)/usr/lib $(1)/usr/include - mv $(2)/lib/* $(1)/usr/lib/ - mv $(2)/include/* $(1)/usr/include/ -endef - -define Package/libltdl/install - $(INSTALL_DIR) $(1)/usr/lib - $(CP) $(PKG_BUILD_DIR)/libltdl/.libs/libltdl.so.* $(1)/usr/
[OpenWrt-Devel] [PATCH 1/1] package/libs/libtool: rename to libltdl
Source package libtool is used to package libltdl. Unfortunately binary libtoolize is missing. Packaging libtoolize would depend on package file which is in the packages feed. Felix Fietkau suggested to rename source libtool to libltdl and to create a new package libtool in packages. This patch contains the renaming. Signed-off-by: Heinrich Schuchardt --- package/libs/libltdl/Makefile | 52 ++ .../libs/libltdl/patches/160-passthrough-ssp.patch | 11 + package/libs/libtool/Makefile | 52 -- .../libs/libtool/patches/160-passthrough-ssp.patch | 11 - 4 files changed, 63 insertions(+), 63 deletions(-) create mode 100644 package/libs/libltdl/Makefile create mode 100644 package/libs/libltdl/patches/160-passthrough-ssp.patch delete mode 100644 package/libs/libtool/Makefile delete mode 100644 package/libs/libtool/patches/160-passthrough-ssp.patch diff --git a/package/libs/libltdl/Makefile b/package/libs/libltdl/Makefile new file mode 100644 index 000..8091081 --- /dev/null +++ b/package/libs/libltdl/Makefile @@ -0,0 +1,52 @@ +# +# Copyright (C) 2006 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:=libtool +PKG_VERSION:=2.4 +PKG_RELEASE:=1 + +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz +PKG_SOURCE_URL:=@GNU/libtool +PKG_MD5SUM:=b32b04148ecdd7344abc6fe8bd1bb021 + +PKG_LICENSE:=GPL-2.0+ +PKG_LICENSE_FILES:=COPYING + +PKG_BUILD_PARALLEL:=0 + +include $(INCLUDE_DIR)/package.mk + +CONFIGURE_PREFIX=$(STAGING_DIR)/host +export GLOBAL_LIBDIR=$(STAGING_DIR)/usr/lib + +define Package/libltdl + SECTION:=libs + CATEGORY:=Libraries + TITLE:=A generic dynamic object loading library + URL:=http://www.gnu.org/software/libtool/ +endef + +define Build/InstallDev + $(MAKE) -C $(PKG_BUILD_DIR) \ + bindir="$(2)/bin" \ + datadir="$(2)/share" \ + prefix="$(2)" \ + exec_prefix="$(2)" \ + install + $(INSTALL_DIR) $(1)/usr/lib $(1)/usr/include + mv $(2)/lib/* $(1)/usr/lib/ + mv $(2)/include/* $(1)/usr/include/ +endef + +define Package/libltdl/install + $(INSTALL_DIR) $(1)/usr/lib + $(CP) $(PKG_BUILD_DIR)/libltdl/.libs/libltdl.so.* $(1)/usr/lib/ +endef + +$(eval $(call BuildPackage,libltdl)) diff --git a/package/libs/libltdl/patches/160-passthrough-ssp.patch b/package/libs/libltdl/patches/160-passthrough-ssp.patch new file mode 100644 index 000..6fcbe68 --- /dev/null +++ b/package/libs/libltdl/patches/160-passthrough-ssp.patch @@ -0,0 +1,11 @@ +--- a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh +@@ -5051,7 +5051,7 @@ func_mode_link () + # -O*, -flto*, -fwhopr*, -fuse-linker-plugin GCC link-time optimization + -64|-mips[0-9]|-r[0-9][0-9]*|-xarch=*|-xtarget=*|+DA*|+DD*|-q*|-m*| \ + -t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|@*|-tp=*|--sysroot=*| \ +- -O*|-flto*|-fwhopr*|-fuse-linker-plugin) ++ -O*|-flto*|-fwhopr*|-fuse-linker-plugin|-fstack-protector*) + func_quote_for_eval "$arg" + arg="$func_quote_for_eval_result" + func_append compile_command " $arg" diff --git a/package/libs/libtool/Makefile b/package/libs/libtool/Makefile deleted file mode 100644 index 8091081..000 --- a/package/libs/libtool/Makefile +++ /dev/null @@ -1,52 +0,0 @@ -# -# Copyright (C) 2006 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:=libtool -PKG_VERSION:=2.4 -PKG_RELEASE:=1 - -PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz -PKG_SOURCE_URL:=@GNU/libtool -PKG_MD5SUM:=b32b04148ecdd7344abc6fe8bd1bb021 - -PKG_LICENSE:=GPL-2.0+ -PKG_LICENSE_FILES:=COPYING - -PKG_BUILD_PARALLEL:=0 - -include $(INCLUDE_DIR)/package.mk - -CONFIGURE_PREFIX=$(STAGING_DIR)/host -export GLOBAL_LIBDIR=$(STAGING_DIR)/usr/lib - -define Package/libltdl - SECTION:=libs - CATEGORY:=Libraries - TITLE:=A generic dynamic object loading library - URL:=http://www.gnu.org/software/libtool/ -endef - -define Build/InstallDev - $(MAKE) -C $(PKG_BUILD_DIR) \ - bindir="$(2)/bin" \ - datadir="$(2)/share" \ - prefix="$(2)" \ - exec_prefix="$(2)" \ - install - $(INSTALL_DIR) $(1)/usr/lib $(1)/usr/include - mv $(2)/lib/* $(1)/usr/lib/ - mv $(2)/include/* $(1)/usr/include/ -endef - -define Package/libltdl/install - $(INSTALL_DIR) $(1)/usr/lib - $(CP) $(PKG_BUILD_DIR)/libltdl/.libs/libltdl.so.* $(1)/usr/lib/ -endef - -$(eval $(call BuildPackage,libltdl)) diff --git a/package/libs/libtool/patches/160-passthrough-ssp.patch b/package/libs/libtool/patches/160-passthrough-ssp.patch deleted file mode 100644 index 6fcbe68..000 --- a/package/libs/libtool/patches/160-passthro
Re: [OpenWrt-Devel] SDK vs. Toolchain+
On 03/01/16 01:01 PM, Felix Fietkau wrote: On 2016-01-03 18:53, Daniel Dickinson wrote: Hi Felix, I think part of the confusion stems from the fact that the current SDK is not really an SDK but a 'Toolchain+'. Perhaps the current SDK should be renamed to clarify that point, and a 'real' SDK created. What's a 'real' SDK as opposed to a 'Toolchain+'? Perhaps it's just the way I think of it, but a Toolchain/Toolchain(+) provides everything need to do build on a particular platform, with only minor exceptions of things included with OS in a standard install. It's binary or equivalent (i.e. no special tools required) pretty much by definition because it's supposed to take care of providing what you need to do a build. You can talk about the source of a toolchain, but I don't think it's coherent to talk about the source as the toolchain. A toolchain of some sort is typically required to build an SDK, or to develop new versions of the toolchain (assuming you have the source of the toolchain). A 'real' SDK on the other hand allows you to build toolchains and systems from scratch, but has more dependencies (unless it's combination SDK + Toolchain) because the operating system has to provide enough build machinery to build from source (or in the proprietary version, source + binary bits that theoretically can be legitimately packaged that way and/or 'protect' 'special' IP). It's kind of a greyish area for definitions because I'm not sure there is a consistent usage of the SDK term in industry. I think in some cases SDK is used to mean what I think of as Toolchain+ that is used build add-ons for a system, but is platform-specific (and not necessarily with source to port either), whereas in the the open source world I think SDK tends to imply something that lets you build from scratch (with source). In any event, regardless of what you call it, the current OpenWrt SDK is of the variety of (mostly) standalone binaries that you use to build packages for openwrt, rather than of a set of sources that can be used to build what you need to build packages and/or the packages themselves (which is what I would consider a 'real' SDK vs the current Toolchain+). The two types of things have different goals. the 'real' SDK is meant to provide the ability to develop the system; the toolchain/toolchain+ is meant to bootstrap the process or at least make building stand on it's own for a given platform. The current SDK is useless without ImageBuilder and/or package repositories. Not really. It allows you to build packages that you can put on a running system built from the same release (including out-of-tree kernel modules). Ok, I mean useless for building firmware; it certainly isn't useless by any means (I fin it rather useful as a Toolchain+; for SDK there is buildroot + feeds + downloaded packages). Does that clarify my thinking a little for you, and do you see, perhaps, the value of the current toolchain+ type of SDK in addition to the kind of SDK I think you're thinking of (That I call a 'real' SDK)? Regards, Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] images: Add option to build tar.gz suitable for use as LXC guest rootfs
On 2015-12-17 10:40, open...@daniel.thecshore.com wrote: > From: Daniel Dickinson > > An any target with targz image support we add the option of building > a tar.gz which is suitably configured to run as an LXC guest rootfs. > > NB: This does not require kernel support; the LCX *host* requires > the appropriate kernel support, but building the guest does not > need such support enabled. > > Signed-off-by: Daniel Dickinson There's quite a bit of nasty code duplication in there. Also, I wonder: Do we really need to have a separate .tar.gz for lxc? Can't the use of lxc be detected and dealt with in the standard scripts instead of introducing more quirky hackery? - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [ar71xx] Support for Ubiquiti UniFi AP AC LITE
On 2015-12-23 00:35, p.wa...@gmx.at wrote: > From: P.Wassi > > Add support for the Ubiquiti UniFi AP AC LITE > Signed-off-by: P.Wassi > --- > The UniFi AC series will only be supported, if these patches are > applied first (especially for the QCA956x SoC support): > https://patchwork.ozlabs.org/patch/559284/ > https://patchwork.ozlabs.org/patch/559285/ > https://patchwork.ozlabs.org/patch/559286/ > https://patchwork.ozlabs.org/patch/559287/ > https://patchwork.ozlabs.org/patch/559288/ > Then, this patch adds: > * New machine type > * Code for device setup > * Proper image configuration > * New target for the build system > * Network setup as LAN-only > * Diagnostic LED > * Sysupgrade Support > * ath10k firmware extraction > * Board detection > Additional information on https://pwassi.privatedns.org/openwrt/unifiac/ The additions to the mach file in the patch seem to be free of dependencies on definitions from other ubnt boards - please move them to a new mach-*.c file instead of patching them in. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] add ubifs filesystem for image building system
On 2016-01-03 22:17, Daniel Golle wrote: > On Sat, Jan 02, 2016 at 04:02:58PM +0100, Felix Fietkau wrote: >> On 2016-01-02 15:11, RhoYounJae wrote: >> > Currently, the devices which actually uses ubifs filesystem uses squashfs >> > filesystem >> > Thus openwrt binary image have a wrong squashfs- prefix not ubifs- which >> > gives user confusion >> > This patch add ubifs filesystem for image building system but not for >> > legacy system >> You're right about one thing: These images do use ubifs, however only as >> an overlay. The base filesystem is squashfs, just like on all those NOR >> flash based devices (which use jffs2 as overlay). >> >> I might accept a patch that adds ubifs as an option, if you can convince >> me that it's actually useful, but replacing the squashfs images with >> ubifs ones is not an option. > > Similar to having a JFFS2 read-write-mounted rootfs without any overlay > can make sense in certain (rare) scenaria. I intended to use a ubifs > rootfs in those situations on devices which need UBI. > There already is a way to generate images having ubifs rootfs, see e.g. > https://dev.openwrt.org/browser/trunk/target/linux/oxnas/image/Makefile#L90 Not a very good example, it still uses the old image building code ;) - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] add ubifs filesystem for image building system
On Sat, Jan 02, 2016 at 04:02:58PM +0100, Felix Fietkau wrote: > On 2016-01-02 15:11, RhoYounJae wrote: > > Currently, the devices which actually uses ubifs filesystem uses squashfs > > filesystem > > Thus openwrt binary image have a wrong squashfs- prefix not ubifs- which > > gives user confusion > > This patch add ubifs filesystem for image building system but not for > > legacy system > You're right about one thing: These images do use ubifs, however only as > an overlay. The base filesystem is squashfs, just like on all those NOR > flash based devices (which use jffs2 as overlay). > > I might accept a patch that adds ubifs as an option, if you can convince > me that it's actually useful, but replacing the squashfs images with > ubifs ones is not an option. Similar to having a JFFS2 read-write-mounted rootfs without any overlay can make sense in certain (rare) scenaria. I intended to use a ubifs rootfs in those situations on devices which need UBI. There already is a way to generate images having ubifs rootfs, see e.g. https://dev.openwrt.org/browser/trunk/target/linux/oxnas/image/Makefile#L90 UBI and UBIFS image generation is still kind of a mess because not all targets have been migrated to the 'new way' (using SysupgradeNAND and UbinizeImage) yet. Once this is done, include/image.mk can be cleaned up and the old stuff (still needed on targets relying on a static ubinize.cfg) can be removed... Cheers Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] wpa_supplicant: fix generating phase2 config line for WPA-EAP
On 2016-01-03 22:06, Daniel Golle wrote: > Hi Felix, > > On Sun, Jan 03, 2016 at 09:33:13PM +0100, Felix Fietkau wrote: >> > - append network_data "phase2=\"$auth\"" >> > "$N$T" >> > + append network_data >> > "phase2=\"auth=$auth\"" "$N$T" >> This might break existing configurations that already include the auth= >> part, so when reworking this part you should detect and fix this. >> Also, for EAP-TLS, phase2 needs to be autheap=TLS, which is not >> supported with this change. > > Right... Probably this should be changed in LuCI then, because > currently $auth is set to values like 'PAP', 'MSCHAPV2', ... see > https://github.com/openwrt/luci/blob/master/modules/luci-mod-admin-full/luasrc/model/cbi/admin_network/wifi.lua#L897 > which still matches the pre-netifd behaviour as defined in > https://dev.openwrt.org/browser/trunk/package/network/services/hostapd/files/wpa_supplicant.sh#L107 > which is what I wanted to restore. > Having a complex value stored in UCI and leaving it to the user/view > to set it seems a bit odd to me (but might still be the best thing to > do), maybe we should rather store eap_type in UCI as well and then > generate the phase2 string in netifd.sh according to that...? > > Let me know what you think and I'll suggest a follow-up patch. How about this: If $auth is set, add it with auth=$auth (strip existing auth= from the variable if present). Then add an eap_auth config option (should be a list), add autheap= for every entry (I think there can be multiple ones). That way you can configure everything and avoid complex UI-hostile types. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] wpa_supplicant: fix generating phase2 config line for WPA-EAP
Hi Felix, On Sun, Jan 03, 2016 at 09:33:13PM +0100, Felix Fietkau wrote: > > - append network_data "phase2=\"$auth\"" > > "$N$T" > > + append network_data > > "phase2=\"auth=$auth\"" "$N$T" > This might break existing configurations that already include the auth= > part, so when reworking this part you should detect and fix this. > Also, for EAP-TLS, phase2 needs to be autheap=TLS, which is not > supported with this change. Right... Probably this should be changed in LuCI then, because currently $auth is set to values like 'PAP', 'MSCHAPV2', ... see https://github.com/openwrt/luci/blob/master/modules/luci-mod-admin-full/luasrc/model/cbi/admin_network/wifi.lua#L897 which still matches the pre-netifd behaviour as defined in https://dev.openwrt.org/browser/trunk/package/network/services/hostapd/files/wpa_supplicant.sh#L107 which is what I wanted to restore. Having a complex value stored in UCI and leaving it to the user/view to set it seems a bit odd to me (but might still be the best thing to do), maybe we should rather store eap_type in UCI as well and then generate the phase2 string in netifd.sh according to that...? Let me know what you think and I'll suggest a follow-up patch. Cheers Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Allow scan of single channel
On 2015-12-17 11:47, Dmitry Ivanov wrote: > Sometimes it is enough to scan single channel only. This is much faster > than scanning all of them and ingnoring unnecessary data. > > Signed-off-by: Dmitry Ivanov When adding such an extra API, please make one that takes a list of frequencies instead of just a single one. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Add support for Netgear D7800
On 2015-12-25 12:46, Tathagata Das wrote: > Add support for the Netgear D7800 and build appropriate sysupgrade and > factory images. > > Known issues: > . USB ports are not working > . DSL is not added > > Signed-off-by: Tathagata Das > --- > .../linux/ipq806x/base-files/etc/board.d/01_leds | 1 + > .../ipq806x/base-files/etc/board.d/02_network | 1 + > target/linux/ipq806x/base-files/lib/ipq806x.sh | 3 + > .../ipq806x/base-files/lib/upgrade/platform.sh | 2 + > target/linux/ipq806x/image/Makefile| 13 +- > ...dd-Netgear-Nighthawk-X4-D7800-device-tree.patch | 381 > + > target/linux/ipq806x/profiles/netgear.mk | 13 + > 7 files changed, 413 insertions(+), 1 deletion(-) > create mode 100644 > target/linux/ipq806x/patches-3.18/801-ARM-qcom-add-Netgear-Nighthawk-X4-D7800-device-tree.patch > This patch is badly damaged by line wrapping. Please fix and resend. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] mac80211: bypass otp check in ath10k initialization (needed for TP-Link Archer C2600)
On 2015-12-25 19:08, Josh Bendavid wrote: > There is a patch added here to ath10k to bypass some checks on > startup. I believe this is related to the calibration data being > provided in external files (dumped from the ART mtd partition at init > time) rather than directly from the pcie board. The patch and related > discussion is from here: > http://lists.infradead.org/pipermail/ath10k/2015-November/006489.html. > This has also been discussed a bit further on the ath10k list here: > http://lists.infradead.org/pipermail/ath10k/2015-December/006613.html. > > Signed-off-by: Josh Bendavid I think the check should only be skipped if loading calibration data succeeded. Actually, in that case it should not even try to fetch the board id. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/3] ipq806x: add support for TP-Link Archer C2600 image building and ath10k initialization
Hi,
sorry for the late reply, could you merge patch 2/3 into this one and
split the firmware-utils part out into its one patch please ?
John
On 25/12/2015 05:58, Josh Bendavid wrote:
> Add initial support for Archer C2600 to Makefiles, profiles, led/network
> config, and hotplug script, along with needed modifications to
> tplink-safeloader in firmware-tools. This is sufficient to build a working
> factory image flashable both from stock web ui and bootloader tftp recovery.
> Sysupgrade is working as well. Added hotplug script is adapted from existing
> script for ar71xx which copies wireless calibration data from ART partition
> in flash to appropriate place in /lib/firmware.
>
> Working: Wired network, wireless (both bands), power/status/lan/wan/usb led's
>
> Not working: wireless status led's (these are not controlled through gpio,
> but rather through the QCA9980 pcie chips). Also there is no way to set the
> wan led to orange, which is possible in the stock firmware. Kernel 4.1 build
> does not boot currently.
>
> Not tested: Hardware buttons.
>
> Signed-off-by: Josh Bendavid
>
> ---
> include/image.mk | 11 ++
> .../linux/ipq806x/base-files/etc/board.d/01_leds | 7 ++
> .../ipq806x/base-files/etc/board.d/02_network | 3 +-
> .../etc/hotplug.d/firmware/11-ath10k-caldata | 66
> target/linux/ipq806x/base-files/lib/ipq806x.sh | 3 +
> .../ipq806x/base-files/lib/upgrade/platform.sh | 34 +-
> target/linux/ipq806x/image/Makefile| 24 -
> target/linux/ipq806x/profiles/tplink.mk| 20
> tools/firmware-utils/src/tplink-safeloader.c | 114
> -
> 9 files changed, 276 insertions(+), 6 deletions(-)
> create mode 100644
> target/linux/ipq806x/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> create mode 100644 target/linux/ipq806x/profiles/tplink.mk
>
> diff --git a/include/image.mk b/include/image.mk
> index 1522dd7..ee180f4 100644
> --- a/include/image.mk
> +++ b/include/image.mk
> @@ -327,6 +327,17 @@ define Build/netgear-dni
> mv $@.new $@
> endef
>
> +define Build/tplink-safe
> + $(STAGING_DIR_HOST)/bin/tplink-safeloader \
> + -B $(TPLINK_BOARD_ID) -V OpenWrt.$(REVISION) \
> + -k $(word 1,$^) \
> + -r $(word 2,$^) \
> + -j \
> + $(if $(findstring sysupgrade,$1),-S) \
> + -o $@.new
> + mv $@.new $@
> +endef
> +
> define Build/fit
> $(TOPDIR)/scripts/mkits.sh \
> -D $(DEVICE_NAME) -o $@.its -k $@ \
> diff --git a/target/linux/ipq806x/base-files/etc/board.d/01_leds
> b/target/linux/ipq806x/base-files/etc/board.d/01_leds
> index 07b5b06..46070ad6 100755
> --- a/target/linux/ipq806x/base-files/etc/board.d/01_leds
> +++ b/target/linux/ipq806x/base-files/etc/board.d/01_leds
> @@ -19,6 +19,13 @@ r7500)
> ucidef_set_led_default "wps" "WPS" "r7500:white:wps" "0"
> ucidef_set_led_default "rfkill" "rfkill" "r7500:white:rfkill" "0"
> ;;
> +c2600)
> + ucidef_set_led_usbdev "usb1" "USB 1" "usb_2:blue" "2-1"
> + ucidef_set_led_usbdev "usb2" "USB 2" "usb_4:blue" "4-1"
> + ucidef_set_led_netdev "wan" "WAN" "wan:blue" "eth0"
> + ucidef_set_led_netdev "lan" "LAN" "lan:blue" "br-lan"
> + ucidef_set_led_default "general" "general" "ledgnr:blue" "1"
> + ;;
> *)
> ;;
> esac
> diff --git a/target/linux/ipq806x/base-files/etc/board.d/02_network
> b/target/linux/ipq806x/base-files/etc/board.d/02_network
> index 1302a55..9f061e4 100755
> --- a/target/linux/ipq806x/base-files/etc/board.d/02_network
> +++ b/target/linux/ipq806x/base-files/etc/board.d/02_network
> @@ -13,7 +13,8 @@ board=$(ipq806x_board_name)
>
> case "$board" in
> ap148 |\
> -r7500)
> +r7500 |\
> +c2600)
> ucidef_add_switch "switch0" \
> "1:lan" "2:lan" "3:lan" "4:lan" "6@eth1" "5:wan" "0@eth0"
> ;;
> diff --git
> a/target/linux/ipq806x/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> b/target/linux/ipq806x/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> new file mode 100644
> index 000..7a423de
> --- /dev/null
> +++ b/target/linux/ipq806x/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> @@ -0,0 +1,66 @@
> +#!/bin/sh
> +
> +ath10kcal_die() {
> + echo "ath10cal: " "$*"
> + exit 1
> +}
> +
> +ath10kcal_from_file() {
> + local source=$1
> + local offset=$2
> + local count=$3
> +
> + dd if=$source of=/lib/firmware/$FIRMWARE bs=1 skip=$offset count=$count
> 2>/dev/null || \
> + ath10kcal_die "failed to extract calibration data from $source"
> +}
> +
> +ath10kcal_extract() {
> + local part=$1
> + local offset=$2
> + local count=$3
> + local mtd
> +
> + mtd=$(find_mtd_chardev $part)
> + [ -n "$mtd" ] || \
> + ath10kcal_die "no mtd device found for partition $part"
> +
> + dd if=$mtd of=/lib/firmware/$FIRMWARE
Re: [OpenWrt-Devel] [PATCH v2] wpa_supplicant: fix generating phase2 config line for WPA-EAP
On 2015-12-29 04:37, Daniel Golle wrote:
> Signed-off-by: Daniel Golle
> ---
> v2: missed the default definition two lines above, so no need to
> use shell-expansion for that then.
>
> package/network/services/hostapd/files/netifd.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/package/network/services/hostapd/files/netifd.sh
> b/package/network/services/hostapd/files/netifd.sh
> index 5541e4d..75d340a 100644
> --- a/package/network/services/hostapd/files/netifd.sh
> +++ b/package/network/services/hostapd/files/netifd.sh
> @@ -630,7 +630,7 @@ wpa_supplicant_add_network() {
> peap|ttls)
> json_get_vars auth password
> set_default auth MSCHAPV2
> - append network_data "phase2=\"$auth\""
> "$N$T"
> + append network_data
> "phase2=\"auth=$auth\"" "$N$T"
This might break existing configurations that already include the auth=
part, so when reworking this part you should detect and fix this.
Also, for EAP-TLS, phase2 needs to be autheap=TLS, which is not
supported with this change.
- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH RESEND] dnsmasq: add config option for ra_names
On 2015-12-29 17:58, Dominique Martinet wrote:
> Signed-off-by: Dominique Martinet
> ---
>
> I posted this quite another while ago:
> Dominique Martinet wrote on Sun, Jul 14, 2013:
>> I posted this quite a while ago:
>> Dominique Martinet wrote on Fri, Jul 06, 2012:
>>> ra_names is a feature introduced in dnsmasq 2.61, which is why I changed
>>> the rules to build something newer (and figured I might as well take it
>>> to 62)
>>> Basically, it:
>>> - does router-advertisment (not dhcpv6)
>>> - when it gets a request for RA, it looks up if there is an active ipv4
>>> lease for the same host via its MAC address, and if there is it adds
>>> the to-be ipv6 to the local dns (assuming the host will take the dns)
>>> - when it gets a dhcpv4 release it takes off the ipv6 dns record as
>>> well
>>>
>>> (since RA is stateless and doesn't give the host name, I couldn't figure
>>> any better way without dhcpv6; I was about to hack something (with a
>>> very large axe and radvd) when I found out they've done it already :D)
>>>
>>> There are also modes for router-advertisment only which I haven't looked
>>> at, and a dhcpv6 client implementation that I didn't try yet either.
>>>
>>>
>>> The option I added is in the dhcp field, a "ra_name" option with the
>>> prefix to announce in RAs, i.e.
>>>
>>> config dhcp 'lan'
>>> option interface 'lan'
>>> option ra_names '2001:dead:beef::'
>>
>>
>> Since I re-installed my router I looked to see if there was another way
>> to give dnsmasq a custom option, but couldn't find any - maybe I'm just
>> blind though.
>>
>> That being said, I think this is a nice feature for anyone with a dual
>> stack ipv4/ipv6 at home, it "just works", and if there is no other clean
>> way to add this in the config I wouldn't mind getting this added.
>> If you have any suggestion/qualms about it, please tell me and I'm
>> willing to try to get these fixed before sending a new patch.
>> (unless of course it's a "we're not interested" - but if I just need to
>> add a checkbox to luci I'll consider it.)
>>
>> The original patch inclued a dnsmasq version bump which isn't needed
>> anymore, so here's the short bit that would interest me:
>> (just checked it still applies to trunk one year later, I just had to
>> change the file path. This mail should apply with git am/git apply.)
>
> The patch didn't get any reply so I guess it's more of a "we're not
> interested"
> kind of answer, but I still like this option so trying my chance again...
> Maybe now more people (hopefully) have ipv6 this will get a new look.
>
> package/network/services/dnsmasq/files/dnsmasq.init |6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/package/network/services/dnsmasq/files/dnsmasq.init
> b/package/network/services/dnsmasq/files/dnsmasq.init
> index 630c07d..a2f274e 100644
> --- a/package/network/services/dnsmasq/files/dnsmasq.init
> +++ b/package/network/services/dnsmasq/files/dnsmasq.init
> @@ -375,6 +375,12 @@ dhcp_add() {
> xappend
> "--dhcp-range=$networkid,$START,$END,$NETMASK,$leasetime${options:+ $options}"
>
> dhcp_option_add "$cfg" "$networkid"
> +
> + config_get ra_names "$cfg" ra_names
> +
> + [ -n "$ra_names" ] && {
> + xappend "--dhcp-range=$networkid,$ra_names,ra-names,$leasetime"
> + }
It seems to me that configuring this manually limits its use. Wouldn't
it be better to integrate it with OpenWrt's prefix delegation support?
this would make it work with dynamically assigned prefixes.
When the init script runs, it could query netifd for assigned prefixes
belonging to that particular interface, and use those for ra_names.
- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] add UCI option for leasetime per static host
On 2015-12-30 06:28, ufomanf...@freaktose.net wrote: > Hi guys, > > I wanted to use this feature and decided to figure out how to commit to the > awesome OpenWrt project. > > I am completely new to development so please be kind when reviewing. I > appreciate any (constructive) feedback! > > Cheers, ufomanfred > > Edit: screw you HTML webmail client.. Patch is still broken (line wrapped). Also, the subject should have a proper prefix, e.g. 'dnsmasq:' and the email body should only contain things that should end up in the commit message, e.g. a proper description what the change does and why it does it. Please fix and resend. Thanks, - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/1] package/libs/libtool: package libtool
On 2015-12-28 03:39, Heinrich Schuchardt wrote: > Up to now only package libtldl is created form source package > GNU libtool. > > A new package libtool containing libtoolize is provided. > > Signed-off-by: Heinrich Schuchardt I think it's better to rename the libtool package in trunk to libltdl and package the full libtool in the github repo. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SHA512/SHA256 hashes truncated/busybox weirdness
On 2016-01-03 20:17, Chris Marchesi wrote: > Hey! > > I tried to change the default passwd algorithm used by busybox to > sha512, but got some strange looking hashes back by passwd after changing. > > They basically had the algorithm and the salt (maybe) squashed, like below. > > $6abCDefGH:(rest of shadow entry here) > > Admittedly I'm not used to seeing this, so I'm not too sure if it's an > issue or not. The passwords still worked after this, but I'm not too > sure if it was insecure, so I reverted it back to defaults. > > Any ideas? I'm used to seeing a full $6$salt$hash entry. I think switching from MD5 to SHA256/SHA512 is rather pointless. It slows down password cracking by a small factor, but not by real orders of magnitude, so it practically does not make much of a difference in terms of security. Since hash functions like MD5, SHA256, etc. are designed to be fast, they don't provide much real security against hardware assisted brute force cracking. All password hash algorithms except for MD5 (default) and DES (for compatibility reasons) have been stripped from libc to cut down on useless bloat. If you care about password storage security, it's better to use a function that was intentionally designed NOT to be fast, e.g. PBKDF2 or bcrypt. Feel free to send patches... - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Outstanding patches question (WNDR3700v4|WNDR4300 128MB flash and px5g SHA256 MD certs)
On 2016-01-03 20:26, Chris Marchesi wrote: > I found a couple of patches that I don't know why have not been > introduced upstream yet that I wanted to ask about. > > First one > was > https://github.com/openwrt-mirror/openwrt/commit/1dbb652ea0594c284710ace5e479c1ac7fdd1cbb, > which has also been mentioned in the WNDR3700 thread, regarding the > extension of the flash on WNDR3700v4 and WNDR4300 devices to the full > 128 MB. That openwrt-mirror thing was not created by the OpenWrt project and we don't follow pull requests sent there. There's a standard procedure for getting changes accepted into OpenWrt, and it's documented here: https://dev.openwrt.org/wiki/SubmittingPatches > The second is this one: https://patchwork.ozlabs.org/patch/538691/ - > don't know if it's been mentioned, but with the SHA1 deprecation > ongoing, this may cause increasingly more issues with certificates > generated by px5g. > > Anything I can do to help get these upstream? Put in tickets? > > I'm using both of these patches in a custom 15.05 without issue. That one is in trunk already. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Outstanding patches question (WNDR3700v4|WNDR4300 128MB flash and px5g SHA256 MD certs)
I found a couple of patches that I don't know why have not been introduced upstream yet that I wanted to ask about. First one was https://github.com/openwrt-mirror/openwrt/commit/1dbb652ea0594c284710ace5e479c1ac7fdd1cbb, which has also been mentioned in the WNDR3700 thread, regarding the extension of the flash on WNDR3700v4 and WNDR4300 devices to the full 128 MB. The second is this one: https://patchwork.ozlabs.org/patch/538691/ - don't know if it's been mentioned, but with the SHA1 deprecation ongoing, this may cause increasingly more issues with certificates generated by px5g. Anything I can do to help get these upstream? Put in tickets? I'm using both of these patches in a custom 15.05 without issue. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] SHA512/SHA256 hashes truncated/busybox weirdness
Hey! I tried to change the default passwd algorithm used by busybox to sha512, but got some strange looking hashes back by passwd after changing. They basically had the algorithm and the salt (maybe) squashed, like below. $6abCDefGH:(rest of shadow entry here) Admittedly I'm not used to seeing this, so I'm not too sure if it's an issue or not. The passwords still worked after this, but I'm not too sure if it was insecure, so I reverted it back to defaults. Any ideas? I'm used to seeing a full $6$salt$hash entry. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SDK vs. Toolchain+
On 2016-01-03 18:53, Daniel Dickinson wrote: > Hi Felix, > > I think part of the confusion stems from the fact that the current SDK > is not really an SDK but a 'Toolchain+'. Perhaps the current SDK should > be renamed to clarify that point, and a 'real' SDK created. What's a 'real' SDK as opposed to a 'Toolchain+'? > The current SDK is useless without ImageBuilder and/or package repositories. Not really. It allows you to build packages that you can put on a running system built from the same release (including out-of-tree kernel modules). - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v4 1/4] [CC] [RESEND] ramips: Fix whitespace in the rt3052 switch driver.
Signed-off-by: Vittorio Gambaletta --- --- a/target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3052.c +++ b/target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3052.c @@ -1417,19 +1417,19 @@ static int esw_probe(struct platform_device *pdev) } port_map = of_get_property(np, "ralink,portmap", NULL); -if (port_map) + if (port_map) esw->port_map = be32_to_cpu(*port_map); reg_init = of_get_property(np, "ralink,fct2", NULL); -if (reg_init) + if (reg_init) esw->reg_initval_fct2 = be32_to_cpu(*reg_init); reg_init = of_get_property(np, "ralink,fpa2", NULL); -if (reg_init) + if (reg_init) esw->reg_initval_fpa2 = be32_to_cpu(*reg_init); reg_init = of_get_property(np, "ralink,led_polarity", NULL); -if (reg_init) + if (reg_init) esw->reg_led_polarity = be32_to_cpu(*reg_init); swdev = &esw->swdev; ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v4 1/4] [CC] ramips: Fix whitespace in the rt3052 switch driver.
On 03/01/2016 18:37:03 CET, John Crispin wrote: blogic@debian:/openwrt/CC$ patchwork 561992 Applying: ramips: Fix whitespace in the rt3052 switch driver. fatal: corrupt patch at line 6 Patch failed at 0001 ramips: Fix whitespace in the rt3052 switch driver. When you have resolved this problem run "git am --resolved". If you would prefer to skip this patch, instead run "git am --skip". To restore the original branch and stop patching run "git am --abort". In fact that is stricter, patch doesn't fail... By the way, is `patchwork` a shell alias? It seems interesting. ;) if you look at line 6 and 22 of the patch you will see that the leading space is missing. how did you generate these patches ? Ehm. This particular patch has a long history, I can't remember anymore. And in fact this v4-cc-1 is the only one that's bad. For the more recent patches I used quilt. Cheers, Vittorio On 03/01/2016 18:30, Vittorio G (VittGam) wrote: Hi John, It does here... openwrt@asd:~$ git clone https://github.com/openwrt/openwrt openwrt-cc Cloning into 'openwrt-cc'... remote: Counting objects: 338616, done. remote: Compressing objects: 100% (130/130), done. remote: Total 338616 (delta 61), reused 0 (delta 0), pack-reused 338484 Receiving objects: 100% (338616/338616), 120.31 MiB | 26.38 MiB/s, done. Resolving deltas: 100% (229507/229507), done. openwrt@asd:~$ cd openwrt-cc/ openwrt@asd:~/openwrt-cc$ git checkout chaos_calmer Branch chaos_calmer set up to track remote branch chaos_calmer from origin. Switched to a new branch 'chaos_calmer' openwrt@asd:~/openwrt-cc$ patch -p1 < ../v4-cc-1.patch patching file target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3052.c openwrt@asd:~/openwrt-cc$ patch -p1 < ../v4-cc-2.patch patching file target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3052.c openwrt@asd:~/openwrt-cc$ patch -p1 < ../v4-cc-3.patch patching file target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3052.c openwrt@asd:~/openwrt-cc$ patch -p1 < ../v4-cc-4.patch patching file target/linux/ramips/dts/HT-TM02.dts openwrt@asd:~/openwrt-cc$ Cheers, Vittorio On 03/01/2016 15:53:56 CET, John Crispin wrote: Hi, the patch/series does not apply to CC John On 01/01/2016 00:00, Vittorio G (VittGam) wrote: Signed-off-by: Vittorio Gambaletta --- --- a/target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3052.c +++ b/target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3052.c @@ -1417,19 +1417,19 @@ static int esw_probe(struct platform_device *pdev) } port_map = of_get_property(np, "ralink,portmap", NULL); -if (port_map) +if (port_map) esw->port_map = be32_to_cpu(*port_map); reg_init = of_get_property(np, "ralink,fct2", NULL); -if (reg_init) +if (reg_init) esw->reg_initval_fct2 = be32_to_cpu(*reg_init); reg_init = of_get_property(np, "ralink,fpa2", NULL); -if (reg_init) +if (reg_init) esw->reg_initval_fpa2 = be32_to_cpu(*reg_init); reg_init = of_get_property(np, "ralink,led_polarity", NULL); -if (reg_init) +if (reg_init) esw->reg_led_polarity = be32_to_cpu(*reg_init); swdev = &esw->swdev; ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] SDK vs. Toolchain+
Hi Felix, I think part of the confusion stems from the fact that the current SDK is not really an SDK but a 'Toolchain+'. Perhaps the current SDK should be renamed to clarify that point, and a 'real' SDK created. The current SDK is useless without ImageBuilder and/or package repositories. Regards, Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v4 1/4] [CC] ramips: Fix whitespace in the rt3052 switch driver.
Hi, blogic@debian:/openwrt/CC$ patchwork 561992 Applying: ramips: Fix whitespace in the rt3052 switch driver. fatal: corrupt patch at line 6 Patch failed at 0001 ramips: Fix whitespace in the rt3052 switch driver. When you have resolved this problem run "git am --resolved". If you would prefer to skip this patch, instead run "git am --skip". To restore the original branch and stop patching run "git am --abort". if you look at line 6 and 22 of the patch you will see that the leading space is missing. how did you generate these patches ? John On 03/01/2016 18:30, Vittorio G (VittGam) wrote: > Hi John, > > It does here... > > openwrt@asd:~$ git clone https://github.com/openwrt/openwrt openwrt-cc > Cloning into 'openwrt-cc'... > remote: Counting objects: 338616, done. > remote: Compressing objects: 100% (130/130), done. > remote: Total 338616 (delta 61), reused 0 (delta 0), pack-reused 338484 > Receiving objects: 100% (338616/338616), 120.31 MiB | 26.38 MiB/s, done. > Resolving deltas: 100% (229507/229507), done. > openwrt@asd:~$ cd openwrt-cc/ > openwrt@asd:~/openwrt-cc$ git checkout chaos_calmer > Branch chaos_calmer set up to track remote branch chaos_calmer from origin. > Switched to a new branch 'chaos_calmer' > openwrt@asd:~/openwrt-cc$ patch -p1 < ../v4-cc-1.patch > patching file > target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3052.c > openwrt@asd:~/openwrt-cc$ patch -p1 < ../v4-cc-2.patch > patching file > target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3052.c > openwrt@asd:~/openwrt-cc$ patch -p1 < ../v4-cc-3.patch > patching file > target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3052.c > openwrt@asd:~/openwrt-cc$ patch -p1 < ../v4-cc-4.patch > patching file target/linux/ramips/dts/HT-TM02.dts > openwrt@asd:~/openwrt-cc$ > > Cheers, > Vittorio > > On 03/01/2016 15:53:56 CET, John Crispin wrote: >> Hi, >> >> the patch/series does not apply to CC >> >> John >> >> On 01/01/2016 00:00, Vittorio G (VittGam) wrote: >>> Signed-off-by: Vittorio Gambaletta >>> --- >>> >>> --- a/target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3052.c >>> +++ b/target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3052.c >>> @@ -1417,19 +1417,19 @@ static int esw_probe(struct platform_device >>> *pdev) >>> } >>> >>> port_map = of_get_property(np, "ralink,portmap", NULL); >>> -if (port_map) >>> +if (port_map) >>> esw->port_map = be32_to_cpu(*port_map); >>> >>> reg_init = of_get_property(np, "ralink,fct2", NULL); >>> -if (reg_init) >>> +if (reg_init) >>> esw->reg_initval_fct2 = be32_to_cpu(*reg_init); >>> >>> reg_init = of_get_property(np, "ralink,fpa2", NULL); >>> -if (reg_init) >>> +if (reg_init) >>> esw->reg_initval_fpa2 = be32_to_cpu(*reg_init); >>> >>> reg_init = of_get_property(np, "ralink,led_polarity", NULL); >>> -if (reg_init) >>> +if (reg_init) >>> esw->reg_led_polarity = be32_to_cpu(*reg_init); >>> >>> swdev = &esw->swdev; >>> ___ >>> openwrt-devel mailing list >>> openwrt-devel@lists.openwrt.org >>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >>> >> ___ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v4 1/4] [CC] ramips: Fix whitespace in the rt3052 switch driver.
Hi John, It does here... openwrt@asd:~$ git clone https://github.com/openwrt/openwrt openwrt-cc Cloning into 'openwrt-cc'... remote: Counting objects: 338616, done. remote: Compressing objects: 100% (130/130), done. remote: Total 338616 (delta 61), reused 0 (delta 0), pack-reused 338484 Receiving objects: 100% (338616/338616), 120.31 MiB | 26.38 MiB/s, done. Resolving deltas: 100% (229507/229507), done. openwrt@asd:~$ cd openwrt-cc/ openwrt@asd:~/openwrt-cc$ git checkout chaos_calmer Branch chaos_calmer set up to track remote branch chaos_calmer from origin. Switched to a new branch 'chaos_calmer' openwrt@asd:~/openwrt-cc$ patch -p1 < ../v4-cc-1.patch patching file target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3052.c openwrt@asd:~/openwrt-cc$ patch -p1 < ../v4-cc-2.patch patching file target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3052.c openwrt@asd:~/openwrt-cc$ patch -p1 < ../v4-cc-3.patch patching file target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3052.c openwrt@asd:~/openwrt-cc$ patch -p1 < ../v4-cc-4.patch patching file target/linux/ramips/dts/HT-TM02.dts openwrt@asd:~/openwrt-cc$ Cheers, Vittorio On 03/01/2016 15:53:56 CET, John Crispin wrote: Hi, the patch/series does not apply to CC John On 01/01/2016 00:00, Vittorio G (VittGam) wrote: Signed-off-by: Vittorio Gambaletta --- --- a/target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3052.c +++ b/target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3052.c @@ -1417,19 +1417,19 @@ static int esw_probe(struct platform_device *pdev) } port_map = of_get_property(np, "ralink,portmap", NULL); -if (port_map) + if (port_map) esw->port_map = be32_to_cpu(*port_map); reg_init = of_get_property(np, "ralink,fct2", NULL); -if (reg_init) + if (reg_init) esw->reg_initval_fct2 = be32_to_cpu(*reg_init); reg_init = of_get_property(np, "ralink,fpa2", NULL); -if (reg_init) + if (reg_init) esw->reg_initval_fpa2 = be32_to_cpu(*reg_init); reg_init = of_get_property(np, "ralink,led_polarity", NULL); -if (reg_init) + if (reg_init) esw->reg_led_polarity = be32_to_cpu(*reg_init); swdev = &esw->swdev; ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 09/14] package/signing-key base-files: Move the package list signing key to separate package
On 2016-01-03 07:02, open...@daniel.thecshore.com wrote: > From: Daniel Dickinson > > In order to make it easier to sign packages built with an SDK > we make signing-key a separate package from base-files with > a configuration option and variants (so that different builds > can use different keys) which can be easy included in images > with imagebuilder > > Signed-off-by: Daniel Dickinson This BUILD_KEY_TYPE stuff looks really quirky and convoluted. By default, the build will include the official OpenWrt key (via base-files) and the local build key (via that new signing-key package). I think it should stay that way, and if you want to include more keys, just make your own package or use files/ - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 12/14] target/sdk: Fix handling of already built packages
On 2016-01-03 16:36, Daniel Dickinson wrote: > Actually, in keeping with your comment about rather having a fork of the > source in SDKs, I'm thinking it would be better to rework all of this, > so that SDK's automatically ship the source, and figure out a better > mechanism for managing the recording of what is already built (probably > just a plain text file) which can be easily 'overridden' by removing the > record (or taking an approach similar to feeds.conf.default, only with a > generated file instead of one in the source tree). > > I hadn't thought of the issue of people shipping binary-only SDK's and > think that having the SDK have a copy of the source (but that doesn't > get in the way easy updates to the source) would be preferrable; my > object with the SDK was to build only what's needed, when it's needed, > rather than as means to ship binaries. I was thinking more in terms of > internal common code, but see how it could easily get abused, in it's > current form. I think the SDK should behave just like the normal build system. The problem with relying on prebuilt stuff in the staging dir (or even the build dir) is that quite often absolute path names leak into various places of the build, making it impossible to relocate. IMHO the only sane way to deal with that is to stop relying on prebuilt stuff in build_dir or staging_dir/target-* entirely. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 12/14] target/sdk: Fix handling of already built packages
Actually, in keeping with your comment about rather having a fork of the source in SDKs, I'm thinking it would be better to rework all of this, so that SDK's automatically ship the source, and figure out a better mechanism for managing the recording of what is already built (probably just a plain text file) which can be easily 'overridden' by removing the record (or taking an approach similar to feeds.conf.default, only with a generated file instead of one in the source tree). I hadn't thought of the issue of people shipping binary-only SDK's and think that having the SDK have a copy of the source (but that doesn't get in the way easy updates to the source) would be preferrable; my object with the SDK was to build only what's needed, when it's needed, rather than as means to ship binaries. I was thinking more in terms of internal common code, but see how it could easily get abused, in it's current form. Regards, Daniel On 03/01/16 09:51 AM, Felix Fietkau wrote: On 2016-01-03 07:03, open...@daniel.thecshore.com wrote: From: Daniel Dickinson When using SDK default to avoiding rebuilding packages previously built (within same variant of a source package; alternate variants don't cause isses so do allow them) and in addition avoid installing from feeds packages previously built. In both cases this may be overridden by a force option on the command line. For feeds install it is -f, and for building the force is FORCE_SDK="", where package variant is just source package name for non varianted packages and - for varianted packages Signed-off-by: Daniel Dickinson I think this is heading in the wrong direction, since it's somewhat fragile. Instead, I'd like to see changes that make it possible to ship the SDK without staging_dir/target-*, and allow cleaning it. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 06/14] toolchain: Allow to set libc type for external toolchains
On 2016-01-03 07:02, open...@daniel.thecshore.com wrote: > From: Daniel Dickinson > > An external toolchain, if glibc, uclibc, or musl, can benefit > from enabling the appropriate USE_ configure flags so that > packages compile correctly for the libc type > > Signed-off-by: Daniel Dickinson > --- > rules.mk | 2 +- > toolchain/Config.in| 21 + > toolchain/glibc/Config.in | 2 +- > toolchain/musl/Config.in | 2 +- > toolchain/uClibc/Config.in | 2 +- > 5 files changed, 17 insertions(+), 12 deletions(-) > > diff --git a/rules.mk b/rules.mk > index 1e7549f..eb5665d 100644 > --- a/rules.mk > +++ b/rules.mk > @@ -89,7 +89,7 @@ ifeq ($(CONFIG_EXTERNAL_TOOLCHAIN),) >REAL_GNU_TARGET_NAME=$(OPTIMIZE_FOR_CPU)-openwrt-linux$(if > $(TARGET_SUFFIX),-$(TARGET_SUFFIX)) >GNU_TARGET_NAME=$(OPTIMIZE_FOR_CPU)-openwrt-linux >DIR_SUFFIX:=_$(LIBC)-$(LIBCV)$(if $(CONFIG_arm),_eabi) > - BIN_DIR:=$(BIN_DIR)$(if $(CONFIG_USE_MUSL),,-$(LIBC)) > + BIN_DIR:=$(BIN_DIR)$(if $(CONFIG_USE_MUSL),$(if > $(CONFIG_USE_EXTERNAL_LIBC),-$(LIBC)),-$(LIBC)) >TARGET_DIR_NAME = target-$(ARCH)$(ARCH_SUFFIX)$(DIR_SUFFIX)$(if > $(BUILD_SUFFIX),_$(BUILD_SUFFIX)) >TOOLCHAIN_DIR_NAME = > toolchain-$(ARCH)$(ARCH_SUFFIX)_gcc-$(GCCV)$(DIR_SUFFIX) > else > diff --git a/toolchain/Config.in b/toolchain/Config.in > index c7072fc..1f6f753 100644 > --- a/toolchain/Config.in > +++ b/toolchain/Config.in > @@ -143,6 +143,11 @@ menuconfig TOOLCHAINOPTS > bool "Toolchain Options" if DEVEL > depends on NEED_TOOLCHAIN > > +menuconfig EXTERNAL_TOOLCHAIN_OPTS > + bool "Define external toolchain options" if DEVEL > + depends on !NEED_TOOLCHAIN > + > + > menuconfig EXTRA_TARGET_ARCH > bool > prompt "Enable an extra toolchain target architecture" if TOOLCHAINOPTS Can you get rid of EXTERNAL_TOOLCHAIN_OPTS and check for NEED_TOOLCHAIN in the right places instead? > @@ -178,7 +183,7 @@ menuconfig EXTRA_TARGET_ARCH > > > choice > - prompt "MIPS64 user-land ABI" if TOOLCHAINOPTS && (mips64 || > mips64el) > + prompt "MIPS64 user-land ABI" if ( TOOLCHAINOPTS || > EXTERNAL_TOOLCHAIN_OPTS ) && (mips64 || mips64el) > default MIPS64_ABI_N64 > help > MIPS64 supports 3 different user-land ABIs: o32 (legacy), > @@ -209,7 +214,7 @@ comment "C Library" > depends on TOOLCHAINOPTS > > choice > - prompt "C Library implementation" if TOOLCHAINOPTS > + prompt "C Library implementation" if ( TOOLCHAINOPTS || > EXTERNAL_TOOLCHAIN_OPTS ) > default LIBC_USE_GLIBC if mips64 || mips64el > default LIBC_USE_UCLIBC if arc > default LIBC_USE_MUSL > @@ -281,15 +286,15 @@ source "toolchain/musl/Config.version" > > config LIBC > string > - default "glibc" if USE_GLIBC > - default "uClibc" if USE_UCLIBC > - default "musl"if USE_MUSL > + default "glibc" if ( USE_GLIBC && !EXTERNAL_TOOLCHAIN ) > + default "uClibc" if ( USE_UCLIBC && !EXTERNAL_TOOLCHAIN ) > + default "musl"if ( USE_MUSL && !EXTERNAL_TOOLCHAIN ) > > config LIBC_VERSION > string > - default GLIBC_VERSION if USE_GLIBC > - default UCLIBC_VERSION if USE_UCLIBC > - default MUSL_VERSIONif USE_MUSL > + default GLIBC_VERSION if ( USE_GLIBC && !EXTERNAL_TOOLCHAIN ) > + default UCLIBC_VERSION if ( USE_UCLIBC && !EXTERNAL_TOOLCHAIN ) > + default MUSL_VERSIONif ( USE_MUSL && !EXTERNAL_TOOLCHAIN ) > > config TARGET_SUFFIX > string > diff --git a/toolchain/glibc/Config.in b/toolchain/glibc/Config.in > index 66ff2f4..fcda4c9 100644 > --- a/toolchain/glibc/Config.in > +++ b/toolchain/glibc/Config.in > @@ -16,6 +16,6 @@ choice > endchoice > > menu "eglibc configuration" > - depends on TOOLCHAINOPTS && USE_GLIBC && EGLIBC_USE_VERSION_2_19 > + depends on TOOLCHAINOPTS && USE_GLIBC && EGLIBC_USE_VERSION_2_19 && > !EXTERNAL_TOOLCHAIN > source toolchain/glibc/config/Config.in > endmenu You can simplify a lot of this by adding this around blocks of code/includes: if TOOLCHAINOPTS ... endif - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 14/14] target/sdk: Allow building buildroot + kernel only SDK/IB
On 2016-01-03 07:03, open...@daniel.thecshore.com wrote: > From: Daniel Dickinson > > In keeping with the theme of building a common base and branching > out we introduce the concept of a minimal SDK which is essentially > the build machinery plus the kernel and it's dependencies (e.g. > hostapd on which mac80211 depends, and usign on which package > signing depends). The minimal package selection may be tailored > further (e.g. if one does not want to build all kernel modules) > via the usual means as the minimal SDK package selection is > done via defaults, not requirements. > > The same build that builds the minimal SDK would be used to > build a non-standalone SDK (since by default with minimal SDK > not all packages required for a working image are built) which > can be used with repositories containing the packages built at > the various stages to create viable images. > > Signed-off-by: Daniel Dickinson > --- > config/Config-build.in | 13 + > config/Config-images.in | 13 + > include/target.mk | 124 > > scripts/metadata.pl | 19 ++- > scripts/metadata.pm | 1 + > target/convert-config.pl| 3 ++ > target/sdk/Config-in-sdk.in | 4 ++ > 7 files changed, 176 insertions(+), 1 deletion(-) > > diff --git a/config/Config-images.in b/config/Config-images.in > index a60dd50..1731f94 100644 > --- a/config/Config-images.in > +++ b/config/Config-images.in > @@ -8,6 +8,7 @@ menu "Target Images" > > menuconfig TARGET_ROOTFS_INITRAMFS > bool "ramdisk" > + default n if SDK_CORE > default y if USES_INITRAMFS > help > Embed the root filesystem into the kernel (initramfs). Why not just hide the entire menu if SDK_CORE is set? > diff --git a/include/target.mk b/include/target.mk > index f129298..30c02de 100644 > --- a/include/target.mk > +++ b/include/target.mk > @@ -11,6 +11,129 @@ __target_inc=1 > # default device type > DEVICE_TYPE?=router > > +# Default packages when building SDK_CORE (minimal set of source packages > +# required by a 'build machinery plus all kernel module build', but do build > +# all packages of the same variant from dependency chain source packages > +# by default). This approach is taken to avoid potentially conflicting > packages, > +# which could be an issue with multiple builds of the same variant (e.g. due > to > +# one binary package of the variant built for the SDK and another by the SDK > in > +# a separate build). > +# Hostapd source package is required by mac80211, ubus by hostapd, libubox > +# by ubus, lua by ubus, libjson-c by libubox, > +# usign is required for package signing, and wireless-tools is required by > +# broadcom-wl and hostap-driver, toolchain by the toolchain, various > firmware > +# are required by kernel packages, iptables by netfilter kernel modules, > +# and opkg by by build system, and signing-key is required for the signing > key > +# > +# Note this is done one package per-line for both ease of editing > +# and because as one long line it exceed's git send-email's line > +# length limit. > +DEFAULT_SDK_CORE_PACKAGES:=\ > +hostapd-common \ > +hostadp-common-old \ > +hostapd-mini \ > +hostapd-utils \ > +wpad-mini \ > +wpa-supplicant-mini \ > +wpa-cli \ > +libubus \ > +libubus-lua \ > +ubus \ > +ubusd \ > +libubox \ > +libblobmsg-json \ > +jshn \ > +libjson-script \ > +libubox-lua \ > +liblua \ > +lua \ > +luac \ > +lua-examples \ > +usign \ > +wireless-tools \ > +libiw \ > +libgcc \ > +libatomic \ > +libssp \ > +libstdcpp \ > +libc \ > +libpthread \ > +libphtread-db \ > +librt \ > +libgfortran \ > +ldd \ > +ldconfig \ > +glibc \ > +musl \ > +uClibc \ > +wlc \ > +wl \ > +nas \ > +om-watchdog \ > +ltq-vdsl-vr9 \ > +kmod-ltq-adsl-danube-fw-a \ > +kmod-ltq-adsl-danube-fw-ba \ > +kmod-ltq-adsl-ase-fw-a \ > +kmod-ltq-adsl-ase-fw-b \ > +kmod-ltq-adsl-ar9-fw-a \ > +kmod-ltq-adsl-ar9-fw-b \ > +ltq-vsdl-mei_test \ > +ar3k-firmware \ > +ibt-firmware \ > +r8169-firmware \ > +r8189eu-firmware \ > +iptables \ > +iptables-mod-conntrack-extra \ > +iptables-mod-extra \ > +iptables-mod-filter \ > +iptables-mod-ipopt \ > +iptables-mod-ipsec \ > +iptables-mod-ipset \ > +iptables-mod-nat-extra \ > +iptables-mod-iprange \ > +iptables-mod-cluster \ > +iptables-mod-clusterip \ > +iptables-mod-ulog \ > +iptables-mod-hashlimit \ > +iptables-mod-led \ > +iptables-mod-tproxy \ > +iptables-mod-tee \ > +iptables-mod-u32 \ > +iptables-mod-nflog \ > +iptables-mod-nfqueue \ > +ip6tables \ > +ip6tables-extra \ > +ip6tables-mod-nat \ > +libiptc \ > +libip4tc \ > +libip6tc \ > +libxtables \ > +iptables-mod-compat-xtables \ > +iptables-mod-nathelper-rtsp \ > +iptables-mod-account \ > +iptables-mod-chaos \ > +iptables-mod-condition \ > +iptables-mod-delude \ > +iptables-mod-dhcpmac \ > +iptables-mod-dnetmap \ > +iptables-mod-fuzzy \ > +iptables-mod-geoip \ > +iptables-mod-iface \ > +iptable
Re: [OpenWrt-Devel] [PATCH 13/14] target/sdk: Allow building a more complete SDK from within an SDK
On 2016-01-03 07:03, open...@daniel.thecshore.com wrote: > From: Daniel Dickinson > > This patch allows using and SDK to build additional packages to > create a more complete SDK (e.g. you could start with a base > system SDK and use it to create an SDK that has libraries from > both base and packages feed). This allows for new workflows > that build a common base and then branch in different directions > depending on the type of system being build (e.g. router vs. > NAS). > > Signed-off-by: Daniel Dickinson I'm not sure I like where this is going. I think this is encouraging people too much to reuse other people's binary crap without regard for shipping proper corresponding source code. I certainly would not like to see proliferation of such SDKs in the wild, as many people and organizations tend to be careless about shipping corresponding source code. Even though it may take a bit longer to build, I'd much rather have SDKs contain forks of relevant source packages instead. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v4 1/4] [CC] ramips: Fix whitespace in the rt3052 switch driver.
Hi, the patch/series does not apply to CC John On 01/01/2016 00:00, Vittorio G (VittGam) wrote: > Signed-off-by: Vittorio Gambaletta > --- > > --- a/target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3052.c > +++ b/target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3052.c > @@ -1417,19 +1417,19 @@ static int esw_probe(struct platform_device *pdev) > } > > port_map = of_get_property(np, "ralink,portmap", NULL); > -if (port_map) > + if (port_map) > esw->port_map = be32_to_cpu(*port_map); > > reg_init = of_get_property(np, "ralink,fct2", NULL); > -if (reg_init) > + if (reg_init) > esw->reg_initval_fct2 = be32_to_cpu(*reg_init); > > reg_init = of_get_property(np, "ralink,fpa2", NULL); > -if (reg_init) > + if (reg_init) > esw->reg_initval_fpa2 = be32_to_cpu(*reg_init); > > reg_init = of_get_property(np, "ralink,led_polarity", NULL); > -if (reg_init) > + if (reg_init) > esw->reg_led_polarity = be32_to_cpu(*reg_init); > > swdev = &esw->swdev; > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 12/14] target/sdk: Fix handling of already built packages
On 2016-01-03 07:03, open...@daniel.thecshore.com wrote: > From: Daniel Dickinson > > When using SDK default to avoiding rebuilding packages previously built > (within same variant of a source package; alternate variants don't cause > isses so do allow them) and in addition avoid installing from feeds > packages previously built. In both cases this may be overridden > by a force option on the command line. > > For feeds install it is -f, and for building the force is > FORCE_SDK="", > where package variant is just source package name for non > varianted packages and - for varianted > packages > > Signed-off-by: Daniel Dickinson I think this is heading in the wrong direction, since it's somewhat fragile. Instead, I'd like to see changes that make it possible to ship the SDK without staging_dir/target-*, and allow cleaning it. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] export KERNEL_INITRAMFS_IMAGE
On 2016-01-03 14:26, YounJae Rho wrote: > `Build/ubnt-erx-factory-kernel` in `target\linux\ramips\image\Makefile` > references `$(KERNEL_INITRAMFS_IMAGE)` > which is not exported > > Signed-off-by: YounJae Rho Still doesn't apply. Please send patches to yourself instead of the list and try applying them with 'git am' until you've sorted this out. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 11/14] target/imagebuilder: Add ability to menuconfig image options
On 2016-01-03 07:02, open...@daniel.thecshore.com wrote: > From: Daniel Dickinson > > It is convenient to be able to change image generation options > (including types of images, version information, and things > like squashfs parameters) at the time of image generations, > therefore add ability to do image generation menuconfig in > ImageBuilder. > > Signed-off-by: Daniel Dickinson I think for this kind of configuration, adding menuconfig to the image builder is overkill. Why not just let the user edit a text file instead? - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] export KERNEL_INITRAMFS_IMAGE
`Build/ubnt-erx-factory-kernel` in `target\linux\ramips\image\Makefile` references `$(KERNEL_INITRAMFS_IMAGE)` which is not exported Signed-off-by: YounJae Rho --- include/image.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/image.mk b/include/image.mk index 1522dd7..6a3595e 100644 --- a/include/image.mk +++ b/include/image.mk @@ -461,7 +461,7 @@ define Device/ExportVar endef define Device/Export - $(foreach var,$(DEVICE_VARS) DEVICE_NAME KERNEL KERNEL_INITRAMFS,$(call Device/ExportVar,$(1),$(var))) + $(foreach var,$(DEVICE_VARS) DEVICE_NAME KERNEL KERNEL_INITRAMFS KERNEL_INITRAMFS_IMAGE,$(call Device/ExportVar,$(1),$(var))) $(1) : FILESYSTEM:=$(2) endef -- 2.5.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Board detection for Lamobo R1 fails again
Addendum: u-boot was bumped ten days ago to 2016.01-rc2 for sunxi with commit http://git.openwrt.org/?p=openwrt.git;a=commit;h=dd2b7afc88a0df1cadb43451104bef9337acae34 The "Lamobo Banana Pi R1" string was in the file package/boot/boot-sunxi/patches/002-add-lamobo-r1.diff which got deleted with the bump, as upstream provides the dts now. The official string from upstreams seems to be "Lamobo R1". This pretty explains the hickup experienced. Kind regards, Vasco ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Board detection for Lamobo R1 fails again
Hi, with the latest trunk the board.d detection script for the Lamobo Banana Pi R1 fails again. This time the value is cat /proc/device-tree/model Lamobo R1 Sadliy this is the model name before my previous complaint at end of November, when the dt reported "Lamobo Banana Pi R1" Apparently u-bloat had been updated to 2016.01-rc2 since then. The former u-bloat version was 2015.07. Maybe someone else with this particular board could verify it and revert http://git.openwrt.org/?p=openwrt.git;a=commit;h=a56638a303a2fe931273cbff493b485dc0f5f409 then. Kind regards, Vasco ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] busybox: include config files relative to serveral Config.in
On 2016-01-03 06:35, Wensheng Tang wrote: > Once reported at https://dev.openwrt.org/ticket/18552. When using SDK we > shouldn't use absolute path in the Config.in. > > Signed-off-by: Wensheng Tang mailto:sp3...@gmail.com>> This patch is whitespace mangled and does not apply. Additionally, the script that generated these files needs to be adjusted as well. I've taken care of this in r48078 Thanks, - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] export KERNEL_INITRAMFS_IMAGE
On 2016-01-03 04:55, RhoYounJae wrote: > `Build/ubnt-erx-factory-kernel` in `target\linux\ramips\image\Makefile` > references `$(KERNEL_INITRAMFS_IMAGE)` > which is not exported > > Signed-off-by: YounJae Rho Your patch is whitespace mangled and does not apply. Please consider using git send-email to avoid such issues. Thanks, - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] mvebu: fix WRT1900AC v1 LED driver module
Update OpenWRT build tree to reflect changes in TLC-591xx LED family driver. In kernels < 4.0 the driver was present in form of a patch for the TLC-59116 chip, and was upstreamed later in kernels > 4.0 to support the entire chip family. Signed-off-by: Sebastian Careba --- package/kernel/linux/modules/leds.mk | 16 target/linux/mvebu/profiles/linksys.mk | 2 +- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/package/kernel/linux/modules/leds.mk b/package/kernel/linux/modules/leds.mk index 996deb3..b0e22db 100644 --- a/package/kernel/linux/modules/leds.mk +++ b/package/kernel/linux/modules/leds.mk @@ -199,17 +199,17 @@ endef $(eval $(call KernelPackage,leds-pca963x)) -define KernelPackage/leds-tlc59116 +define KernelPackage/leds-tlc591xx SUBMENU:=$(LEDS_MENU) - TITLE:=TLC59116 LED support + TITLE:=TLC591xx LED support DEPENDS:=@TARGET_mvebu +kmod-i2c-core +kmod-regmap - KCONFIG:=CONFIG_LEDS_TLC59116 - FILES:=$(LINUX_DIR)/drivers/leds/leds-tlc59116.ko - AUTOLOAD:=$(call AutoLoad,60,leds-tlc59116,1) + KCONFIG:=CONFIG_LEDS_TLC591xx + FILES:=$(LINUX_DIR)/drivers/leds/leds-tlc591xx.ko + AUTOLOAD:=$(call AutoLoad,60,leds-tlc591xx,1) endef -define KernelPackage/leds-tlc59116/description - Kernel module for LEDs on TLC59116 +define KernelPackage/leds-tlc591xx/description + Kernel module for LEDs on TLC591xx endef -$(eval $(call KernelPackage,leds-tlc59116)) +$(eval $(call KernelPackage,leds-tlc591xx)) diff --git a/target/linux/mvebu/profiles/linksys.mk b/target/linux/mvebu/profiles/linksys.mk index 1a5b8af..9c954bd 100644 --- a/target/linux/mvebu/profiles/linksys.mk +++ b/target/linux/mvebu/profiles/linksys.mk @@ -53,7 +53,7 @@ define Profile/Mamba kmod-ata-core kmod-ata-marvell-sata \ kmod-rtc-marvell kmod-thermal-armada \ kmod-gpio-button-hotplug kmod-hwmon-tmp421 \ - kmod-hwmon-pwmfan kmod-leds-tlc59116 \ + kmod-hwmon-pwmfan kmod-leds-tlc591xx \ kmod-ledtrig-usbdev kmod-mwlwifi wpad-mini \ swconfig endef -- 2.1.4 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] mvebu: fix LED's module
Update OpenWRT build tree to reflect changes in TLC-591xx LED family driver. In kernels < 4.0 the driver was present in form of a patch, and was upstreamed later in kernels > 4.0. Signed-off-by: Sebastian Careba --- package/kernel/linux/modules/leds.mk | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/package/kernel/linux/modules/leds.mk b/package/kernel/linux/modules/leds.mk index 996deb3..b0e22db 100644 --- a/package/kernel/linux/modules/leds.mk +++ b/package/kernel/linux/modules/leds.mk @@ -199,17 +199,17 @@ endef $(eval $(call KernelPackage,leds-pca963x)) -define KernelPackage/leds-tlc59116 +define KernelPackage/leds-tlc591xx SUBMENU:=$(LEDS_MENU) - TITLE:=TLC59116 LED support + TITLE:=TLC591xx LED support DEPENDS:=@TARGET_mvebu +kmod-i2c-core +kmod-regmap - KCONFIG:=CONFIG_LEDS_TLC59116 - FILES:=$(LINUX_DIR)/drivers/leds/leds-tlc59116.ko - AUTOLOAD:=$(call AutoLoad,60,leds-tlc59116,1) + KCONFIG:=CONFIG_LEDS_TLC591xx + FILES:=$(LINUX_DIR)/drivers/leds/leds-tlc591xx.ko + AUTOLOAD:=$(call AutoLoad,60,leds-tlc591xx,1) endef -define KernelPackage/leds-tlc59116/description - Kernel module for LEDs on TLC59116 +define KernelPackage/leds-tlc591xx/description + Kernel module for LEDs on TLC591xx endef -$(eval $(call KernelPackage,leds-tlc59116)) +$(eval $(call KernelPackage,leds-tlc591xx)) -- 2.1.4 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] dev.openwrt.org not sending emails
On 30 December 2015 at 13:08, Nemesis wrote: > The ticket has been created, but an error occurred while sending > notifications: [Errno 111] Connection refused > > I also did not receive the confirmation mail with the token to activate > my trac account. Seems it's fixed now (2 days ago I believe). -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
