Re: [LEDE-DEV] gen_initramfs_list.sh escaping problem or stale dependency file?
On Mon, Sep 12, 2016 at 05:12:15PM -0700, Florian Fainelli wrote:
> Hi,
>
> I have a root filesystem embedding filenames that look like these:
>
> /lib/data/:
>
> these are essentially files that can be matched against an USB
> vendor/product id in an easy way.
>
> Now, the fun part is that this is only a problem when doing the
> following (using OpenWrt/LEDE as a build system):
>
> 1:
> - set CONFIG_INITRAMFS_SOURCE=""
> - build kernel modules
> - build my user-space tools
> - build the kernel image
> - reconfigure the kernel to now use an initramfs
> - build the kernel w/ initramfs
>
> and then back to step 1 with the kernel build, would I hit this error:
>
> usr/Makefile:64: *** multiple target patterns. Stop.
[...]
> Which sorts of make sense here because the file name contains a ":"
> which is not escaped, so GNU Make tries to interpret it.
>
> Now the part that does not quite make sense to me is why this file is
> even relevant here considering that the first thing we do is set
> CONFIG_INITRAMFS_SOURCE="" to disable the initramfs basically.
It is possible that we read usr/Makefile twice for some reason. But the
real problem is the lack of escaping. Can you try the following
(untested) patch?
diff --git a/scripts/gen_initramfs_list.sh b/scripts/gen_initramfs_list.sh
index 17fa901418ae..5d3188e74101 100755
--- a/scripts/gen_initramfs_list.sh
+++ b/scripts/gen_initramfs_list.sh
@@ -97,7 +97,10 @@ print_mtime() {
}
list_parse() {
- [ ! -L "$1" ] && echo "$1 \\" || :
+ if [ -L "$1" ]; then
+ return
+ fi
+ echo "$1" | sed 's/\([:%]\)/\\\1/g; s/$/ \\/'
}
# for each file print a line in following format
Thanks,
Michal
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 0/6] Add check-size when append-kernel is used
12.09.2016 06:33, Chris Blake: > These patches are the outcome of discussions had at > http://lists.infradead.org/pipermail/lede-dev/2016-September/002693.html, > where append-kernel was failing to properly offset kernels due to a typo. Out > of this, it was also > found that kernels are not checked for size, which can cause issues down the > line as kernel images get larger > over time. The following series of patches ensures that any kernel added by > append-kernel is checked > to ensure it fits within it's defined size on targets that use this function. > > Cc: Mathias Kresin > Signed-off-by: Chris Blake > > Chris Blake (6): > apm821xx: Add default kernel size > apm821xx: Add check-size when append-kernel is used > ar71xx: Add check-size when append-kernel is used > ipq806x: Add check-size when append-kernel is used > kirkwood: Add check-size when append-kernel is used > mvebu: Add check-size when append-kernel is used > > target/linux/apm821xx/image/Makefile | 5 +++-- > target/linux/ar71xx/image/generic.mk | 4 ++-- > target/linux/ar71xx/image/ubnt.mk| 2 +- > target/linux/ipq806x/image/Makefile | 2 +- > target/linux/kirkwood/image/Makefile | 4 ++-- > target/linux/mvebu/image/Makefile| 2 +- > 6 files changed, 10 insertions(+), 9 deletions(-) During a chat with Christian Lamparter about the factory image format of the WNDR4700, he pointed out that the kernel size check shouldn't be required. If KERNEL_SIZE is defined this check is already done on Device/Build/kernel [0]. Indeed, it works this way for all targets except ar71xx. This leads me to the conclusion that my last patch just workaround the underlying issue. I'll try to find the underlying issue later the day. Sorry for not spotting this before I've requested the changes. Mathias [0] https://github.com/lede-project/source/blob/master/include/image.mk#L453 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] A Wiki for LEDE Documentation
On 09/12/2016 10:42 PM, Jan-Tarek Butt wrote: > Hi, > >> Yeah, I'm also willing to dedicate some hours per week to wiki gardening, >> whatever wiki technology is chosen. > Shall I do set up a dokuwiki on our open wireless community infrastructure? > > cheers > Tarek Ok for me but I'm not a LEDE dev (more like an old-time OpenWRT user), so yeah. We got no answer from LEDE devs apart from jow saying he had some space on the server and asking what wiki people prefers, but that discussion died up quickly. I'd personally prefer your "jump the gun" approach where someone starts the wiki unofficially and all those that want to contribute do it there before we get old waiting. Whenever they feel like it they can always let the unofficial wiki become official, or not, it's not really relevant anymore once that wiki is good and working. If you do start the wiki, please cc the news to all others that might be interested from last week's discussion so we can get them there. -Alberto ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] mac80211: stop brcmfmac from selecting all PCIe firmwares
From: Rafał Miłecki Now we have firmwares separated and bcm53xx selecting required ones make use of it to actually save that rootfs space. Other targets using brcmfmac (brcm2708 and sunxi) use SDIO interface and firmware so they don't won't be affected. Signed-off-by: Rafał Miłecki --- package/kernel/mac80211/Makefile | 1 - 1 file changed, 1 deletion(-) diff --git a/package/kernel/mac80211/Makefile b/package/kernel/mac80211/Makefile index 44a2b43..adc9bca 100644 --- a/package/kernel/mac80211/Makefile +++ b/package/kernel/mac80211/Makefile @@ -682,7 +682,6 @@ define KernelPackage/brcmfmac TITLE:=Broadcom IEEE802.11n USB FullMAC WLAN driver URL:=https://wireless.wiki.kernel.org/en/users/drivers/brcm80211 DEPENDS+= @USB_SUPPORT +kmod-cfg80211 +@DRIVER_11N_SUPPORT +kmod-brcmutil \ - +BRCMFMAC_PCIE:brcmfmac-firmware-43602a1-pcie +BRCMFMAC_PCIE:brcmfmac-firmware-4366b1-pcie \ +BRCMFMAC_SDIO:kmod-mmc +BRCMFMAC_SDIO:brcmfmac-firmware-sdio \ +BRCMFMAC_USB:kmod-usb-core +BRCMFMAC_USB:brcmfmac-firmware-usb FILES:=$(PKG_BUILD_DIR)/drivers/net/wireless/broadcom/brcm80211/brcmfmac/brcmfmac.ko -- 2.9.3 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Metallurgical products
Hello, I’m contacting You on behalf of the company that offers solutions for flat and bent steel parts. We have more than 25 years of experience in metal industry and more than 15 years in laser cutting. The quality of our actions has been checked and approved by issuing ISO 9001:2000 certificate by a leading certifying authority – PIHZ [Polish Chamber of Foreign Trade]. We have 7 service centres, 14 lasers, 378 employees and 30.000 square meters of production and warehouse surface. We can pack and deliver purchased products to a designated address in Southern Sweden by ourselves. With regard to the above mentioned, may I present You more information concerning our ability to produce flat and bent steel parts for your company? Best Regards, Tomasz Zambrzycki Service Centre Manager www.steel-elements.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH netifd 2/3] interface-ip: DNS name server sorting support in resolv.conf.auto
Interface name servers when being written to resolv.conf.auto are sorted
based on the following parameters:
-Primary sorting key is interface dns_metric; name servers having lowest
interface dns_metric are listed first
-Secondary sorting key is interface metric; in case of equal interface
dns_metric name servers having lowest interface metric are listed first
-Finally alphabetical order of the interface names in case of equal
interface dns_metric and metric
In case the resolver queries the multiple servers in the order
listed; sorting is usefull in the following scenarios :
-Name resolving over a main and backup interface
-Assign priority to IPv6 name servers over IPv4 or vice versa
Signed-off-by: Hans Dedecker
---
interface-ip.c | 73 +++---
interface.c| 6 +
interface.h| 1 +
ubus.c | 1 +
4 files changed, 68 insertions(+), 13 deletions(-)
diff --git a/interface-ip.c b/interface-ip.c
index 26a2865..24ea054 100644
--- a/interface-ip.c
+++ b/interface-ip.c
@@ -1197,21 +1197,33 @@ write_resolv_conf_entries(FILE *f, struct
interface_ip_settings *ip, const char
}
}
-void
-interface_write_resolv_conf(void)
+/* Sorting of interface resolver entries : */
+/* Primary on interface dns_metric : lowest metric first */
+/* Secondary on interface metric : lowest metric first */
+/* Finally alphabetical order of interface names */
+static int resolv_conf_iface_cmp(const void *k1, const void *k2, void *ptr)
+{
+ const struct interface *iface1 = k1, *iface2 = k2;
+
+ if (iface1->dns_metric != iface2->dns_metric)
+ return iface1->dns_metric - iface2->dns_metric;
+
+ if (iface1->metric != iface2->metric)
+ return iface1->metric - iface2->metric;
+
+ return strcmp(iface1->name, iface2->name);
+}
+
+static void
+__interface_write_dns_entries(FILE *f)
{
struct interface *iface;
- char *path = alloca(strlen(resolv_conf) + 5);
- FILE *f;
- uint32_t crcold, crcnew;
+ struct {
+ struct avl_node node;
+ } *entry, *n_entry;
+ struct avl_tree resolv_conf_iface_entries;
- sprintf(path, "%s.tmp", resolv_conf);
- unlink(path);
- f = fopen(path, "w+");
- if (!f) {
- D(INTERFACE, "Failed to open %s for writing\n", path);
- return;
- }
+ avl_init(&resolv_conf_iface_entries, resolv_conf_iface_cmp, false,
NULL);
vlist_for_each_element(&interfaces, iface, node) {
if (iface->state != IFS_UP)
@@ -1219,15 +1231,50 @@ interface_write_resolv_conf(void)
if (vlist_simple_empty(&iface->proto_ip.dns_search) &&
vlist_simple_empty(&iface->proto_ip.dns_servers) &&
- vlist_simple_empty(&iface->config_ip.dns_search) &&
+ vlist_simple_empty(&iface->config_ip.dns_search) &&
vlist_simple_empty(&iface->config_ip.dns_servers))
continue;
+ entry = calloc(1, sizeof(*entry));
+ if (!entry)
+ continue;
+
+ entry->node.key = iface;
+ avl_insert(&resolv_conf_iface_entries, &entry->node);
+ }
+
+ avl_for_each_element(&resolv_conf_iface_entries, entry, node) {
+ iface = (struct interface *)entry->node.key;
+
fprintf(f, "# Interface %s\n", iface->name);
+
write_resolv_conf_entries(f, &iface->config_ip, iface->ifname);
+
if (!iface->proto_ip.no_dns)
write_resolv_conf_entries(f, &iface->proto_ip,
iface->ifname);
}
+
+ avl_remove_all_elements(&resolv_conf_iface_entries, entry, node,
n_entry)
+ free(entry);
+}
+
+void
+interface_write_resolv_conf(void)
+{
+ char *path = alloca(strlen(resolv_conf) + 5);
+ FILE *f;
+ uint32_t crcold, crcnew;
+
+ sprintf(path, "%s.tmp", resolv_conf);
+ unlink(path);
+ f = fopen(path, "w+");
+ if (!f) {
+ D(INTERFACE, "Failed to open %s for writing\n", path);
+ return;
+ }
+
+ __interface_write_dns_entries(f);
+
fflush(f);
rewind(f);
crcnew = crc32_file(f);
diff --git a/interface.c b/interface.c
index 71e2ecc..5870422 100644
--- a/interface.c
+++ b/interface.c
@@ -35,6 +35,7 @@ enum {
IFACE_ATTR_PEERDNS,
IFACE_ATTR_DNS,
IFACE_ATTR_DNS_SEARCH,
+ IFACE_ATTR_DNS_METRIC,
IFACE_ATTR_METRIC,
IFACE_ATTR_INTERFACE,
IFACE_ATTR_IP6ASSIGN,
@@ -57,6 +58,7 @@ static const struct blobmsg_policy
iface_attrs[IFACE_ATTR_MAX] = {
[IFACE_ATTR_METRIC] = { .name = "metric", .type = BLOBMSG_TYPE_INT32 },
[IFACE_ATTR_DNS] = { .name = "dns", .type = BLOBMSG_TYPE_ARRAY },
[IFACE_ATTR_DNS_SEARCH] = { .name = "dns_search", .type =
BLOBMSG_TYPE_ARRAY
[LEDE-DEV] [PATCH netifd 1/3] bridge: Allow setting multicast_fast_leave_option
Setting the multicast_fast_leave option of a bridge allows to control
the forwarding of multicast traffic when an IGMP/MLD leave is received.
In case multicast_leave_option is enabled and a leave is received the
multicast membership will immediately be dropped on the bridge port while
in the other case the multicast membership will time out in the bridge.
This could be usefull in scenarios where explicit multicast membership
host tracking is not supported in the upstream network. In this case the
multicast stream is still flowing after a leave is received resulting into
possible bandwidth saturation on the lan if a new stream is joined as
multiple multicast streams are received.
Signed-off-by: Hans Dedecker
---
device.c | 9 +
device.h | 3 +++
system-linux.c | 9 +
3 files changed, 21 insertions(+)
diff --git a/device.c b/device.c
index fa3d00f..d45ce63 100644
--- a/device.c
+++ b/device.c
@@ -51,6 +51,7 @@ static const struct blobmsg_policy dev_attrs[__DEV_ATTR_MAX]
= {
[DEV_ATTR_DADTRANSMITS] = { .name = "dadtransmits", .type =
BLOBMSG_TYPE_INT32 },
[DEV_ATTR_MULTICAST_TO_UNICAST] = { .name = "multicast_to_unicast",
.type = BLOBMSG_TYPE_BOOL },
[DEV_ATTR_MULTICAST_ROUTER] = { .name = "multicast_router", .type =
BLOBMSG_TYPE_INT32 },
+ [DEV_ATTR_MULTICAST_FAST_LEAVE] = { .name = "multicast_fast_leave", .
type = BLOBMSG_TYPE_BOOL },
[DEV_ATTR_MULTICAST] = { .name ="multicast", .type = BLOBMSG_TYPE_BOOL
},
[DEV_ATTR_LEARNING] = { .name ="learning", .type = BLOBMSG_TYPE_BOOL },
[DEV_ATTR_UNICAST_FLOOD] = { .name ="unicast_flood", .type =
BLOBMSG_TYPE_BOOL },
@@ -184,6 +185,7 @@ device_merge_settings(struct device *dev, struct
device_settings *n)
s->multicast : os->multicast;
n->multicast_to_unicast = s->multicast_to_unicast;
n->multicast_router = s->multicast_router;
+ n->multicast_fast_leave = s->multicast_fast_leave;
n->learning = s->learning;
n->unicast_flood = s->unicast_flood;
n->flags = s->flags | os->flags | os->valid_flags;
@@ -304,6 +306,11 @@ device_init_settings(struct device *dev, struct blob_attr
**tb)
DPRINTF("Invalid value: %d - (Use 0: never, 1: learn,
2: always)\n", blobmsg_get_u32(cur));
}
+ if ((cur = tb[DEV_ATTR_MULTICAST_FAST_LEAVE])) {
+ s->multicast_fast_leave = blobmsg_get_bool(cur);
+ s->flags |= DEV_OPT_MULTICAST_FAST_LEAVE;
+ }
+
if ((cur = tb[DEV_ATTR_MULTICAST])) {
s->multicast = blobmsg_get_bool(cur);
s->flags |= DEV_OPT_MULTICAST;
@@ -994,6 +1001,8 @@ device_dump_status(struct blob_buf *b, struct device *dev)
blobmsg_add_u8(b, "multicast_to_unicast",
st.multicast_to_unicast);
if (st.flags & DEV_OPT_MULTICAST_ROUTER)
blobmsg_add_u32(b, "multicast_router",
st.multicast_router);
+ if (st.flags & DEV_OPT_MULTICAST_FAST_LEAVE)
+ blobmsg_add_u8(b, "multicast_fast_leave",
st.multicast_fast_leave);
if (st.flags & DEV_OPT_MULTICAST)
blobmsg_add_u8(b, "multicast", st.multicast);
if (st.flags & DEV_OPT_LEARNING)
diff --git a/device.h b/device.h
index e13e435..032a8e9 100644
--- a/device.h
+++ b/device.h
@@ -44,6 +44,7 @@ enum {
DEV_ATTR_DADTRANSMITS,
DEV_ATTR_MULTICAST_TO_UNICAST,
DEV_ATTR_MULTICAST_ROUTER,
+ DEV_ATTR_MULTICAST_FAST_LEAVE,
DEV_ATTR_MULTICAST,
DEV_ATTR_LEARNING,
DEV_ATTR_UNICAST_FLOOD,
@@ -94,6 +95,7 @@ enum {
DEV_OPT_LEARNING= (1 << 17),
DEV_OPT_UNICAST_FLOOD = (1 << 18),
DEV_OPT_NEIGHGCSTALETIME= (1 << 19),
+ DEV_OPT_MULTICAST_FAST_LEAVE= (1 << 20),
};
/* events broadcasted to all users of a device */
@@ -156,6 +158,7 @@ struct device_settings {
unsigned int dadtransmits;
bool multicast_to_unicast;
unsigned int multicast_router;
+ bool multicast_fast_leave;
bool multicast;
bool learning;
bool unicast_flood;
diff --git a/system-linux.c b/system-linux.c
index d868c15..6e4a194 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -326,6 +326,11 @@ static void system_bridge_set_multicast_to_unicast(struct
device *dev, const cha
system_set_dev_sysctl("/sys/class/net/%s/brport/multicast_to_unicast",
dev->ifname, val);
}
+static void system_bridge_set_multicast_fast_leave(struct device *dev, const
char *val)
+{
+ system_set_dev_sysctl("/sys/class/net/%s/brport/multicast_fast_leave",
dev->ifname, val);
+}
+
static void system_bridge_set_hairpin_mode(struct device *dev, const char *val)
{
system_set_dev_sysctl("/sys/class/net/%s/brport/hairpin_mode",
dev->ifname, val);
@@ -680,6 +685,10 @@ int system_bridge_addif(struct device *bridge, struct
devic
[LEDE-DEV] [PATCH netifd 3/3] interface-event: Don't dequeue hotplug event in case of interface reload event
Dropping hotplug event in case of interface reload results into hotplug scripts not being being run for the interface and thus external actors not being informed about the actual state of the interface. This is clearly visible if the interface auto parameter is set to disabled for multiple interfaces resulting into no hotplug down event for all interfaces. Therefore don't flush the interface hotplug queue in case an interface reload event is observed. Signed-off-by: Hans Dedecker --- interface-event.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/interface-event.c b/interface-event.c index 93da22b..4976c2c 100644 --- a/interface-event.c +++ b/interface-event.c @@ -196,9 +196,10 @@ static void interface_event_cb(struct interface_user *dep, struct interface *ifa interface_queue_event(iface, ev); break; case IFEV_FREE: - case IFEV_RELOAD: interface_dequeue_event(iface); break; + default: + break; } } -- 1.9.1 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Looking for beta testers for new package: slide-switch
> I'd like to make sure the package works on a few more devices before > submitting to the official package feed. So if you have a device with > a slide switch, I'd really appreciate it if you can install the > package and let me know if it works (or doesn't work) for you, either > on this thread or on GitHub. Works like a charm on the TL-WR810N. Jens ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] uci: decrement package's section counter when free'ing sections
The counter is incremented during section allocation, but never decremented. Signed-off-by: Reiner Herrmann --- list.c | 1 + 1 file changed, 1 insertion(+) diff --git a/list.c b/list.c index 321861c..a2be150 100644 --- a/list.c +++ b/list.c @@ -213,6 +213,7 @@ uci_free_section(struct uci_section *s) if ((s->type != uci_dataptr(s)) && (s->type != NULL)) free(s->type); + s->package->n_section--; uci_free_element(&s->e); } -- 2.1.4 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] A Wiki for LEDE Documentation
> We got no answer from LEDE devs apart from jow saying he had some space > on the server and asking what wiki people prefers, but that discussion > died up quickly. > I'd personally prefer your "jump the gun" approach where someone starts > the wiki unofficially and all those that want to contribute do it there > before we get old waiting. I would definetely wait for Jow to answer on this subject. AFAIK he is quite busy these days. A LEDE wiki should be part of the LEDE infrastructure, with proper control and multiple admins, in order to avoid situations like at the beginning of this year. Give Jow a little time to respond. Thomas ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] gen_initramfs_list.sh escaping problem or stale dependency file?
On 09/13/2016 12:24 AM, Michal Marek wrote:
> On Mon, Sep 12, 2016 at 05:12:15PM -0700, Florian Fainelli wrote:
>> Hi,
>>
>> I have a root filesystem embedding filenames that look like these:
>>
>> /lib/data/:
>>
>> these are essentially files that can be matched against an USB
>> vendor/product id in an easy way.
>>
>> Now, the fun part is that this is only a problem when doing the
>> following (using OpenWrt/LEDE as a build system):
>>
>> 1:
>> - set CONFIG_INITRAMFS_SOURCE=""
>> - build kernel modules
>> - build my user-space tools
>> - build the kernel image
>> - reconfigure the kernel to now use an initramfs
>> - build the kernel w/ initramfs
>>
>> and then back to step 1 with the kernel build, would I hit this error:
>>
>> usr/Makefile:64: *** multiple target patterns. Stop.
> [...]
>> Which sorts of make sense here because the file name contains a ":"
>> which is not escaped, so GNU Make tries to interpret it.
>>
>> Now the part that does not quite make sense to me is why this file is
>> even relevant here considering that the first thing we do is set
>> CONFIG_INITRAMFS_SOURCE="" to disable the initramfs basically.
>
> It is possible that we read usr/Makefile twice for some reason. But the
> real problem is the lack of escaping. Can you try the following
> (untested) patch?
This patch works for me:
Tested-by: Florian Fainelli
Kind of surprising that this has not showed up before, but maybe people
don't really go through the same steps while re-configuring/re-building
their kernels
Thanks Michal!
>
>
> diff --git a/scripts/gen_initramfs_list.sh b/scripts/gen_initramfs_list.sh
> index 17fa901418ae..5d3188e74101 100755
> --- a/scripts/gen_initramfs_list.sh
> +++ b/scripts/gen_initramfs_list.sh
> @@ -97,7 +97,10 @@ print_mtime() {
> }
>
> list_parse() {
> - [ ! -L "$1" ] && echo "$1 \\" || :
> + if [ -L "$1" ]; then
> + return
> + fi
> + echo "$1" | sed 's/\([:%]\)/\\\1/g; s/$/ \\/'
> }
>
> # for each file print a line in following format
>
> Thanks,
> Michal
>
--
Florian
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] A Wiki for LEDE Documentation
On 09/13/2016 06:50 PM, Thomas Endt wrote: >> We got no answer from LEDE devs apart from jow saying he had some space >> on the server and asking what wiki people prefers, but that discussion >> died up quickly. >> I'd personally prefer your "jump the gun" approach where someone starts >> the wiki unofficially and all those that want to contribute do it there >> before we get old waiting. > I would definetely wait for Jow to answer on this subject. AFAIK he is quite > busy these days. > A LEDE wiki should be part of the LEDE infrastructure, with proper control > and multiple admins, in order to avoid situations like at the beginning of > this year. > > Give Jow a little time to respond. > > Thomas Was just voicing some impatience... I've been waiting for proper infrastructure from OpenWRT for far longer than a few months lol. -Alberto ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 0/2] update QCA988X ath10k-firmware to the latest version
According to Kalle Valo (on the OpenWrt mailing list, see [0]) only firmware binaries from his repository are tested by QCA's internal QA team. Additionally he pointed out that the version used in LEDE so far is from September 2015, despite having a newer version number than the current "stable" version (10.2.4.70.54). This updates the firmware for the QCA988X chips to the latest version available in his repository (meaning the latest stable version). As a side-note: this should (theoretically) add 802.11s (mesh) support to the firmware. However, at least for some OpenWrt users this does not work out-of-the-box. I have tested this for a few minutes, but maybe we can let this live in Felix' tree for a few days to get test results from other people as well. [0] https://lists.openwrt.org/pipermail/openwrt-devel/2016-September/042162.html Martin Blumenstingl (2): ath10k-firmware: update the qca988x firmware to 10.2.4.70.54 ath10k-firmware: bump the PKG_VERSION package/firmware/ath10k-firmware/Makefile | 16 1 file changed, 4 insertions(+), 12 deletions(-) -- 2.9.3 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 1/2] ath10k-firmware: update the qca988x firmware to 10.2.4.70.54
Use firmware version 10.2.4.70.54 from kvalo's git repository. The old version (even though it's version number is greater) is an old version from September 2015. Using only the firmware versions from kvalo's git repo is recommended, because those are tested by QCA's internal QCA. The QCA988X directory received a small reorganization as a "hw2.0" subdirectory was added - this patch also takes care of that as board.bin was moved to that subdirectory. Signed-off-by: Martin Blumenstingl --- package/firmware/ath10k-firmware/Makefile | 14 +++--- 1 file changed, 3 insertions(+), 11 deletions(-) diff --git a/package/firmware/ath10k-firmware/Makefile b/package/firmware/ath10k-firmware/Makefile index 624da6a..8535fe5 100644 --- a/package/firmware/ath10k-firmware/Makefile +++ b/package/firmware/ath10k-firmware/Makefile @@ -8,7 +8,7 @@ include $(TOPDIR)/rules.mk PKG_NAME:=ath10k-firmware -PKG_SOURCE_VERSION:=b00eb8d30fbebb6a5047ccacefa8c37e072fca9c +PKG_SOURCE_VERSION:=307cb46b06661ebd3186723b5002de769c7add83 PKG_VERSION:=2014-11-13-$(PKG_SOURCE_VERSION) PKG_RELEASE:=1 @@ -66,18 +66,10 @@ $(Package/ath10k-firmware-default) TITLE:=ath10k firmware for QCA988x devices endef -QCA988X_FIRMWARE_FILE:=firmware-5.bin_10.2.4.97-1 QCA988X_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-16.1.bin-lede QCA99X0_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-7.bin-lede.004 QCA9984_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-7.bin-lede.004 -define Download/ath10k-firmware-qca988x - URL:=https://www.codeaurora.org/cgit/quic/qsdk/oss/firmware/ath10k-firmware/plain/10.2.4/ - FILE:=$(QCA988X_FIRMWARE_FILE) - MD5SUM:=fcb2fbd42d73a63fbf603505c718cbde -endef -$(eval $(call Download,ath10k-firmware-qca988x)) - define Download/ath10k-firmware-qca988x-ct URL:=https://www.candelatech.com/downloads/ FILE:=$(QCA988X_FIRMWARE_FILE_CT) @@ -188,10 +180,10 @@ endef define Package/ath10k-firmware-qca988x/install $(INSTALL_DIR) $(1)/lib/firmware/ath10k/QCA988X/hw2.0 $(INSTALL_DATA) \ - $(PKG_BUILD_DIR)/QCA988X/board.bin \ + $(PKG_BUILD_DIR)/QCA988X/hw2.0/board.bin \ $(1)/lib/firmware/ath10k/QCA988X/hw2.0/ $(INSTALL_DATA) \ - $(DL_DIR)/$(QCA988X_FIRMWARE_FILE) \ + $(PKG_BUILD_DIR)/QCA988X/hw2.0/10.2.4.70/firmware-5.bin_10.2.4.70.54 \ $(1)/lib/firmware/ath10k/QCA988X/hw2.0/firmware-5.bin endef -- 2.9.3 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 2/2] ath10k-firmware: bump the PKG_VERSION
Update the PKG_VERSION to indicate that this package now contains newer firmware binaries (as all firmware versions were updated since 2014). Signed-off-by: Martin Blumenstingl --- package/firmware/ath10k-firmware/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/firmware/ath10k-firmware/Makefile b/package/firmware/ath10k-firmware/Makefile index 8535fe5..6b6944c 100644 --- a/package/firmware/ath10k-firmware/Makefile +++ b/package/firmware/ath10k-firmware/Makefile @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk PKG_NAME:=ath10k-firmware PKG_SOURCE_VERSION:=307cb46b06661ebd3186723b5002de769c7add83 -PKG_VERSION:=2014-11-13-$(PKG_SOURCE_VERSION) +PKG_VERSION:=2016-09-13-$(PKG_SOURCE_VERSION) PKG_RELEASE:=1 PKG_SOURCE_PROTO:=git -- 2.9.3 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] uci: decrement package's section counter when free'ing sections
On 2016-09-13 16:25, Reiner Herrmann wrote: > The counter is incremented during section allocation, but never > decremented. > > Signed-off-by: Reiner Herrmann > --- > list.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/list.c b/list.c > index 321861c..a2be150 100644 > --- a/list.c > +++ b/list.c > @@ -213,6 +213,7 @@ uci_free_section(struct uci_section *s) > if ((s->type != uci_dataptr(s)) && > (s->type != NULL)) > free(s->type); > + s->package->n_section--; NACK. n_section is used for hashing only, decrementing it here probably makes collisions for anonymous sections more likely. - Felix ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 0/2] update QCA988X ath10k-firmware to the latest version
On 2016-09-13 21:08, Martin Blumenstingl wrote: > According to Kalle Valo (on the OpenWrt mailing list, see [0]) only > firmware binaries from his repository are tested by QCA's internal QA > team. > > Additionally he pointed out that the version used in LEDE so far is > from September 2015, despite having a newer version number than the > current "stable" version (10.2.4.70.54). > > This updates the firmware for the QCA988X chips to the latest version > available in his repository (meaning the latest stable version). > > As a side-note: this should (theoretically) add 802.11s (mesh) > support to the firmware. However, at least for some OpenWrt users this > does not work out-of-the-box. > > I have tested this for a few minutes, but maybe we can let this live in > Felix' tree for a few days to get test results from other people as > well. Added to my staging tree. I squashed the PKG_VERSION bump into the first commit. - Felix ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] A Wiki for LEDE Documentation
Hi, > I would definetely wait for Jow to answer on this subject. AFAIK he is quite > busy these days. > A LEDE wiki should be part of the LEDE infrastructure, with proper control > and multiple admins, in order to avoid situations like at the beginning of > this year. > > Give Jow a little time to respond. All admins can have ssh root access. I put the dokuwiki inside a LXC Container. with global v6 and forwarded v4. We can transfare the container easily to another infra. cheers Tarek signature.asc Description: OpenPGP digital signature ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] OpenWrt Summit Session Announcements
All, I wanted to let everyone know that the sessions for OpenWrt Summit have been announced and are listed at http://openwrtsummit.org. We have a really broad range of sessions this year that address both the technical and industry sides of the OpenWrt/LEDE communities. I think I can speak for the rest of the summit committee-members when I say that we're very excited by our list of sessions. This will be great chance to meet in person with others who are using or involved with OpenWrt or LEDE. I encourage everyone to check out the session list and consider joining us in Berlin on October 13. It's free to attend, we only ask that you register ahead of time at http://openwrtsummit.org. I look forward to seeing everyone there! Eric Schultz, Chair, on behalf of the OpenWrt Summit Committee: Abhijit Mahajani Beda Kosata Eric Schultz Federico Capoano Hans Dedecker Hauke Mehrtens Imre Kaloz Kathy Giori Luka Perkov Paul Blay Zoltan Herpai -- Eric Schultz, Community Manager, prpl Foundation http://www.prplfoundation.org eschu...@prplfoundation.org cell: 920-539-0404 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] A Wiki for LEDE Documentation
Hi, it is great to see that there is some movement in the wiki discussion :) My personal view (and I suppose that of some other LEDE people too) is that the decision on what wiki software to use, on how to organize submissions and on how to structure it is at the sole discretion of the people willing to do the actual work. Past efforts with the OpenWrt wiki (mainly thinking about the Moinmoin to Dokuwiki migration) have shown that it makes no sense to impose any kind of restrictions without the gardeners consent. I strongly support any effort to get a wiki up and running but I think it is best if the "how" and "when" is decided by the future gardener and user community. >From what I can see the next steps to get an actual wiki up and running would be: - Assemble a team of volunteers to maintain the wiki - Among those volunteers who want to work on the wiki, decide on a software / markup flavor - Setup the chosen wiki software - we can use LEDE's donated Digital Ocean resources to setup production and test instances - Start building/migrating content Once a consensus has been reached we can start to look into whatever is needed to setup and host the decided wiki software. Personally I won't be able to invest too much time into the actual content gardening but I would be more then happy to assist with hosting matters. Cheers, Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] uci: decrement package's section counter when free'ing sections
On Tue, Sep 13, 2016 at 10:52:43PM +0200, Felix Fietkau wrote:
> On 2016-09-13 16:25, Reiner Herrmann wrote:
> > The counter is incremented during section allocation, but never
> > decremented.
> NACK. n_section is used for hashing only, decrementing it here probably
> makes collisions for anonymous sections more likely.
I was encountering a strange behaviour related to adding/deleting
sections, like in the example below.
There I'm adding two sections, deleting one, commiting, deleting the
other, and commiting again.
I would expect that afterwards the package is empty and there is no
diff in the save dir.
But it is the case:
$ uci -c /tmp/uci -X show
foo.cfg0260ba=bar
$ cat /tmp/.uci/foo
-foo.cfg0460ba
In a slightly more complex example the patch (decrementing the counter)
seemed to help. Though with the minimal example from below, the issue
also still exists...
#include
#include
int main()
{
struct uci_ptr ptr;
struct uci_context *ctx = uci_alloc_context();
struct uci_section *section;
uci_set_confdir(ctx, "/tmp/uci");
uci_lookup_ptr(ctx, &ptr, "foo", 0);
/* Add two sections */
uci_add_section(ctx, ptr.p, "bar", §ion);
uci_add_section(ctx, ptr.p, "bar", §ion);
/* Delete one section */
uci_lookup_ptr(ctx, &ptr, strdup("foo.@bar[0]"), 1);
uci_delete(ctx, &ptr);
uci_save(ctx, ptr.p);
uci_commit(ctx, &ptr.p, 1);
/* Delete other section */
uci_lookup_ptr(ctx, &ptr, strdup("foo.@bar[0]"), 1);
uci_delete(ctx, &ptr);
uci_save(ctx, ptr.p);
uci_commit(ctx, &ptr.p, 1);
return 0;
}
signature.asc
Description: Digital signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] A Wiki for LEDE Documentation
Hi Alberto, don't hold back yourself waiting for a response from "the LEDE devs" - those who care about a wiki will likely endorse whatever good solution is proposed and the rest either has no opinion or time to participate in the decision making processes :) Part of the reason that there is no wiki yet is the fact that there is a lack of manpower to start one, so any extra effort spent here is more than welcome! Please don't treat the general silence regarding the wiki topic as a sign of rejection - I think all people here would be more than happy to have a proper solution, it just needs someone taking the lead to get all required things organized. Cheers, Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Documentation for router support means the famous Table of Hardware
Hi Tarek, Thomas Endt and others invested a lot of time to implement a structured table of hardware in the OpenWrt wiki, which means that a lot of detail information is accessible in a SQLite3 database file which should make it easy to generate hardware documentation pages with a little script and a few self-join queries. I also think that such a model would be a viable option for the future: have a structured data entry dialog in the wiki which fills a database, have all the surrounding wiki capabilities for free text information and use the resulting database backend data to provide other, non-wiki services like a vendor/model search to to download link redirection. Imho a well maintained hardware database is a very important topic for LEDE, OpenWrt and other associated projects but we need to find a sane middle ground that does not upset too many potential contributors but still yields a reasonable data quality... On a related note I wonder if anyone ever thought about joining forces with WikiDevi? It seems like a perfectly reasonable thing to do but I recall that the site operators are rather hard to contact. Just my two cents :) Regards, Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [RFC 7/7] ramips: set blocksize for dch-m225/dir-860l-b1
> Signed-off-by: Mathias Kresin > --- > target/linux/ramips/image/mt7620.mk | 6 -- > target/linux/ramips/image/mt7621.mk | 6 -- > 2 files changed, 8 insertions(+), 4 deletions(-) > > diff --git a/target/linux/ramips/image/mt7620.mk > b/target/linux/ramips/image/mt7620.mk > index 00dd4f2..1df806b 100644 > --- a/target/linux/ramips/image/mt7620.mk > +++ b/target/linux/ramips/image/mt7620.mk > @@ -422,14 +422,16 @@ TARGET_DEVICES += tiny-ac > dch_m225_mtd_size=7012352 > define Device/dch-m225 >DTS := DCH-M225 > + BLOCKSIZE := 4k >IMAGES += factory.bin >IMAGE_SIZE := $(dch_m225_mtd_size) >IMAGE/sysupgrade.bin := \ > - append-kernel | pad-offset 65536 64 | append-rootfs | \ > + append-kernel | pad-offset (BLOCKSIZE) 64 | append-rootfs | \ > seama -m "dev=/dev/mtdblock/2" -m "type=firmware" | \ > pad-rootfs | check-size (IMAGE_SIZE) >IMAGE/factory.bin := \ > - append-kernel | pad-offset 65536 64 | append-rootfs | pad-rootfs -x 64 > | \ > + append-kernel | pad-offset (BLOCKSIZE) 64 | \ > + append-rootfs | pad-rootfs -x 64 | \ > seama -m "dev=/dev/mtdblock/2" -m "type=firmware" | \ > seama-seal -m "signature=wapn22_dlink.2013gui_dap1320b" | \ > check-size (IMAGE_SIZE) > diff --git a/target/linux/ramips/image/mt7621.mk > b/target/linux/ramips/image/mt7621.mk > index e602dfb..acc17c3 100644 > --- a/target/linux/ramips/image/mt7621.mk > +++ b/target/linux/ramips/image/mt7621.mk > @@ -65,15 +65,17 @@ TARGET_DEVICES += wsr-1166 > > define Device/dir-860l-b1 >DTS := DIR-860L-B1 > + BLOCKSIZE := 4k >IMAGES += factory.bin >KERNEL := kernel-bin | patch-dtb | relocate-kernel | lzma | uImage lzma >IMAGE_SIZE := $(ralink_default_fw_size_16M) >IMAGE/sysupgrade.bin := \ > - append-kernel | pad-offset 65536 64 | append-rootfs | \ > + append-kernel | pad-offset (BLOCKSIZE) 64 | append-rootfs | \ > seama -m "dev=/dev/mtdblock/2" -m "type=firmware" | \ > pad-rootfs | check-size (IMAGE_SIZE) >IMAGE/factory.bin := \ > - append-kernel | pad-offset 65536 64 | append-rootfs | pad-rootfs -x 64 > | \ > + append-kernel | pad-offset (BLOCKSIZE) 64 | \ > + append-rootfs | pad-rootfs -x 64 | \ > seama -m "dev=/dev/mtdblock/2" -m "type=firmware" | \ > seama-seal -m "signature=wrgac13_dlink.2013gui_dir860lb" | \ > check-size (IMAGE_SIZE) > -- > 2.7.4 This patch broke dir-860l-b1. Changing BLOCKSIZE for dir-860l-b1 to 64k makes it work again. -- Russell Senior, President russ...@personaltelco.net ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 0/2] update QCA988X ath10k-firmware to the latest version
I had just completed a very large set of tests comparing the now-shown-to-be-old firmware and the candelatech firmware, I'll get to this newer stuff sometime in the next month or so I did not observe much performance differences between the obsolete firmware and the candelatech stuff on normal tests (haven't looked at them in huge detail yet, either) - the huge advantage to the candelatech firmware was working adhoc support. Although that works (which is a huge advantage over not working at all!), it only did 80Mbits on a vht40 test where I was getting 300 in sta/ap mode. Is adhoc in the new qca firmware? ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [RFC 7/7] ramips: set blocksize for dch-m225/dir-860l-b1
14.09.2016 02:02, Russell Senior: diff --git a/target/linux/ramips/image/mt7621.mk b/target/linux/ramips/image/mt7621.mk index e602dfb..acc17c3 100644 --- a/target/linux/ramips/image/mt7621.mk +++ b/target/linux/ramips/image/mt7621.mk @@ -65,15 +65,17 @@ TARGET_DEVICES += wsr-1166 define Device/dir-860l-b1 DTS := DIR-860L-B1 + BLOCKSIZE := 4k IMAGES += factory.bin KERNEL := kernel-bin | patch-dtb | relocate-kernel | lzma | uImage lzma IMAGE_SIZE := $(ralink_default_fw_size_16M) IMAGE/sysupgrade.bin := \ - append-kernel | pad-offset 65536 64 | append-rootfs | \ + append-kernel | pad-offset (BLOCKSIZE) 64 | append-rootfs | \ seama -m "dev=/dev/mtdblock/2" -m "type=firmware" | \ pad-rootfs | check-size (IMAGE_SIZE) IMAGE/factory.bin := \ - append-kernel | pad-offset 65536 64 | append-rootfs | pad-rootfs -x 64 | \ + append-kernel | pad-offset (BLOCKSIZE) 64 | \ + append-rootfs | pad-rootfs -x 64 | \ seama -m "dev=/dev/mtdblock/2" -m "type=firmware" | \ seama-seal -m "signature=wrgac13_dlink.2013gui_dir860lb" | \ check-size (IMAGE_SIZE) -- 2.7.4 This patch broke dir-860l-b1. Changing BLOCKSIZE for dir-860l-b1 to 64k makes it work again. Thanks for the report. To my knowledge the D-Link DIR-860L rev B1 has a MX25L12805D flash chip which supports 4K sector size. But I've missed to include the required kernel config changes. This was fixed with 925e63e71fa6691f3fa374f71c77d0a91c7e7539. Would you please make sure that this commit is in your tree. Please provide a full bootlog and the output of 'cat /proc/mtd' from an image which has the blocksize reverted to 64k. Might be possible that it's related to the seama header. I've checked the seama mtd splitter code before committing the change but might have missed something. Mathias ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
