Re: [OpenWrt-Devel] [PATCH] generic: add linux 4.1-rc1 support
On 05/01/2015 10:59 AM, Dirk Neukirchen wrote: On 28.04.2015 23:08, Álvaro Fernández Rojas wrote: Boot tested: http://pastebin.com/L6aAb9xj Signed-off-by: Álvaro Fernández Rojas nolt...@gmail.com Great work ! 2. any(?) mac80211 does not built Error: include/net/cfg80211.h:3249:25: error: 'struct wiphy' has no member named '_net' return read_pnet(wiphy-_net); I did try to use the v4.1-rc1 Backports package as drop-in (only some OpenWrt specific driver series patches were not applied) since it should deal with that error, ( but I get compile errors with that too: include/net/cfg80211.h:3253:2: error: implicit declaration of function 'possible_write_pnet' include/net/cfg80211.h:3248:2: error: implicit declaration of function 'possible_read_pnet' (introduced by https://git.kernel.org/cgit/linux/kernel/git/backports/backports.git/tree/patches/collateral-evolutions/network/0053-possible_net_t.patch ) Could you send me your patch which made mac80211 work with kernel 4.1? I got 4.1 booting on my bcm53xx device and want to test something with wifi. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ddns default config values broken?
Well i just quickly looked at the sources on github. It looked like the verbosity level was also used to change the retry-behaviour of the script. As a programmer i would expect a debug or verbosity level to impact the amount of printfs and nothing more. Thanks for accepting the suggestion to default-set the retry_count to infinite, as far as i understood you experienced problems with a limited number of retries as well. Henning On Sun, 10 May 2015 20:44:31 +0200 Christian Schoenebeck christian.schoeneb...@gmail.com wrote: One Shot in verbose mode is for diagnostic on console only. To configure One Shot if starting via init.d script i.e. using cron you should set force_interval to 0. This will retry (retry_count) until one successful update. If looking into sources do it on Github or the source tree because during building all comments are removed. Thanks for feedback. Christian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Remove requirement of an absolute path to the perl interpreter
On 05/10/2015 09:02 PM, Felix Fietkau wrote: On 2015-05-10 20:49, Thomas Strobel wrote: On 05/10/2015 02:48 PM, Felix Fietkau wrote: On 2015-05-10 14:16, Thomas Strobel wrote: diff --git a/include/feeds.mk b/include/feeds.mk index 695b03b..27f3e8f 100644 --- a/include/feeds.mk +++ b/include/feeds.mk @@ -7,7 +7,7 @@ -include $(TMP_DIR)/.packagefeeds -FEEDS_AVAILABLE:=$(shell $(SCRIPT_DIR)/feeds list -n) +FEEDS_AVAILABLE:=$(perl $(SCRIPT_DIR)/feeds list -n) I think this is the wrong place to make the change. Why not change scripts/feeds to replace the #! line with: #!/usr/bin/env perl - Felix Thanks for the review. Unfortunately, /usr/bin/env does not exist either. In NixOS there is no /usr, no /sbin, and only a /bin/sh - /nix/store/nixos_installation_specific_hash/bash. The absolute path to, e.g., perl or env is different for each installation of NixOS, so it can't be hard-coded into the build script. That's why I thought of calling perl directly from the PATH environment. Then I think we should hold off on applying changes like the one you proposed until we have a proper plan for dealing with the rest. It needs to be possible to call ./scripts/feeds and similar scripts directly. How do other perl scripts on NixOS deal with that sort of stuff? - Felix The way how NixOS deals with absolute path names in scripts is to patch every script. If software is packed for NixOS, then scripts are automatically or manually patched to execute under NixOS. For software that is not packed but only executed in NixOS, the scripts have to be adapted manually. Ugh, that sounds really nasty. Well, there's a price to pay for having a purely functional, declarative distribution with atomic upgrades and rollbacks ;). It's amazing when using the package manager of NixOS for software development, as you can, e.g., define a separate working environment for each project, especially as the environments are much more lightweight than Docker or LXC or all that. Have a look, the package manager is not restricted to NixOS but is also available for other Linux distributions and for OSX! As OpenWRT is just executed, the scripts have to be adapted manually for each new version or checkout of OpenWRT. The only reasonable way I can think of so far to fix the scripts in OpenWRT is at the calling side, like suggested in my patch. However, there are only 3-4 places that need changing in the build system and in a standard set of packages. So it wouldn't need too much tweaking on the OpenWRT side. Given that the approach is incomplete (and quite inconvenient for regular use), and any better fix will not need these changes at all, I still object to adding them. The way I see it, the issue of missing /usr/bin/env is going to come up frequently with package-internal builds as well. NixOS users should probably just create a symlink or wrapper script at /usr/bin/env, and we should make sure that all important places in OpenWrt use it. I really don't want to start adding more and more patches afterwards to deal with the quirky non-standard behavior of NixOS. Changing the scripts in OpenWRT to use /usr/bin/env sounds like a pragmatic choice that would already make life easier under NixOS. In addition to changing the scripts, what do you think about referring to $(STAGING_DIR)/host/bin only for calling host binaries from OpenWRT scripts? That is, for calling perl, the change would be: -FEEDS_AVAILABLE:=$(shell $(SCRIPT_DIR)/feeds list -n) +FEEDS_AVAILABLE:=$($(STAGING_DIR)/host/bin/perl $(SCRIPT_DIR)/feeds list -n) I know that this is very similar to what I proposed before, but it would have the benefit that there is a clear interface through which OpenWRT accesses any host binaries. Package-internal builds could be restricted to only access the host environment through $(STAGING_DIR)/host/bin as well, maybe helping to execute correctly once all requirements in $(STAGING_DIR)/host/bin are filled. - Thomas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 3/3] [rpcd] file: be consistent with string termination character
Signed-off-by: Luka Perkov l...@openwrt.org --- file.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/file.c b/file.c index 86783e0..4c00ae2 100644 --- a/file.c +++ b/file.c @@ -253,7 +253,7 @@ rpc_file_read(struct ubus_context *ctx, struct ubus_object *obj, free(data); } - *(wbuf + len) = 0; + *(wbuf + len) = '\0'; blobmsg_add_string_buffer(buf); ubus_send_reply(ctx, req, buf.head); -- 2.4.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Remove requirement of an absolute path to the perl interpreter
On 2015-05-11 01:12, Thomas Strobel wrote: Changing the scripts in OpenWRT to use /usr/bin/env sounds like a pragmatic choice that would already make life easier under NixOS. In addition to changing the scripts, what do you think about referring to $(STAGING_DIR)/host/bin only for calling host binaries from OpenWRT scripts? That is, for calling perl, the change would be: -FEEDS_AVAILABLE:=$(shell $(SCRIPT_DIR)/feeds list -n) +FEEDS_AVAILABLE:=$($(STAGING_DIR)/host/bin/perl $(SCRIPT_DIR)/feeds list -n) I know that this is very similar to what I proposed before, but it would have the benefit that there is a clear interface through which OpenWRT accesses any host binaries. I think if $(SCRIPT_DIR)/feeds is changed in a way that it can be called directly, the above change becomes completely pointless, as it only adds redundant information about what format $(SCRIPT_DIR)/feeds is supposed to be. So NACK from me on this one. Package-internal builds could be restricted to only access the host environment through $(STAGING_DIR)/host/bin as well, maybe helping to execute correctly once all requirements in $(STAGING_DIR)/host/bin are filled. Right now we rely on many things outside of the staging dir - basic utilties, toolchain, etc. I don't see that changing any time soon. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/3] [rpcd][v2] file: add support for base64
Signed-off-by: Luka Perkov l...@openwrt.org
---
= changes in v2:
Use new libubox base64 provided API.
file.c | 118 +++--
1 file changed, 107 insertions(+), 11 deletions(-)
diff --git a/file.c b/file.c
index 9c1b301..c3671bb 100644
--- a/file.c
+++ b/file.c
@@ -29,6 +29,7 @@
#include libubox/blobmsg.h
#include libubox/md5.h
#include libubox/ustream.h
+#include libubox/utils.h
#include rpcd/plugin.h
@@ -79,14 +80,27 @@ static const struct blobmsg_policy
rpc_file_r_policy[__RPC_F_R_MAX] = {
};
enum {
+ RPC_F_RB_PATH,
+ RPC_F_RB_BASE64,
+ __RPC_F_RB_MAX,
+};
+
+static const struct blobmsg_policy rpc_file_rb_policy[__RPC_F_RB_MAX] = {
+ [RPC_F_RB_PATH] = { .name = path, .type = BLOBMSG_TYPE_STRING },
+ [RPC_F_RB_BASE64] = { .name = base64, .type = BLOBMSG_TYPE_BOOL },
+};
+
+enum {
RPC_F_RW_PATH,
RPC_F_RW_DATA,
+ RPC_F_RW_BASE64,
__RPC_F_RW_MAX,
};
static const struct blobmsg_policy rpc_file_rw_policy[__RPC_F_RW_MAX] = {
- [RPC_F_RW_PATH] = { .name = path, .type = BLOBMSG_TYPE_STRING },
- [RPC_F_RW_DATA] = { .name = data, .type = BLOBMSG_TYPE_STRING },
+ [RPC_F_RW_PATH] = { .name = path, .type = BLOBMSG_TYPE_STRING },
+ [RPC_F_RW_DATA] = { .name = data, .type = BLOBMSG_TYPE_STRING },
+ [RPC_F_RW_BASE64] = { .name = base64, .type = BLOBMSG_TYPE_BOOL },
};
enum {
@@ -162,12 +176,22 @@ rpc_file_read(struct ubus_context *ctx, struct
ubus_object *obj,
struct ubus_request_data *req, const char *method,
struct blob_attr *msg)
{
- int fd, rv, len;
+ static struct blob_attr *tb[__RPC_F_RB_MAX];
+ bool base64 = false;
+ int fd, rv;
+ ssize_t len;
char *path;
struct stat s;
char *wbuf;
- if (!rpc_check_path(msg, path, s))
+ blobmsg_parse(rpc_file_rb_policy, __RPC_F_RB_MAX, tb, blob_data(msg),
blob_len(msg));
+
+ if (!tb[RPC_F_RB_PATH])
+ return rpc_errno_status();
+
+ path = blobmsg_data(tb[RPC_F_RB_PATH]);
+
+ if (stat(path, s))
return rpc_errno_status();
if (s.st_size = RPC_FILE_MAX_SIZE)
@@ -182,7 +206,17 @@ rpc_file_read(struct ubus_context *ctx, struct ubus_object
*obj,
blob_buf_init(buf, 0);
- wbuf = blobmsg_alloc_string_buffer(buf, data, s.st_size + 1);
+ if (tb[RPC_F_RB_BASE64])
+ base64 = blobmsg_get_bool(tb[RPC_F_RB_BASE64]);
+
+ if (base64)
+ {
+ wbuf = blobmsg_alloc_string_buffer(buf, data,
B64_ENCODE_LEN(s.st_size));
+ }
+ else
+ {
+ wbuf = blobmsg_alloc_string_buffer(buf, data, s.st_size + 1);
+ }
if (!wbuf)
{
@@ -196,14 +230,35 @@ rpc_file_read(struct ubus_context *ctx, struct
ubus_object *obj,
goto out;
}
+ if (base64)
+ {
+ uint8_t *data = calloc(B64_ENCODE_LEN(len), sizeof(uint8_t));
+ if (!data)
+ {
+ rv = UBUS_STATUS_UNKNOWN_ERROR;
+ goto out;
+ }
+
+ len = b64_encode(wbuf, len, data, B64_ENCODE_LEN(len));
+ if (len 0)
+ {
+ free(data);
+ rv = UBUS_STATUS_UNKNOWN_ERROR;
+ goto out;
+ }
+
+ memcpy(wbuf, data, len);
+ free(data);
+ }
+
*(wbuf + len) = 0;
blobmsg_add_string_buffer(buf);
ubus_send_reply(ctx, req, buf.head);
- blob_buf_free(buf);
rv = UBUS_STATUS_OK;
out:
+ blob_buf_free(buf);
close(fd);
return rv;
}
@@ -213,8 +268,13 @@ rpc_file_write(struct ubus_context *ctx, struct
ubus_object *obj,
struct ubus_request_data *req, const char *method,
struct blob_attr *msg)
{
- int fd;
struct blob_attr *tb[__RPC_F_RW_MAX];
+ bool base64 = false;
+ int fd, rv = 0;
+ void *data = NULL;
+ size_t data_len = 0;
+ void *rbuf = NULL;
+ ssize_t rbuf_len = 0;
blobmsg_parse(rpc_file_rw_policy, __RPC_F_RW_MAX, tb,
blob_data(msg), blob_len(msg));
@@ -222,18 +282,54 @@ rpc_file_write(struct ubus_context *ctx, struct
ubus_object *obj,
if (!tb[RPC_F_RW_PATH] || !tb[RPC_F_RW_DATA])
return UBUS_STATUS_INVALID_ARGUMENT;
+ data = blobmsg_data(tb[RPC_F_RW_DATA]);
+ data_len = blobmsg_data_len(tb[RPC_F_RW_DATA]) - 1;
+
if ((fd = open(blobmsg_data(tb[RPC_F_RW_PATH]), O_CREAT | O_TRUNC |
O_WRONLY, 0666)) 0)
return rpc_errno_status();
- if (write(fd, blobmsg_data(tb[RPC_F_RW_DATA]),
blobmsg_data_len(tb[RPC_F_RW_DATA])) 0)
- return rpc_errno_status();
+ if (tb[RPC_F_RW_BASE64])
+ base64 =
Re: [OpenWrt-Devel] [PATCH] mtd: correct/change warning text about partition split / read-only status
On 2015-04-24 21:58, Hannu Nyman wrote: Since the kernel/rootfs split handling was modified 2 years ago by r37283 ( https://dev.openwrt.org/changeset/37283 ) and by the subsequent checkins, users have seen rather scary mtd errors in the log at every boot. The message ends -- forcing read-only, which looks a bit error-like. That error has been mentioned in some forum threads, when users have noticed this message instead of some actual error. [2.94] 0x0007-0x00ff : firmware [2.97] 2 netgear-fw partitions found on MTD device firmware [2.97] 0x0007-0x00188440 : kernel [2.98] mtd: partition kernel must either start or end on erase block boundary or be smaller than an erase block -- forcing read-only [2.99] 0x00188440-0x00ff : rootfs [2.99] mtd: partition rootfs must either start or end on erase block boundary or be smaller than an erase block -- forcing read-only [3.01] mtd: device 4 (rootfs) set to be root filesystem [3.01] 1 squashfs-split partitions found on MTD device rootfs [3.02] 0x0066-0x00ff : rootfs_data The error text 'mtd: partition kernel must either start or end on erase block boundary or be smaller than an erase block -- forcing read-only' originates from 6 years ago, when nbd checked in r17658 to kernel 2.6.30. https://dev.openwrt.org/changeset/17658 https://dev.openwrt.org/browser/trunk/target/linux/generic-2.6/patches-2.6.30/222-partial_eraseblock_write.patch?rev=17658 At that time, this message was rarely shown, as it was normal to have padding after kernel, so that rootfs started at the next block boundary. Currently many platforms have kernel rootfs tightly packed without padding in between, so the message is shown quite frequently. Additionally, I think that the original warning message has a logical fault: the first or should be and. It should say must either start AND end on erase block boundary or be smaller than an erase block. (otherwise 'kernel' should not cause the warning message as it starts at a boundary...). The logic in 411-mtd-partial_eraseblock_write.patch is pretty hard to follow, but that is my reading about the correct reasoning. https://dev.openwrt.org/browser/trunk/target/linux/generic/patches-3.18/411-mtd-partial_eraseblock_write.patch I propose that the message class is changed from a kernel warning to a kernel info message and the text is changed to be less scary: 'partition kernel is read-only: it does not start and end at erase block boundary and is larger than a single block' [2.97] 2 netgear-fw partitions found on MTD device firmware [2.97] 0x0007-0x00188440 : kernel [2.98] mtd: partition kernel is read-only: it does not start and end at erase block boundary and is larger than a single block [2.99] 0x00188440-0x00ff : rootfs [2.99] mtd: partition rootfs is read-only: it does not start and end at erase block boundary and is larger than a single block I would prefer to shorten the message even more, but I didn't invent a suitable short but informative wording. (Althoug as this is currently most often just an informative notice, I am not quite sure if the logic needs to be explained quite that closely in the message.) I think this message is quite pointless anyway, so I'd prefer to simply have it removed instead of changing 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] TP-LINK Archer C7 () JFFS2 only 5GHz fix
On 2015-05-08 23:04, Spencer Thomason wrote: If you select a JFFS2 only build for the TP-Link Archer C7 then the ath10k drivers blob doesn't load and the 5GHz band doesn't work at all. It looks like the partitions were hard-coded for sqashfs. This patch allows both squashfs and JFFS2 to work. Signed-off-by: Spencer Thomason sthoma...@cleanrouter.com mailto:sthoma...@cleanrouter.com Formatting of this patch is screwed up, probably because of HTML/plain text mixing. If you want to avoid such issues, I'd suggest setting up git-send-email. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC PATCH] ar71xx: Support Antminer S1/S3
On 2015-05-02 05:08, James Hilliard wrote: I did my best to separate this device out, below is my current patch, comments appreciated. I'm having trouble figuring out how to differentiate the hwid which seems to be the same as the tp-link wr743nd-v2. 0x07430002 Is the hardware ID that both seem to have, is there any other ID's that I may be able to use? There are a lot of seemingly bogus unrelated changes, especially the ones to the generic code. The patch is completely misformatted, so it won't ever apply. Many of the changes do not make sense, so please make an effort to reduce the patch to the smallest amount of change to support the platform. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH RFC] base-files: switch reset button support to hotplug.d
On 10 May 2015 at 13:14, Felix Fietkau n...@openwrt.org wrote: On 2015-05-09 22:33, Rafał Miłecki wrote: For years now we have procd (with its hotplug support) and action JSON executing all scripts in /etc/hotplug.d/SUBSYSTEM/. Move reset button support to handle it the same way we handle other subsystems. Signed-off-by: Rafał Miłecki zaj...@gmail.com That does not make any sense to me. Especially since we have other rc.button scripts still in place. I think we should leave the reset script where it is. My further plan was to move all buttons to the /etc/hotplug.d/. I was thinking hotplug.d is something more generic and should be preferred. After that we could leave support for /etc/rc.button/ for one or two more releases (to let user swtich to hotplug.d). Then finally get rid of it. -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Remove requirement of an absolute path to the perl interpreter
On 05/10/2015 01:12 PM, Felix Fietkau wrote: On 2015-05-09 16:50, Thomas Strobel wrote: Hi, I'm using OpenWRT on NixOS, a Linux operating system that uses a sophisticated hash mechanism instead of the Filesystem Hierarchy Standard. A consequence of the hashing mechanism is that files like, e.g., /usr/bin/perl don't exist under NixOS. I've tried to create a patch that replaces two occurrences where /usr/bin/perl would be needed with a more general calling scheme that shouldn't break OpenWRT on any other platform, but allows to build it on NixOS. Could you please comment on the changes suggested, e.g., if they break anything, and whether there is an interest in merging the patch upstream? Many thanks! Thomas diff --git a/include/feeds.mk b/include/feeds.mk index 695b03b..27f3e8f 100644 --- a/include/feeds.mk +++ b/include/feeds.mk @@ -7,7 +7,7 @@ -include $(TMP_DIR)/.packagefeeds -FEEDS_AVAILABLE:=$(shell $(SCRIPT_DIR)/feeds list -n) +FEEDS_AVAILABLE:=$(perl $(SCRIPT_DIR)/feeds list -n) I think this is the wrong place to make the change. Why not change scripts/feeds to replace the #! line with: #!/usr/bin/env perl - Felix Thanks for the review. Unfortunately, /usr/bin/env does not exist either. In NixOS there is no /usr, no /sbin, and only a /bin/sh - /nix/store/nixos_installation_specific_hash/bash. The absolute path to, e.g., perl or env is different for each installation of NixOS, so it can't be hard-coded into the build script. That's why I thought of calling perl directly from the PATH environment. Thomas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Remove requirement of an absolute path to the perl interpreter
On 2015-05-10 14:16, Thomas Strobel wrote: diff --git a/include/feeds.mk b/include/feeds.mk index 695b03b..27f3e8f 100644 --- a/include/feeds.mk +++ b/include/feeds.mk @@ -7,7 +7,7 @@ -include $(TMP_DIR)/.packagefeeds -FEEDS_AVAILABLE:=$(shell $(SCRIPT_DIR)/feeds list -n) +FEEDS_AVAILABLE:=$(perl $(SCRIPT_DIR)/feeds list -n) I think this is the wrong place to make the change. Why not change scripts/feeds to replace the #! line with: #!/usr/bin/env perl - Felix Thanks for the review. Unfortunately, /usr/bin/env does not exist either. In NixOS there is no /usr, no /sbin, and only a /bin/sh - /nix/store/nixos_installation_specific_hash/bash. The absolute path to, e.g., perl or env is different for each installation of NixOS, so it can't be hard-coded into the build script. That's why I thought of calling perl directly from the PATH environment. Then I think we should hold off on applying changes like the one you proposed until we have a proper plan for dealing with the rest. It needs to be possible to call ./scripts/feeds and similar scripts directly. How do other perl scripts on NixOS deal with that sort of stuff? - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Remove requirement of an absolute path to the perl interpreter
On 2015-05-09 16:50, Thomas Strobel wrote: Hi, I'm using OpenWRT on NixOS, a Linux operating system that uses a sophisticated hash mechanism instead of the Filesystem Hierarchy Standard. A consequence of the hashing mechanism is that files like, e.g., /usr/bin/perl don't exist under NixOS. I've tried to create a patch that replaces two occurrences where /usr/bin/perl would be needed with a more general calling scheme that shouldn't break OpenWRT on any other platform, but allows to build it on NixOS. Could you please comment on the changes suggested, e.g., if they break anything, and whether there is an interest in merging the patch upstream? Many thanks! Thomas diff --git a/include/feeds.mk b/include/feeds.mk index 695b03b..27f3e8f 100644 --- a/include/feeds.mk +++ b/include/feeds.mk @@ -7,7 +7,7 @@ -include $(TMP_DIR)/.packagefeeds -FEEDS_AVAILABLE:=$(shell $(SCRIPT_DIR)/feeds list -n) +FEEDS_AVAILABLE:=$(perl $(SCRIPT_DIR)/feeds list -n) I think this is the wrong place to make the change. Why not change scripts/feeds to replace the #! line with: #!/usr/bin/env perl - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH RFC] base-files: switch reset button support to hotplug.d
On 2015-05-09 22:33, Rafał Miłecki wrote: For years now we have procd (with its hotplug support) and action JSON executing all scripts in /etc/hotplug.d/SUBSYSTEM/. Move reset button support to handle it the same way we handle other subsystems. Signed-off-by: Rafał Miłecki zaj...@gmail.com That does not make any sense to me. Especially since we have other rc.button scripts still in place. I think we should leave the reset script where it is. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] lantiq: add platform_pre_upgrade for sysupgrade
As explained in recent sysupgrade/nand.sh commits, current NAND
sysupgrade is a bit misleading because of nand_do_platform_check
behavior. It leaves a special mark in /tmp/sysupgrade-nand-path
triggering some diffent code path in nand_upgrade_stage1.
The plan is to have the check function only check the image and nothing
else. Then platform code (platform_pre_upgrade) should trigger NAND
specific upgrade path. This is what this patch implements.
Please note that because of current nand_upgrade_stage1 implemntation
this patch doesn't change any behavior yet. It only prepares lantiq
target for changing nand_do_platform_check (it will be possible after
preparing all other targets as well).
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
target/linux/lantiq/base-files/lib/upgrade/platform.sh | 11 +++
1 file changed, 11 insertions(+)
diff --git a/target/linux/lantiq/base-files/lib/upgrade/platform.sh
b/target/linux/lantiq/base-files/lib/upgrade/platform.sh
index 1688d3a..a892805 100755
--- a/target/linux/lantiq/base-files/lib/upgrade/platform.sh
+++ b/target/linux/lantiq/base-files/lib/upgrade/platform.sh
@@ -25,6 +25,17 @@ platform_check_image() {
esac
}
+platform_pre_upgrade() {
+ local board=$(lantiq_board_name)
+
+ case $board in
+ BTHOMEHUBV2B|BTHOMEHUBV3A|P2812HNUF* )
+ nand_do_upgrade $1
+ ;;
+ esac
+}
+
+
# use default for platform_do_upgrade()
disable_watchdog() {
--
1.8.4.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC PATCH] ar71xx: Support Antminer S1/S3
The generic changes I had intended to remove before a final submission. I'm also wondering what the best way to handle devices with 1 ethernet port is, should that be a WAN or a LAN port(right now it seems to be WAN with some things on the firewall opened up), it also has a rarely used wireless header that is configured as a LAN port. For the moment I'm a little stuck on separating it out fully from the tp-link device specifically in relation to tplink_board_detect() and the conflicting ID, would you have any suggestions for how to fix that? I'll work on making the patch as small as possible as well. I created the patch using a git diff and it seemed to apply when I used git apply, did my mail client mess up the formatting? On Sun, May 10, 2015 at 5:23 AM, Felix Fietkau n...@openwrt.org wrote: On 2015-05-02 05:08, James Hilliard wrote: I did my best to separate this device out, below is my current patch, comments appreciated. I'm having trouble figuring out how to differentiate the hwid which seems to be the same as the tp-link wr743nd-v2. 0x07430002 Is the hardware ID that both seem to have, is there any other ID's that I may be able to use? There are a lot of seemingly bogus unrelated changes, especially the ones to the generic code. The patch is completely misformatted, so it won't ever apply. Many of the changes do not make sense, so please make an effort to reduce the patch to the smallest amount of change to support the platform. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH V2] lantiq: add platform_pre_upgrade for sysupgrade
As explained in recent sysupgrade/nand.sh commits, current NAND
sysupgrade is a bit misleading because of nand_do_platform_check
behavior. It leaves a special mark in /tmp/sysupgrade-nand-path
triggering some diffent code path in nand_upgrade_stage1.
The plan is to have the check function only check the image and nothing
else. Then platform code (platform_pre_upgrade) should trigger NAND
specific upgrade path. This is what this patch implements.
Please note that because of current nand_upgrade_stage1 implementation
this patch doesn't change any behaior yet. It only prepares lantiq
target for changing nand_do_platform_check (it will be possible after
preparing all other targets as well).
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
V2: Fix typo in commit message (implementation)
Add only 1 empty line (instead of 2) in platform.sh
---
target/linux/lantiq/base-files/lib/upgrade/platform.sh | 10 ++
1 file changed, 10 insertions(+)
diff --git a/target/linux/lantiq/base-files/lib/upgrade/platform.sh
b/target/linux/lantiq/base-files/lib/upgrade/platform.sh
index 1688d3a..a38a468 100755
--- a/target/linux/lantiq/base-files/lib/upgrade/platform.sh
+++ b/target/linux/lantiq/base-files/lib/upgrade/platform.sh
@@ -25,6 +25,16 @@ platform_check_image() {
esac
}
+platform_pre_upgrade() {
+ local board=$(lantiq_board_name)
+
+ case $board in
+ BTHOMEHUBV2B|BTHOMEHUBV3A|P2812HNUF* )
+ nand_do_upgrade $1
+ ;;
+ esac
+}
+
# use default for platform_do_upgrade()
disable_watchdog() {
--
1.8.4.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ddns default config values broken?
Looking at the code the script is already pretty complicated for what it does. So i would say forget about the traffic it will generate, because it is close to nothing already. Just keep it simple. If you still decide to implement an increase, there should be a maximum of say 10 times the original retry interval. If your wan fails and comes back after hours the script might have reached a very high sleep time and will not update the records for a long time, not to mention wrapping numbers that might cause funny behaviour. Reading the code i found it very confusing that the verbosity level is abused to derive whether the scripts runs in loop- or one-shot- mode. That should be another command line parameter and a new variable in the script. But that is a totally different issue, and certainly a matter of style that can be argued about. Henning On Sat, 09 May 2015 19:09:32 +0200 Christian Schoenebeck christian.schoeneb...@gmail.com wrote: Hi Henning, the pull request is posted on github https://github.com/openwrt/packages/pull/1241 Please have a look on the comments. What do you think about a minimum or increasing sleep time before next retry ? Christian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] mtd: correct/change warning text about partition split / read-only status
mtd: remove the warning about read-only caused by size vs. block boundary
mismatch
patch version 2 as requested by nbd.
Since the kernel/rootfs split handling was modified 2 years ago by r37283 (
https://dev.openwrt.org/changeset/37283 ) and by the subsequent checkins,
users have seen rather scary mtd errors in the log at every boot. The message
ends -- forcing read-only, which looks a bit error-like. That error has
been mentioned in some forum threads, when users have noticed this message
instead of some actual error.
[2.94] 0x0007-0x00ff : firmware
[2.97] 2 netgear-fw partitions found on MTD device firmware
[2.97] 0x0007-0x00188440 : kernel
[2.98] mtd: partition kernel must either start or end on erase
block boundary or be smaller than an erase block -- forcing read-only
[2.99] 0x00188440-0x00ff : rootfs
The patch removes the rather useless warning message.
signed-off-by: Hannu Nyman hannu.ny...@iki.fi
---
On 10.5.2015 14:39, Felix Fietkau wrote:
I think this message is quite pointless anyway, so I'd prefer to simply
have it removed instead of changing it.
- Felix
Index: target/linux/generic/patches-3.18/411-mtd-partial_eraseblock_write.patch
===
--- target/linux/generic/patches-3.18/411-mtd-partial_eraseblock_write.patch
(revision 45667)
+++ target/linux/generic/patches-3.18/411-mtd-partial_eraseblock_write.patch
(working copy)
@@ -97,7 +97,7 @@
if (instr-fail_addr != MTD_FAIL_ADDR_UNKNOWN)
instr-fail_addr -= part-offset;
instr-addr -= part-offset;
-@@ -514,18 +582,24 @@ static struct mtd_part *allocate_partiti
+@@ -514,18 +582,21 @@ static struct mtd_part *allocate_partiti
if ((slave-mtd.flags MTD_WRITEABLE)
mtd_mod_by_eb(slave-offset, slave-mtd)) {
/* Doesn't start on a boundary of major erase size */
@@ -125,9 +125,6 @@
+ else
+ slave-mtd.erasesize = slave-mtd.size;
}
-+ if ((slave-mtd.flags (MTD_ERASE_PARTIAL|MTD_WRITEABLE)) ==
MTD_ERASE_PARTIAL)
-+ printk(KERN_WARNINGmtd: partition \%s\ must either start or
end on erase block boundary or be smaller than an erase block -- forcing
read-only\n,
-+ part-name);
slave-mtd.ecclayout = master-ecclayout;
slave-mtd.ecc_step_size = master-ecc_step_size;
Index: target/linux/generic/patches-4.0/411-mtd-partial_eraseblock_write.patch
===
--- target/linux/generic/patches-4.0/411-mtd-partial_eraseblock_write.patch
(revision 45667)
+++ target/linux/generic/patches-4.0/411-mtd-partial_eraseblock_write.patch
(working copy)
@@ -97,7 +97,7 @@
if (instr-fail_addr != MTD_FAIL_ADDR_UNKNOWN)
instr-fail_addr -= part-offset;
instr-addr -= part-offset;
-@@ -513,18 +581,24 @@ static struct mtd_part *allocate_partiti
+@@ -513,18 +581,21 @@ static struct mtd_part *allocate_partiti
if ((slave-mtd.flags MTD_WRITEABLE)
mtd_mod_by_eb(slave-offset, slave-mtd)) {
/* Doesn't start on a boundary of major erase size */
@@ -125,9 +125,6 @@
+ else
+ slave-mtd.erasesize = slave-mtd.size;
}
-+ if ((slave-mtd.flags (MTD_ERASE_PARTIAL|MTD_WRITEABLE)) ==
MTD_ERASE_PARTIAL)
-+ printk(KERN_WARNINGmtd: partition \%s\ must either start or
end on erase block boundary or be smaller than an erase block -- forcing
read-only\n,
-+ part-name);
slave-mtd.ecclayout = master-ecclayout;
slave-mtd.ecc_step_size = master-ecc_step_size;
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ddns default config values broken?
One Shot in verbose mode is for diagnostic on console only. To configure One Shot if starting via init.d script i.e. using cron you should set force_interval to 0. This will retry (retry_count) until one successful update. If looking into sources do it on Github or the source tree because during building all comments are removed. Thanks for feedback. Christian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Remove requirement of an absolute path to the perl interpreter
On 2015-05-10 20:49, Thomas Strobel wrote: On 05/10/2015 02:48 PM, Felix Fietkau wrote: On 2015-05-10 14:16, Thomas Strobel wrote: diff --git a/include/feeds.mk b/include/feeds.mk index 695b03b..27f3e8f 100644 --- a/include/feeds.mk +++ b/include/feeds.mk @@ -7,7 +7,7 @@ -include $(TMP_DIR)/.packagefeeds -FEEDS_AVAILABLE:=$(shell $(SCRIPT_DIR)/feeds list -n) +FEEDS_AVAILABLE:=$(perl $(SCRIPT_DIR)/feeds list -n) I think this is the wrong place to make the change. Why not change scripts/feeds to replace the #! line with: #!/usr/bin/env perl - Felix Thanks for the review. Unfortunately, /usr/bin/env does not exist either. In NixOS there is no /usr, no /sbin, and only a /bin/sh - /nix/store/nixos_installation_specific_hash/bash. The absolute path to, e.g., perl or env is different for each installation of NixOS, so it can't be hard-coded into the build script. That's why I thought of calling perl directly from the PATH environment. Then I think we should hold off on applying changes like the one you proposed until we have a proper plan for dealing with the rest. It needs to be possible to call ./scripts/feeds and similar scripts directly. How do other perl scripts on NixOS deal with that sort of stuff? - Felix The way how NixOS deals with absolute path names in scripts is to patch every script. If software is packed for NixOS, then scripts are automatically or manually patched to execute under NixOS. For software that is not packed but only executed in NixOS, the scripts have to be adapted manually. Ugh, that sounds really nasty. As OpenWRT is just executed, the scripts have to be adapted manually for each new version or checkout of OpenWRT. The only reasonable way I can think of so far to fix the scripts in OpenWRT is at the calling side, like suggested in my patch. However, there are only 3-4 places that need changing in the build system and in a standard set of packages. So it wouldn't need too much tweaking on the OpenWRT side. Given that the approach is incomplete (and quite inconvenient for regular use), and any better fix will not need these changes at all, I still object to adding them. The way I see it, the issue of missing /usr/bin/env is going to come up frequently with package-internal builds as well. NixOS users should probably just create a symlink or wrapper script at /usr/bin/env, and we should make sure that all important places in OpenWrt use it. I really don't want to start adding more and more patches afterwards to deal with the quirky non-standard behavior of NixOS. - 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: add support for compex wpj531
Am 27.04.2015 um 16:48 schrieb Christian Mehlis: OpenWrt can be flashed with following uboot commands: tftpboot 0x8050 openwrt-ar71xx-generic-wpj531-16M-squashfs-sysupgrade.bin erase 0x9f03 +$filesize cp.b $fileaddr 0x9f03 $filesize Signed-off-by: Christian Mehlis christ...@m3hlis.de @nbd are there any comments on the board support? Any reasons for not merging it? Best Christian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
