[OpenWrt-Devel] [PATCH V2 procd] hotplug: support for interval commands
This allows executing code with a given interval. As every command, it
can be assign to any uevent.
Intervals may be useful for counting elapsed time since some action. It
allows e.g. indicating that button has been pressed for some time. This
is useful to let user know he can already release the button.
Signed-off-by: Rafał Miłecki
---
V2: Use avl instead of flat list
Use uloop_process: don't spawn multiple processes, monitor them
---
plug/hotplug.c | 166 +
1 file changed, 166 insertions(+)
diff --git a/plug/hotplug.c b/plug/hotplug.c
index 1a98e8b..83ddc2b 100644
--- a/plug/hotplug.c
+++ b/plug/hotplug.c
@@ -19,6 +19,7 @@
#include
#include
+#include
#include
#include
#include
@@ -43,7 +44,20 @@ struct cmd_queue {
void (*handler)(struct blob_attr *msg, struct blob_attr *data);
};
+struct cmd_interval {
+ struct avl_node avl;
+
+ bool cancelled;
+ struct timespec start;
+ struct uloop_timeout timeout;
+ struct uloop_process process;
+
+ struct blob_attr *msg;
+ struct blob_attr *data;
+};
+
static LIST_HEAD(cmd_queue);
+static AVL_TREE(cmd_intervals, avl_strcmp, false, NULL);
static struct uloop_process queue_proc;
static struct uloop_timeout last_event;
static struct blob_buf b;
@@ -157,6 +171,150 @@ static void handle_exec(struct blob_attr *msg, struct
blob_attr *data)
exit(-1);
}
+static void handle_set_interval_timeout(struct uloop_timeout *timeout)
+{
+ struct cmd_interval *interval = container_of(timeout, struct
cmd_interval, timeout);
+ struct blob_attr *cur;
+ char *argv[8];
+ int rem, fd;
+ int msecs = 0;
+ int i = 0;
+
+ blobmsg_for_each_attr(cur, interval->data, rem) {
+ switch (i) {
+ case 0:
+ break;
+ case 1:
+ msecs = strtol(blobmsg_get_string(cur), NULL, 0);
+ break;
+ default:
+ argv[i - 2] = blobmsg_data(cur);
+ }
+ i++;
+ if (i - 2 == 7)
+ break;
+ }
+
+ if (interval->process.pending) {
+ uloop_timeout_set(&interval->timeout, msecs);
+ return;
+ }
+
+ interval->process.pid = fork();
+ if (interval->process.pid < 0) {
+ perror("fork");
+ } else if (interval->process.pid == 0) {
+ struct timespec now;
+ char elapsed[6];
+
+ if (i - 2 <= 0)
+ return;
+
+ clock_gettime(CLOCK_MONOTONIC, &now);
+ snprintf(elapsed, sizeof(elapsed), "%ld", now.tv_sec -
interval->start.tv_sec);
+
+ blobmsg_for_each_attr(cur, interval->msg, rem)
+ setenv(blobmsg_name(cur), blobmsg_data(cur), 1);
+ setenv("ACTION", "interval", 1);
+ setenv("ELAPSED", elapsed, 1);
+ unsetenv("SEEN");
+
+ if (debug < 3) {
+ fd = open("/dev/null", O_RDWR);
+ if (fd > -1) {
+ dup2(fd, STDIN_FILENO);
+ dup2(fd, STDOUT_FILENO);
+ dup2(fd, STDERR_FILENO);
+ if (fd > STDERR_FILENO)
+ close(fd);
+ }
+ }
+
+ argv[i - 2] = NULL;
+ execvp(argv[0], &argv[0]);
+ exit(-1);
+ } else {
+ uloop_process_add(&interval->process);
+ uloop_timeout_set(&interval->timeout, msecs);
+ }
+}
+
+static void handle_set_interval_process_cb(struct uloop_process *process, int
ret)
+{
+ struct cmd_interval *interval = container_of(process, struct
cmd_interval, process);
+
+ if (interval->cancelled)
+ free(interval);
+}
+
+static void handle_set_interval(struct blob_attr *msg, struct blob_attr *data)
+{
+ static struct blobmsg_policy set_interval_policy[2] = {
+ { .type = BLOBMSG_TYPE_STRING },
+ { .type = BLOBMSG_TYPE_STRING },
+ };
+ struct blob_attr *tb[2];
+ struct cmd_interval *interval;
+ struct blob_attr *_msg, *_data;
+ char *_key;
+ char *name;
+ int msecs;
+
+ blobmsg_parse_array(set_interval_policy, 2, tb, blobmsg_data(data),
blobmsg_data_len(data));
+ if (!tb[0] || !tb[1])
+ return;
+ name = blobmsg_get_string(tb[0]);
+ msecs = strtol(blobmsg_get_string(tb[1]), NULL, 0);
+
+ interval = calloc_a(sizeof(struct cmd_interval),
+ &_key, strlen(name) + 1,
+ &_msg, blob_pad_
[OpenWrt-Devel] [PATCH procd] hotplug: support for interval commands
This allows executing code with a given interval. As every command, it
can be triggered by any uevent.
Intervals may be useful for counting elapsed time since some action. It
allows e.g. indicating that button has been pressed for some time and
can be already released.
Signed-off-by: Rafał Miłecki
---
Example usage:
[ "if",
[ "and",
[ "eq", "SUBSYSTEM", "button" ],
[ "eq", "BUTTON", "wps" ],
[ "eq", "ACTION", "pressed" ],
],
[ "set-interval", "wpsbutton", "1000",
"/etc/rc.button/%BUTTON%" ]
],
[ "if",
[ "and",
[ "eq", "SUBSYSTEM", "button" ],
[ "eq", "BUTTON", "wps" ],
[ "eq", "ACTION", "released" ],
],
[ "clear-interval", "wpsbutton" ]
],
Result from /etc/rc.button/wps script:
SUBSYSTEM:button BUTTON:wps ACTION:pressed SEEN:34 ELAPSED:
SUBSYSTEM:button BUTTON:wps ACTION:interval SEEN: ELAPSED:1
SUBSYSTEM:button BUTTON:wps ACTION:interval SEEN: ELAPSED:2
SUBSYSTEM:button BUTTON:wps ACTION:interval SEEN: ELAPSED:3
SUBSYSTEM:button BUTTON:wps ACTION:released SEEN:3 ELAPSED:
---
plug/hotplug.c | 143 +
1 file changed, 143 insertions(+)
diff --git a/plug/hotplug.c b/plug/hotplug.c
index 1a98e8b..0b183fb 100644
--- a/plug/hotplug.c
+++ b/plug/hotplug.c
@@ -43,7 +43,19 @@ struct cmd_queue {
void (*handler)(struct blob_attr *msg, struct blob_attr *data);
};
+struct cmd_interval {
+ char *name;
+ struct list_head list;
+
+ struct timespec start;
+ struct uloop_timeout timeout;
+
+ struct blob_attr *msg;
+ struct blob_attr *data;
+};
+
static LIST_HEAD(cmd_queue);
+static LIST_HEAD(cmd_intervals);
static struct uloop_process queue_proc;
static struct uloop_timeout last_event;
static struct blob_buf b;
@@ -157,6 +169,129 @@ static void handle_exec(struct blob_attr *msg, struct
blob_attr *data)
exit(-1);
}
+static void handle_set_interval_timeout(struct uloop_timeout *timeout)
+{
+ struct cmd_interval *interval = container_of(timeout, struct
cmd_interval, timeout);
+ struct blob_attr *cur;
+ char *argv[8];
+ int rem, fd, pid;
+ int msecs = 0;
+ int i = 0;
+
+ blobmsg_for_each_attr(cur, interval->data, rem) {
+ switch (i) {
+ case 0:
+ break;
+ case 1:
+ msecs = strtol(blobmsg_get_string(cur), NULL, 0);
+ break;
+ default:
+ argv[i - 2] = blobmsg_data(cur);
+ }
+ i++;
+ if (i - 2 == 7)
+ break;
+ }
+
+ pid = fork();
+ if (pid < 0) {
+ perror("fork");
+ } else if (pid == 0) {
+ struct timespec now;
+ char elapsed[6];
+
+ if (i - 2 <= 0)
+ return;
+
+ clock_gettime(CLOCK_MONOTONIC, &now);
+ snprintf(elapsed, sizeof(elapsed), "%ld", now.tv_sec -
interval->start.tv_sec);
+
+ blobmsg_for_each_attr(cur, interval->msg, rem)
+ setenv(blobmsg_name(cur), blobmsg_data(cur), 1);
+ setenv("ACTION", "interval", 1);
+ setenv("ELAPSED", elapsed, 1);
+ unsetenv("SEEN");
+
+ if (debug < 3) {
+ fd = open("/dev/null", O_RDWR);
+ if (fd > -1) {
+ dup2(fd, STDIN_FILENO);
+ dup2(fd, STDOUT_FILENO);
+ dup2(fd, STDERR_FILENO);
+ if (fd > STDERR_FILENO)
+ close(fd);
+ }
+ }
+
+ argv[i - 2] = NULL;
+ execvp(argv[0], &argv[0]);
+ exit(-1);
+ } else {
+ uloop_timeout_set(&interval->timeout, msecs);
+ }
+}
+
+static void handle_set_interval(struct blob_attr *msg, struct blob_attr *data)
+{
+ static struct blobmsg_policy set_interval_policy[2] = {
+ { .type = BLOBMSG_TYPE_STRING },
+ { .type = BLOBMSG_TYPE_STRING },
+ };
+ struct blob_attr *tb[2];
+ struct cmd_interval *interval;
+ struct blob_attr *_msg, *_data;
+ int msecs;
+
+ blobmsg_
Re: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.
On 29 April 2015 at 12:51, Hante Meuleman wrote: > Status report: spent lots of time trying to figure out how to use cpu > port 8 and use vlan1ports "0 1 2 3 5 7 8t", and found that I got fooled > by the way I tried to determine if it was working or not. To see if the > switch configuration was working I used to type "ifconfig" and then > see if there were and rx packets. Today I added logging in bgmac to > see if there are any rx interrupts, and to my surprise there are. So it > is possible to get it to work with cpu port 8 but the data is being > dropped by the stack (nothing visible in the counters). This is sample > data that gets received: > > [ 32.759614] bgmac: ETH, len=324, flags=0x01, protocol=0x0008 > [ 32.766714] bgmac: 45 00 01 36 bc f2 40 00 ff 11 19 8a c0 a8 02 96 > [ 32.774796] bgmac: e0 00 00 fb 14 e9 14 e9 01 22 b5 86 00 00 84 00 > [ 32.782892] bgmac: ETH, len=344, flags=0x01, protocol=0xdd86 > [ 32.789989] bgmac: 60 00 00 00 01 22 11 ff fd 1b 72 e5 79 5c 00 00 > [ 32.798077] bgmac: 75 58 39 77 51 db f7 b2 ff 02 00 00 00 00 00 00 Packets received by bgmac are supposed to be VLAN tagged. Are they in your case? I think you're dumping beginning on every packet. Compare dump (early bytes, look for 802.1Q header [0]) when using 5t vs. 8t. [0] http://en.wikipedia.org/wiki/IEEE_802.1Q ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ubox: CMake: fix json-c detection
On 27 April 2015 at 22:13, Yegor Yefremov wrote: > Use PKG_SEARCH_MODULE() to detect json-c library, > otherwise the search fails, if both json-c and json > are not present in pkg-config database. Just wanted to say thanks. I remember I got some problems with finding json-c when trying to install ubox on my PC. Guess it was it. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.
On 24 April 2015 at 12:03, Hante Meuleman wrote: > Attached are the two patch files. They were generated from > include/linux/bcm47xx_nvram.h and from > drivers/firmware/broadcom/bcm47xx_nvram.c. I think your idea is correct, I was just thinking about bcm47xx_nvram copying content to provided buffer, instead of sharing its own. I got an impression it's solution usually used when dealing with such situations & this would also protect bcm47xx internals. I'm not really sure how to submit this patch. It exports symbol and will be required by brcmfmac, so I guess we should ask Kalle to pick it. However I also planned moving nvram.c from mips to bcm47xx_nvram.c in firmware and I planned to submit this patch to Ralf (mips maintainer). Maybe it'll be better to work on moving NVRAM driver first? This would make more sense to Kalle accepting drivers/firmware/ patch rather than arch/mips/. We could keep this change in OpenWrt for now. I could submit patch to Ralf for 3.2 kernel. Then for 3.3 we could finally upstream your change to Kalle's tree. Can you also share your brcmfmac patch? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.
On 24 April 2015 at 10:18, Hante Meuleman wrote: > Do you want the patch on top of > > target/linux/bcm53xx/patches-3.18/110-firmware-backport-NVRAM-driver.patch > > Or on top of the unpatched > > drivers/firmware/broadcom/bcm47xx_nvram.c > > Or on top of the kernel driver file where 110-firmwarepatch > already has been applied? > > Or on top of the file > > target/linux/bcm53xx/files/drivers/firmware/Broadcom/bcm47xx_nvram.c > > The latter would be the easiest, but it probably breaks the 110 patch. > > In upstream kernels the bcm47xx_nvram is not part of the kernel, > this made me believe that it was generated with a patch file. > Didn’t realize that the OpenWRT also has a files directory from > which the additional kernel drivers get "injected" in the kernel: > > target/linux/bcm53xx/files/drivers/firmware/broadcom > > Still this makes me believe they are openwrt specific kernel file, > but I guess, that is just how one wants to read this sentence. NVRAM driver is part of upstream kernel, it's just living in arch/mips/ for now: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/mips/bcm47xx/nvram.c bcm53xx's file is just a copy of above and that would be the best to keep it this way. I think you may prepare patch on top of drivers/firmware/broadcom/bcm47xx_nvram.c for now, then we can work on upstreaming it. Meanwhile I'll be happy to add your patch to /home/zajec/openwrt/openwrt.git/target/linux/bcm53xx/patches-3.18/ It doesn't matter if you work on top of 110-firmware-backport-NVRAM-driver.patch, it doesn't even touch (bcm47xx_)nvram.c. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.
On 23 April 2015 at 13:14, Hante Meuleman wrote: > Attached are > three files, one is from brcmfmac (firmware.c). This file is > added to demo how brcmfmac will use a new function of > bm47xx_nvram. The changes in this file are currently under > internal review and the patch may change, but it has been > tested and verified so it can be used to try it out. There exists a diff/patch format for a very good reason. Please send patches, so I can review your changes. > The other > two files bcm47xx_nvram.c and bcm47xx_nvram.h are > OpenWRT specific kernel files. Not really, they are part of the kernel. I was working for last few months moving them out of MIPS arch code. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.
On 20 April 2015 at 22:16, Arend van Spriel wrote: > On 04/20/15 20:49, Rafał Miłecki wrote: >> >> On 20 April 2015 at 19:12, Arend van Spriel wrote: >>> >>> On 04/20/15 13:26, Rafał Miłecki wrote: >>>> >>>> >>>> On 17 April 2015 at 10:50, Arend van Spriel wrote: >>>>> >>>>> Another option is to add the parsing stuff in that nvram code and have >>>>> an >>>>> api to get the appropriate portion based on pcie domain and bus number >>>>> as >>>>> used in brcmf_fw_get_firmwares_pcie(). However, I would prefer to have >>>>> this >>>>> in the driver and not in arch specific code as there may be other >>>>> platforms >>>>> like our set-top boxes needing this. >>>> >>>> >>>> >>>> This is some plan for the future I was lacking from the beginning. It >>>> makes things more clear now, thanks. >>> >>> >>> You're welcome. Do you want to see this clarification in the commit >>> message? >> >> >> I don't really need that, I'm leaving it up to you :) >> >> The last remaining question from me is if about this NVRAM validation >> function (if it exists). > > > Ok. I can try to answer that one. The nvram parsing code in firmware.c > intends to do just that. So apart from stripping comments and whitespace it > validates each line and gives off a warning if a wrongly formatted entry is > found. OK, thanks. So I guess this patch is OK after all? -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] generic/4.0: Linux 4.0 was released on 2014-04-12
On 20 April 2015 at 17:24, Daniel Golle wrote: > Signed-off-by: Daniel Golle Daniel, commit message should say what the patch does. Now what has happened in the world. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.
On 20 April 2015 at 19:12, Arend van Spriel wrote: > On 04/20/15 13:26, Rafał Miłecki wrote: >> >> On 17 April 2015 at 10:50, Arend van Spriel wrote: >>> Another option is to add the parsing stuff in that nvram code and have an >>> api to get the appropriate portion based on pcie domain and bus number as >>> used in brcmf_fw_get_firmwares_pcie(). However, I would prefer to have >>> this >>> in the driver and not in arch specific code as there may be other >>> platforms >>> like our set-top boxes needing this. >> >> >> This is some plan for the future I was lacking from the beginning. It >> makes things more clear now, thanks. > > You're welcome. Do you want to see this clarification in the commit message? I don't really need that, I'm leaving it up to you :) The last remaining question from me is if about this NVRAM validation function (if it exists). -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.
On 20 April 2015 at 13:50, Jonas Gorski wrote: > On Mon, Apr 20, 2015 at 1:29 PM, Rafał Miłecki wrote: >> On 20 April 2015 at 11:27, Arend van Spriel wrote: >>>> Following an "nvram erase" none of the needed pairs remain >>>> in nvram. So we probably can't use nvram in a reliable way to create the >>>> wireless configuration. >>> >>> >>> So why do "nvram erase"? The assumption that it is not needed because you >>> are running an OpenWRT image is wrong or at least only partially true, ie. >>> for the user-space settings. >> >> I agree with Arend. If you're are erasing sensitive wireless info from >> your device, expect problems. The same will happen if you'll overwrite >> standard Broadcom PCI device SPROM (which contains the same kind of >> data). > > At least on older bcm47xx/MIPS devices nvram was also used for (user > changable) configuration like lan ip address, and consequently erasing > nvram caused CFE to restore the default values, which should include > the right wifi configuration values. Several devices even do so when > holding down reset for a long time at power up*. Does this not happen > anymore with bcm53xx/ARM? Are user values now stored in a different > partition? CFE when restoring NVRAM is using its own minimal copy. It contains some basic settings needed for SoC to basically work (CPU config, RAM config, Ethernet MAC). It doesn't contain detailed data like wireless devices configuration. -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.
On 20 April 2015 at 11:27, Arend van Spriel wrote: >> Following an "nvram erase" none of the needed pairs remain >> in nvram. So we probably can't use nvram in a reliable way to create the >> wireless configuration. > > > So why do "nvram erase"? The assumption that it is not needed because you > are running an OpenWRT image is wrong or at least only partially true, ie. > for the user-space settings. I agree with Arend. If you're are erasing sensitive wireless info from your device, expect problems. The same will happen if you'll overwrite standard Broadcom PCI device SPROM (which contains the same kind of data). -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.
On 17 April 2015 at 10:50, Arend van Spriel wrote: > On 04/17/15 09:45, Rafał Miłecki wrote: >> >> Huh, why dropping linux-wireless (and top posting btw)? Please let >> everyone follow the discussion :) >> >> On 15 April 2015 at 21:20, Hante Meuleman wrote: >>> >>> As I wrote to you in a mail and on the openwrt forum, this patch is >>> indeed an attempt to support more complex nvram files. I also wrote, that in >>> order to be able to use it, the nvram contents of the device (r8000) needs >>> to be put a specific file. Now for your concerns, we can perhaps add >>> something which will read the nvram contents directly from an nvram store. >>> But that is irrelevant to this patch. The parsing is still needed, and all >>> we would need to add is something which is reading the nvram contents from >>> some other place >> >> >> So it makes me wonder if we need this patch in its current form. I >> think getting NVRAM directly from the platform is much user friendly. >> It doesn't require user to install some extra tools for dumping NVRAM >> and putting it in a specific file. One extra layer less. >> With that said I think it's hard to review your code for parsing >> NVRAM. We don't know how it's going to be fetched in the first place. > > You already made that point and we agreed to look for a solution. OK, it wasn't supposed to be rude or anything :) Thanks. >>> though it would have to be put under some kernel config flag as this >>> would not be supported in non-router systems. The contents of the nvram >>> would however still need to be parsed in exactly the same way as the nvram >>> files we read from disk. >> >> >> Again, it's hard to say for me. Are you going to use >> bcm47xx_nvram_getenv? Are you going to use MTD subsystem? Are you >> going to develop different solution? When using e.g. >> bcm47xx_nvram_getenv you won't want all this parsing stuff at all. > > > Please look at the usage scenario here. The brcmfmac driver is not needing a > few key,value pairs. It needs a portion of NVRAM to download to the device. > The patch provides the functionality to do just that. Get the appropriate > portion, strip comments and whitespace, and send it to the device. Using > bcm47xx_nvram_getenv is not a useful api as it would mean we need brcmfmac > to know which key ids to ask for, reassemble it to key=value string and send > it to the fullmac device. > > In bcm47xx_nvram_getenv() it does have the whole nvram content available in > nvram_buf which is filled by nvram_init(). So if something similar is made > available on r8000 (or ARM routers in general) build target all we need is > an api to get the nvram_buf. > > Another option is to add the parsing stuff in that nvram code and have an > api to get the appropriate portion based on pcie domain and bus number as > used in brcmf_fw_get_firmwares_pcie(). However, I would prefer to have this > in the driver and not in arch specific code as there may be other platforms > like our set-top boxes needing this. This is some plan for the future I was lacking from the beginning. It makes things more clear now, thanks. -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH V2] b53: override CPU port state on BCM5301X with CPU port other than 8
On 15 April 2015 at 07:37, Ian Kent wrote: > On Sun, 2015-04-12 at 19:01 +0200, Rafał Miłecki wrote: >> Newer revisions (5+) of BCM53011 and probably all revs of BCM53012 >> require overriding CPU port to work. So far we were handling it only for >> CPU port 8, but some devices may use e.g. port 5. In such case we need >> to use recently defined GMII_PORT registers. >> It was tested for regressions on BCM53011 revs 2 & 3. It was also >> confirmed to fix switch on some internal Broadcom board. > > CPU port as 5 also allows the switch on my R8000 (BCM53012) rev 5 device > to function. > > The puzzle is the the Vendor firmware uses port 8 as the cpu port (+ 5 > and 7 for some unknown purpose) for these higher rev switches. We > clearly don't know what the relationship is between ports 5, 7 and 8 and > I suspect there's more to it than just configuring the three ports > properly. But my code to set ports 5, 7 and 8 when cpu is 8 might not be > correct either, don't know yet. I guess this is simply for performance reasons. Imagine there are two 1 Gbps devices connected to the router and that they want to "talk" with router system (for whatever reason). To achieve max speeds we need router system to Tx/Rx with 2 Gbps. This is impossible if switch is connected to CPU with a single 1 Gbps port. By combining 2/3 ports this should be possible (of course you're still limited by CPU performance). ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH V2] b53: override CPU port state on BCM5301X with CPU port other than 8
Newer revisions (5+) of BCM53011 and probably all revs of BCM53012
require overriding CPU port to work. So far we were handling it only for
CPU port 8, but some devices may use e.g. port 5. In such case we need
to use recently defined GMII_PORT registers.
It was tested for regressions on BCM53011 revs 2 & 3. It was also
confirmed to fix switch on some internal Broadcom board.
Signed-off-by: Rafał Miłecki
---
V2: Use new code branch to make (unused) port 8 branch reachable.
---
.../generic/files/drivers/net/phy/b53/b53_common.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
b/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
index d2bb51a..2079f80 100644
--- a/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
+++ b/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
@@ -536,6 +536,23 @@ static int b53_switch_reset(struct b53_device *dev)
PORT_OVERRIDE_LINK);
}
+ if (is5301x(dev)) {
+ if (dev->sw_dev.cpu_port == 8) {
+ /* TODO: Ports 5 & 7 require some extra handling */
+ } else {
+ u8 po_reg =
B53_GMII_PORT_OVERRIDE_CTRL(dev->sw_dev.cpu_port);
+ u8 gmii_po;
+
+ b53_read8(dev, B53_CTRL_PAGE, po_reg, &gmii_po);
+ gmii_po |= GMII_PO_LINK |
+ GMII_PO_RX_FLOW |
+ GMII_PO_TX_FLOW |
+ GMII_PO_EN |
+ GMII_PO_SPEED_2000M;
+ b53_write8(dev, B53_CTRL_PAGE, po_reg, gmii_po);
+ }
+ }
+
b53_enable_mib(dev);
return b53_flush_arl(dev);
--
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] [PATCH] b53: override CPU port state on BCM5301X with CPU port other than 8
On 12 April 2015 at 18:16, Jonas Gorski wrote:
> On Sun, Apr 12, 2015 at 6:03 PM, Rafał Miłecki wrote:
>> Newer revisions (5+) of BCM53011 and probably all revs of BCM53012
>> require overriding CPU port to work. So far we were handling it only for
>> CPU port 8, but some devices may use e.g. port 5. In such case we need
>> to use recently defined GMII_PORT registers.
>> It was tested for regressions on BCM53011 revs 2 & 3. It was also
>> confirmed to fix switch on some internal Broadcom board.
>>
>> Signed-off-by: Rafał Miłecki
>> ---
>> .../linux/generic/files/drivers/net/phy/b53/b53_common.c | 15
>> +++
>> 1 file changed, 15 insertions(+)
>>
>> diff --git a/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
>> b/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
>> index d2bb51a..87c4d5b 100644
>> --- a/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
>> +++ b/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
>> @@ -534,6 +534,21 @@ static int b53_switch_reset(struct b53_device *dev)
>> b53_write8(dev, B53_CTRL_PAGE, B53_PORT_OVERRIDE_CTRL,
>>mii_port_override | PORT_OVERRIDE_EN |
>>PORT_OVERRIDE_LINK);
>> + } else if (is5301x(dev)) {
>> + if (dev->sw_dev.cpu_port == 8) {
>> + /* TODO: Ports 5 & 7 require some extra handling */
>
> This branch can never be reached because the previous has
>
> else if ((is531x5(dev) || is5301x(dev)) &&
>dev->sw_dev.cpu_port == B53_CPU_PORT) { /*
> B53_CPU_PORT is 8 */
Yes, as discussed with you earlier, I didn't move the code from
previous branch yet, since there weren't any differences. Once we
implement differences in port 8 handling on BCM5301X all the code
should be moved to the new branch and condition should be changed.
--
Rafał
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] b53: override CPU port state on BCM5301X with CPU port other than 8
Newer revisions (5+) of BCM53011 and probably all revs of BCM53012
require overriding CPU port to work. So far we were handling it only for
CPU port 8, but some devices may use e.g. port 5. In such case we need
to use recently defined GMII_PORT registers.
It was tested for regressions on BCM53011 revs 2 & 3. It was also
confirmed to fix switch on some internal Broadcom board.
Signed-off-by: Rafał Miłecki
---
.../linux/generic/files/drivers/net/phy/b53/b53_common.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
b/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
index d2bb51a..87c4d5b 100644
--- a/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
+++ b/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
@@ -534,6 +534,21 @@ static int b53_switch_reset(struct b53_device *dev)
b53_write8(dev, B53_CTRL_PAGE, B53_PORT_OVERRIDE_CTRL,
mii_port_override | PORT_OVERRIDE_EN |
PORT_OVERRIDE_LINK);
+ } else if (is5301x(dev)) {
+ if (dev->sw_dev.cpu_port == 8) {
+ /* TODO: Ports 5 & 7 require some extra handling */
+ } else {
+ u8 po_reg =
B53_GMII_PORT_OVERRIDE_CTRL(dev->sw_dev.cpu_port);
+ u8 gmii_po;
+
+ b53_read8(dev, B53_CTRL_PAGE, po_reg, &gmii_po);
+ gmii_po |= GMII_PO_LINK |
+ GMII_PO_RX_FLOW |
+ GMII_PO_TX_FLOW |
+ GMII_PO_EN |
+ GMII_PO_SPEED_2000M;
+ b53_write8(dev, B53_CTRL_PAGE, po_reg, gmii_po);
+ }
}
b53_enable_mib(dev);
--
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] [PATCH] brcm47xx: explicitly select CPU_MIPS32_R2 and CPU_MIPSR2 for mips74k
On 5 April 2015 at 20:03, Nathan Hintz wrote: > The mips74k subtarget of brcm47xx configures gcc to compile for mips32r2; > however, the generated kernel config for 3.14 and later kernels ends up > with CPU_MIPS32_R1 and CPU_MIPSR1 selected. The generated kernel config > for the 3.10 kernel (Barrier Breaker) properly selected CPU_MIPS32_R2 and > CPU_MIPSR2. Modify the default kernel config for mips74k to explicitly > select CPU_MIPS32_R2 and CPU_MIPSR2. I think it makes sense. Hauke? Any reason it wasn't applied back in 2014? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH V3 fstools 2/2] jffs2reset: use jffs2_mark if rootfs_data isn't mounted
Erasing all rootfs_data blocks may cause some problems with partition
identification. It won't contain MAGIC, but will be successfully mounted
with delayed blocks marking. This may be really confusing when user
reboots before JFFS2 finishes its blocks management. During the next
boot rootfs_data will be a valid partition (possibly with data) but
libblkid won't detect it.
Also adjust message in jffs2_mark to make more sense when used together
with jffs2_reset.
Signed-off-by: Rafał Miłecki
---
V2: Update ulog messages. E.hg. the one in jffs2_mark shouldn't include
implementation details (deadc0de).
---
jffs2reset.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/jffs2reset.c b/jffs2reset.c
index 778a97e..0410466 100644
--- a/jffs2reset.c
+++ b/jffs2reset.c
@@ -27,6 +27,8 @@
#include "libfstools/libfstools.h"
#include "libfstools/volume.h"
+static int jffs2_mark(struct volume *v);
+
static int
ask_user(int argc, char **argv)
{
@@ -50,8 +52,8 @@ static int jffs2_reset(struct volume *v)
overlay_delete(mp, false);
mount(mp, "/", NULL, MS_REMOUNT, 0);
} else {
- ULOG_INFO("%s is not mounted, erasing it\n", v->blk);
- volume_erase_all(v);
+ ULOG_INFO("%s is not mounted\n", v->blk);
+ return jffs2_mark(v);
}
return 0;
@@ -64,7 +66,7 @@ static int jffs2_mark(struct volume *v)
int fd;
fd = open(v->blk, O_WRONLY);
- ULOG_INFO("%s - marking with deadc0de\n", v->blk);
+ ULOG_INFO("%s will be erased on next mount\n", v->blk);
if (!fd) {
ULOG_ERR("opening %s failed\n", v->blk);
return -1;
--
1.8.4.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH V3 fstools 1/2] jffs2reset: avoid code duplication in jffs2_reset and jffs2_mark
Signed-off-by: Rafał Miłecki
---
V3: Update TODO comment to be more clear.
---
jffs2reset.c | 56 +---
1 file changed, 25 insertions(+), 31 deletions(-)
diff --git a/jffs2reset.c b/jffs2reset.c
index 1080883..778a97e 100644
--- a/jffs2reset.c
+++ b/jffs2reset.c
@@ -39,26 +39,10 @@ ask_user(int argc, char **argv)
}
-static int
-jffs2_reset(int argc, char **argv)
+static int jffs2_reset(struct volume *v)
{
- struct volume *v;
char *mp;
- if (ask_user(argc, argv))
- return -1;
-
- if (find_filesystem("overlay")) {
- ULOG_ERR("overlayfs not supported by kernel\n");
- return -1;
- }
-
- v = volume_find("rootfs_data");
- if (!v) {
- ULOG_ERR("MTD partition 'rootfs_data' not found\n");
- return -1;
- }
-
mp = find_mount_point(v->blk, 1);
if (mp) {
ULOG_INFO("%s is mounted as %s, only erasing files\n", v->blk,
mp);
@@ -73,23 +57,12 @@ jffs2_reset(int argc, char **argv)
return 0;
}
-static int
-jffs2_mark(int argc, char **argv)
+static int jffs2_mark(struct volume *v)
{
__u32 deadc0de = __cpu_to_be32(0xdeadc0de);
- struct volume *v;
size_t sz;
int fd;
- if (ask_user(argc, argv))
- return -1;
-
- v = volume_find("rootfs_data");
- if (!v) {
- ULOG_ERR("MTD partition 'rootfs_data' not found\n");
- return -1;
- }
-
fd = open(v->blk, O_WRONLY);
ULOG_INFO("%s - marking with deadc0de\n", v->blk);
if (!fd) {
@@ -110,7 +83,28 @@ jffs2_mark(int argc, char **argv)
int main(int argc, char **argv)
{
+ struct volume *v;
+
+ if (ask_user(argc, argv))
+ return -1;
+
+ /*
+* TODO: Currently this only checks if kernel supports OverlayFS. We
+* should check if there is a mount point using it with rootfs_data
+* as upperdir.
+*/
+ if (find_filesystem("overlay")) {
+ ULOG_ERR("overlayfs not supported by kernel\n");
+ return -1;
+ }
+
+ v = volume_find("rootfs_data");
+ if (!v) {
+ ULOG_ERR("MTD partition 'rootfs_data' not found\n");
+ return -1;
+ }
+
if (!strcmp(*argv, "jffs2mark"))
- return jffs2_mark(argc, argv);
- return jffs2_reset(argc, argv);
+ return jffs2_mark(v);
+ return jffs2_reset(v);
}
--
1.8.4.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH V2 fstools 2/2] jffs2reset: use jffs2_mark if rootfs_data isn't mounted
Erasing all rootfs_data blocks may cause some problems with partition
identification. It won't contain MAGIC, but will be successfully mounted
with delayed blocks marking. This may be really confusing when user
reboots before JFFS2 finishes its blocks management. During the next
boot rootfs_data will be a valid partition (possibly with data) but
libblkid won't detect it.
Also adjust message in jffs2_mark to make more sense when used together
with jffs2_reset.
Signed-off-by: Rafał Miłecki
---
jffs2reset.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/jffs2reset.c b/jffs2reset.c
index d634386..20218de 100644
--- a/jffs2reset.c
+++ b/jffs2reset.c
@@ -27,6 +27,8 @@
#include "libfstools/libfstools.h"
#include "libfstools/volume.h"
+static int jffs2_mark(struct volume *v);
+
static int
ask_user(int argc, char **argv)
{
@@ -50,8 +52,8 @@ static int jffs2_reset(struct volume *v)
overlay_delete(mp, false);
mount(mp, "/", NULL, MS_REMOUNT, 0);
} else {
- ULOG_INFO("%s is not mounted, erasing it\n", v->blk);
- volume_erase_all(v);
+ ULOG_INFO("%s is not mounted\n", v->blk);
+ return jffs2_mark(v);
}
return 0;
@@ -64,7 +66,7 @@ static int jffs2_mark(struct volume *v)
int fd;
fd = open(v->blk, O_WRONLY);
- ULOG_INFO("%s - marking with deadc0de\n", v->blk);
+ ULOG_INFO("%s will be erased on next mount\n", v->blk);
if (!fd) {
ULOG_ERR("opening %s failed\n", v->blk);
return -1;
--
1.8.4.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH V2 fstools 1/2] jffs2reset: avoid code duplication in jffs2_reset and jffs2_mark
Signed-off-by: Rafał Miłecki
---
jffs2reset.c | 52 +---
1 file changed, 21 insertions(+), 31 deletions(-)
diff --git a/jffs2reset.c b/jffs2reset.c
index 1080883..d634386 100644
--- a/jffs2reset.c
+++ b/jffs2reset.c
@@ -39,26 +39,10 @@ ask_user(int argc, char **argv)
}
-static int
-jffs2_reset(int argc, char **argv)
+static int jffs2_reset(struct volume *v)
{
- struct volume *v;
char *mp;
- if (ask_user(argc, argv))
- return -1;
-
- if (find_filesystem("overlay")) {
- ULOG_ERR("overlayfs not supported by kernel\n");
- return -1;
- }
-
- v = volume_find("rootfs_data");
- if (!v) {
- ULOG_ERR("MTD partition 'rootfs_data' not found\n");
- return -1;
- }
-
mp = find_mount_point(v->blk, 1);
if (mp) {
ULOG_INFO("%s is mounted as %s, only erasing files\n", v->blk,
mp);
@@ -73,23 +57,12 @@ jffs2_reset(int argc, char **argv)
return 0;
}
-static int
-jffs2_mark(int argc, char **argv)
+static int jffs2_mark(struct volume *v)
{
__u32 deadc0de = __cpu_to_be32(0xdeadc0de);
- struct volume *v;
size_t sz;
int fd;
- if (ask_user(argc, argv))
- return -1;
-
- v = volume_find("rootfs_data");
- if (!v) {
- ULOG_ERR("MTD partition 'rootfs_data' not found\n");
- return -1;
- }
-
fd = open(v->blk, O_WRONLY);
ULOG_INFO("%s - marking with deadc0de\n", v->blk);
if (!fd) {
@@ -110,7 +83,24 @@ jffs2_mark(int argc, char **argv)
int main(int argc, char **argv)
{
+ struct volume *v;
+
+ if (ask_user(argc, argv))
+ return -1;
+
+ /* TODO: Check for /overlay filesystem */
+ if (find_filesystem("overlay")) {
+ ULOG_ERR("overlayfs not supported by kernel\n");
+ return -1;
+ }
+
+ v = volume_find("rootfs_data");
+ if (!v) {
+ ULOG_ERR("MTD partition 'rootfs_data' not found\n");
+ return -1;
+ }
+
if (!strcmp(*argv, "jffs2mark"))
- return jffs2_mark(argc, argv);
- return jffs2_reset(argc, argv);
+ return jffs2_mark(v);
+ return jffs2_reset(v);
}
--
1.8.4.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH][RFT ar71xx] procd: get rid of /tmp/sysupgrade-nand-path magic
Signed-off-by: Rafał Miłecki
---
package/system/procd/files/nand.sh | 20 +++-
1 file changed, 7 insertions(+), 13 deletions(-)
diff --git a/package/system/procd/files/nand.sh
b/package/system/procd/files/nand.sh
index 0ed1b63..dfa1ee6 100644
--- a/package/system/procd/files/nand.sh
+++ b/package/system/procd/files/nand.sh
@@ -312,17 +312,15 @@ nand_upgrade_stage2() {
}
}
+# $(1): file to be used for upgrade
nand_upgrade_stage1() {
- [ -f /tmp/sysupgrade-nand-path ] && {
- path="$(cat /tmp/sysupgrade-nand-path)"
- [ "$SAVE_CONFIG" != 1 -a -f "$CONF_TAR" ] &&
- rm $CONF_TAR
+ local path="$1"
+ [ "$SAVE_CONFIG" != 1 -a -f "$CONF_TAR" ] &&
+ rm $CONF_TAR
- ubus call system nandupgrade "{\"path\": \"$path\" }"
- exit 0
- }
+ ubus call system nandupgrade "{\"path\": \"$path\" }"
+ exit 0
}
-append sysupgrade_pre_upgrade nand_upgrade_stage1
# Check if passed file is a valid one for NAND sysupgrade. Currently it accepts
# 3 types of files:
@@ -348,9 +346,6 @@ nand_do_platform_check() {
return 1
}
- echo -n $2 > /tmp/sysupgrade-nand-path
- cp /sbin/upgraded /tmp/
-
return 0
}
@@ -358,7 +353,6 @@ nand_do_platform_check() {
#
# $(1): file to be used for upgrade
nand_do_upgrade() {
- echo -n $1 > /tmp/sysupgrade-nand-path
cp /sbin/upgraded /tmp/
- nand_upgrade_stage1
+ nand_upgrade_stage1 "$1"
}
--
1.8.4.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ar71xx: add platform_pre_upgrade for sysupgrade
Signed-off-by: Rafał Miłecki
---
target/linux/ar71xx/base-files/lib/upgrade/platform.sh | 13 +
1 file changed, 13 insertions(+)
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index 0cbee1d..01278b5 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -446,6 +446,19 @@ platform_check_image() {
return 1
}
+platform_pre_upgrade() {
+ local board=$(ar71xx_board_name)
+
+ case "$board" in
+ nbg6716 | \
+ r6100 | \
+ wndr3700v4 | \
+ wndr4300 )
+ nand_do_upgrade "$1"
+ ;;
+ esac
+}
+
platform_do_upgrade() {
local board=$(ar71xx_board_name)
--
1.8.4.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/2] procd: add helper for starting NAND sysupgrade
Signed-off-by: Rafał Miłecki
---
package/system/procd/files/nand.sh | 9 +
1 file changed, 9 insertions(+)
diff --git a/package/system/procd/files/nand.sh
b/package/system/procd/files/nand.sh
index 7fb9343..0ed1b63 100644
--- a/package/system/procd/files/nand.sh
+++ b/package/system/procd/files/nand.sh
@@ -353,3 +353,12 @@ nand_do_platform_check() {
return 0
}
+
+# Start NAND upgrade process
+#
+# $(1): file to be used for upgrade
+nand_do_upgrade() {
+ echo -n $1 > /tmp/sysupgrade-nand-path
+ cp /sbin/upgraded /tmp/
+ nand_upgrade_stage1
+}
--
1.8.4.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/2] base-files: add support for platform_pre_upgrade function
Current NAND sysupgrade process is a bit hard to follow due to the way of triggering stage1. Currently this is done by leaving a /mark/ in the form of /tmp/sysupgrade-nand-path during nand_do_platform_check. Existence of this mark stops standard sysupgrade process (as the result of sysupgrade_pre_upgrade exit). This may be a bit misleading. Proposed solution adds a new function that will allow platform.sh trigger NAND sysupgrade consciously. This will also allow cleaning nand_do_platform_check limiting it to just checking the image. Signed-off-by: Rafał Miłecki --- package/base-files/files/sbin/sysupgrade | 8 1 file changed, 8 insertions(+) diff --git a/package/base-files/files/sbin/sysupgrade b/package/base-files/files/sbin/sysupgrade index 215f482..ef83c4b 100755 --- a/package/base-files/files/sbin/sysupgrade +++ b/package/base-files/files/sbin/sysupgrade @@ -215,6 +215,14 @@ fi run_hooks "" $sysupgrade_pre_upgrade +# Some platforms/devices may want different sysupgrade process, e.g. without +# killing processes yet or calling ubus system upgrade method. +# This is needed e.g. on NAND devices where we just want to trigger stage1 at +# this point. +if type 'platform_pre_upgrade' >/dev/null 2>/dev/null; then + platform_pre_upgrade "$ARGV" +fi + ubus call system upgrade touch /tmp/sysupgrade -- 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] I'd like to donate a Linksys WRT300N V1
On 5 April 2015 at 01:01, Rafał Miłecki wrote: > On 30 March 2015 at 23:43, Rafał Miłecki wrote: >> On 17 March 2015 at 22:05, Alex Henrie wrote: >>> I just mailed the router. When it arrives, please send confirmation to >>> me and to treasu...@spi-inc.org. >> >> I just got it today, thanks! >> >> I disassembled it, it's really a PCMCIA wireless card, nice :) Quite >> an unique device! > > Well, it isn't that simple. It's actually CardBus, which is much > closer to PCI rather than what I meant by PCMCIA. > > >> I'll have to install serial console (requires soldering a header) and >> doing more tests, so it may take me a bit more of time. > > I got serial working, unfortunately I discovered many problems with > wireless card support. > 1) ssb believes there isn't cardbus > 2) ssb can't detect PCI is working in hostmode > 3) forcing hostmode causes reboots during PCI init > 4) fixing PCI init causes crash during first MMIO access > > That means a lot of problems, pretty hard to track & understand & fix. > This simply wouldn't be possible to handle this device without having > a physical access to it. It shares some bugs with WRT350N v1 which > unresolved for more than 2 years: > https://dev.openwrt.org/ticket/12682#comment:11 > > So far I only sent generic support for detecting WRT300N v1.0: > http://patchwork.linux-mips.org/patch/9656/ > I'll try to get some PCI patches after this long weekend. WRT300N v1.0 is supported now. I did it even before CC release, hooray :) For few minutes of testing I got a nice 20-22 Mb/s transfer using b43 driver (it doesn't support 802.11n features, so 802.11g speeds are available only). -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH V4] b53: define registers available and needed on BCM5301X
They are also present on some BCM63xx switches. Signed-off-by: Rafał Miłecki --- V4: Fix description of B53_GMII_PORT_OVERRIDE_CTRL Use GMII_PO_* Fix description of B53_BRCM_HDR --- .../generic/files/drivers/net/phy/b53/b53_regs.h | 33 ++ 1 file changed, 33 insertions(+) diff --git a/target/linux/generic/files/drivers/net/phy/b53/b53_regs.h b/target/linux/generic/files/drivers/net/phy/b53/b53_regs.h index 4899cc4..7e50bb4 100644 --- a/target/linux/generic/files/drivers/net/phy/b53/b53_regs.h +++ b/target/linux/generic/files/drivers/net/phy/b53/b53_regs.h @@ -50,6 +50,9 @@ /* Jumbo Frame Registers */ #define B53_JUMBO_PAGE 0x40 +/* CFP Configuration Registers Page */ +#define B53_CFP_PAGE 0xa1 + /* * Control Page registers */ @@ -99,6 +102,25 @@ #define B53_MC_FLOOD_MASK 0x34 #define B53_IPMC_FLOOD_MASK0x36 +/* + * Override Ports 0-7 State on devices with xMII interfaces (8 bit) + * + * For port 8 still use B53_PORT_OVERRIDE_CTRL + * Please note that not all ports are available on every hardware, e.g. BCM5301X + * don't include overriding port 6, BCM63xx also have some limitations. + */ +#define B53_GMII_PORT_OVERRIDE_CTRL(i) (0x58 + i) +#define GMII_PO_LINK BIT(0) +#define GMII_PO_FULL_DUPLEX BIT(1) /* 0 = Half Duplex */ +#define GMII_PO_SPEED_S 2 +#define GMII_PO_SPEED_10M(0 << GMII_PO_SPEED_S) +#define GMII_PO_SPEED_100M (1 << GMII_PO_SPEED_S) +#define GMII_PO_SPEED_1000M (2 << GMII_PO_SPEED_S) +#define GMII_PO_RX_FLOW BIT(4) +#define GMII_PO_TX_FLOW BIT(5) +#define GMII_PO_EN BIT(6) /* Use the register contents */ +#define GMII_PO_SPEED_2000M BIT(7) /* BCM5301X only, requires setting 1000M */ + /* Software reset register (8 bit) */ #define B53_SOFTRESET 0x79 @@ -156,6 +178,10 @@ #define GC_FRM_MGMT_PORT_04 0x00 #define GC_FRM_MGMT_PORT_MII 0x80 +/* Broadcom Header control register (8 bit) */ +#define B53_BRCM_HDR 0x03 +#define BRCM_HDR_EN BIT(0) /* Enable tagging on IMP port */ + /* Device ID register (8 or 32 bit) */ #define B53_DEVICE_ID 0x30 @@ -310,4 +336,11 @@ #define JMS_MIN_SIZE 1518 #define JMS_MAX_SIZE 9724 +/* + * CFP Configuration Page Registers + */ + +/* CFP Control Register with ports map (8 bit) */ +#define B53_CFP_CTRL 0x00 + #endif /* !__B53_REGS_H */ -- 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] [PATCH V3] b53: define registers available and needed on BCM5301X
On 30 March 2015 at 22:43, Jonas Gorski wrote: > On Wed, Mar 18, 2015 at 8:48 PM, Rafał Miłecki wrote: >> They are also present on some BCM63xx switches. >> >> Signed-off-by: Rafał Miłecki >> --- >> .../generic/files/drivers/net/phy/b53/b53_regs.h | 32 >> ++ >> 1 file changed, 32 insertions(+) >> >> diff --git a/target/linux/generic/files/drivers/net/phy/b53/b53_regs.h >> b/target/linux/generic/files/drivers/net/phy/b53/b53_regs.h >> index 4899cc4..a4db1f1 100644 >> --- a/target/linux/generic/files/drivers/net/phy/b53/b53_regs.h >> +++ b/target/linux/generic/files/drivers/net/phy/b53/b53_regs.h >> @@ -50,6 +50,9 @@ >> /* Jumbo Frame Registers */ >> #define B53_JUMBO_PAGE 0x40 >> >> +/* CFP Configuration Registers Page */ >> +#define B53_CFP_PAGE 0xa1 > > How big is this page? What are its valid fields? I don't know, obviously. Is this a real problem? :| It didn't stop you from defining e.g. B53_QOS_PAGE and may bits. Let's just document registers we know/can. >> + >> /* >> * Control Page registers >> */ >> @@ -99,6 +102,24 @@ >> #define B53_MC_FLOOD_MASK 0x34 >> #define B53_IPMC_FLOOD_MASK0x36 >> >> +/* >> + * Overriding ports 0-7 on devices with xMII interfaces (8 bit) > > I suggest adding a blank line here in the comment to separate name and > detailed explanation. Also let's call it "Override Port State > Register" or so. "Overriding ports" sounds like you could change the > port numbering or so. > >> + * For port 8 still use B53_PORT_OVERRIDE_CTRL >> + * Please note that not all ports are available on every hardware, e.g. >> BCM5301X >> + * don't include overriding port 6, BCM63xx also have some limitations. >> + */ >> +#define B53_GMII_PORT_OVERRIDE_CTRL(i) (0x58 + i) >> +#define GMII_PORT_OVERRIDE_LINK BIT(0) >> +#define GMII_PORT_OVERRIDE_FULL_DUPLEX BIT(1) /* 0 = Half Duplex */ >> +#define GMII_PORT_OVERRIDE_SPEED_S 2 >> +#define GMII_PORT_OVERRIDE_SPEED_10M (0 << PORT_OVERRIDE_SPEED_S) >> +#define GMII_PORT_OVERRIDE_SPEED_100M(1 << >> PORT_OVERRIDE_SPEED_S) >> +#define GMII_PORT_OVERRIDE_SPEED_1000M (2 << PORT_OVERRIDE_SPEED_S) >> +#define GMII_PORT_OVERRIDE_RX_FLOW BIT(4) >> +#define GMII_PORT_OVERRIDE_TX_FLOW BIT(5) >> +#define GMII_PORT_OVERRIDE_ENBIT(6) /* Use the >> register contents */ >> +#define GMII_PORT_OVERRIDE_SPEED_2000M BIT(7) /* BCM5301X only, >> requires setting 1000M */ > > Can we shorten these names a bit? Broadcom calls them GMII_PO_*, which > I think is an acceptable abbreviation. I was just trying to follow B53_PORT_OVERRIDE_CTRL, but I like GMII_PO_* too. -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] I'd like to donate a Linksys WRT300N V1
On 6 April 2015 at 08:32, Alex Henrie wrote: > 2015-04-04 17:01 GMT-06:00 Rafał Miłecki : >> I got serial working, unfortunately I discovered many problems with >> wireless card support. >> 1) ssb believes there isn't cardbus >> 2) ssb can't detect PCI is working in hostmode >> 3) forcing hostmode causes reboots during PCI init >> 4) fixing PCI init causes crash during first MMIO access >> >> That means a lot of problems, pretty hard to track & understand & fix. >> This simply wouldn't be possible to handle this device without having >> a physical access to it. It shares some bugs with WRT350N v1 which >> unresolved for more than 2 years: >> https://dev.openwrt.org/ticket/12682#comment:11 >> >> So far I only sent generic support for detecting WRT300N v1.0: >> http://patchwork.linux-mips.org/patch/9656/ >> I'll try to get some PCI patches after this long weekend. > > Would it help you to have a WRT350N v1 to experiment with too? I'm > pretty happy to donate arbitrary hardware to OpenWrt developers. No, thank you, I'm fine with WRT300N v1.0, as it has more problems than WRT350N v1. Resolving all problems with WRT300N v1.0 should make WRT350N v1 supported at the same time. -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] I'd like to donate a Linksys WRT300N V1
On 30 March 2015 at 23:43, Rafał Miłecki wrote: > On 17 March 2015 at 22:05, Alex Henrie wrote: >> I just mailed the router. When it arrives, please send confirmation to >> me and to treasu...@spi-inc.org. > > I just got it today, thanks! > > I disassembled it, it's really a PCMCIA wireless card, nice :) Quite > an unique device! Well, it isn't that simple. It's actually CardBus, which is much closer to PCI rather than what I meant by PCMCIA. > I'll have to install serial console (requires soldering a header) and > doing more tests, so it may take me a bit more of time. I got serial working, unfortunately I discovered many problems with wireless card support. 1) ssb believes there isn't cardbus 2) ssb can't detect PCI is working in hostmode 3) forcing hostmode causes reboots during PCI init 4) fixing PCI init causes crash during first MMIO access That means a lot of problems, pretty hard to track & understand & fix. This simply wouldn't be possible to handle this device without having a physical access to it. It shares some bugs with WRT350N v1 which unresolved for more than 2 years: https://dev.openwrt.org/ticket/12682#comment:11 So far I only sent generic support for detecting WRT300N v1.0: http://patchwork.linux-mips.org/patch/9656/ I'll try to get some PCI patches after this long weekend. -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/6] bcm53xx: update sprom from nvram to handle rev 11
On 10 March 2015 at 04:30, Ian Kent wrote:
> +@@ -93,6 +113,9 @@ struct ssb_sprom {
> + u16 boardflags2_lo; /* Board flags (bits 32-47) */
> + u16 boardflags2_hi; /* Board flags (bits 48-63) */
> + /* TODO store board flags in a single u64 */
> ++ /* spromrev 11 */
> ++ u16 boardflags3_lo; /* Board flags (bits 64-79) */
> ++ u16 boardflags3_hi; /* Board flags (bits 80-95) */
Please, please, use u32 boardflags3. We already suffer from split
boardflags(1) and boardflags2 too much ;)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/6] bcm53xx: update sprom from nvram to handle rev 11
On 2 April 2015 at 11:03, Ian Kent wrote:
> On Thu, 2015-04-02 at 10:22 +0200, Rafał Miłecki wrote:
>> Other than that, current way of handling revisions is quite messy, I
>> guess you noticed it by yourself. I started reworking, see:
>> http://patchwork.linux-mips.org/patch/9659/
>> Again, my change if for upstream driver.
>
> I've noticed a couple of changes you've submitted.
>
> I must admit they are interesting but not what I would have come up
> with. I guess it's my lack of experience with the code, but that'll come
> in time.
That's expected. When you look at driver for the first time, it's hard
to have a nice idea for redesigning it. Unless it's a real crap :P
>> So my idea to resolve this situation is to:
>> 1) sync bcm53xx SPROM driver with mainline one, let it differ only
>> with DT specific code
>> 2) keep submitting SPROM changes to the mainline driver and just
>> backport them to bcm53xx
>> 3) clear bcm47xx's sprom.c and work on moving it to the
>> drivers/firmware/broadcom/
>
> OK, just to clarify, your recommending the canonical source is the
> current bcm47xx and the goal is to make that generic and move it to a
> common location in the source tree.
>
> So I should familiarize myself with that source too.
You got me correct.. This is the same trick I did with bcm53xx NVRAM
driver. Some time ago it was also quite different from the bcm47xx
one. So I modified bcm47xx nvram.c (by sending upstream patches) to
make is usable by bcm53xx and then backported it to bcm53xx. Now the
drivers are identical according to my knowledge.
Few minutes ago I've updated bcm53xx SPROM driver to be based on bcm47xx's one:
https://dev.openwrt.org/changeset/45230/
so we are already doing pretty well with unifying them.
You can now work with bcm53xx's variation of SPROM driver and easily
port changes to the bcm47xx's sprom.c
>> > ++ entry_count = ARRAY_SIZE(gains_info->rxgains5gmelnagaina);
>> > ++ for (j = 0; j < entry_count; j++) {
>> > ++ snprintf(postfix, sizeof(postfix), "%i", j);
>> > ++ snprintf(tmp, sizeof(tmp), "%i:%s", i,
>> > "rxgains5gmelnagaina");
>> > ++ nvram_read_u8(fill, postfix, tmp,
>> > ++&gains_info->rxgains5gmelnagaina[j],
>> > 0);
>> > ++ }
>>
>> You shouldn't let unexpected NVRAM content crash your driver. Don't
>> trust the entry_count, verify it with your array size.
>
> Umm ... don't have my patch handy and don't quite follow.
Just ignore my silly comment, my brain got some memory corruption :|
--
Rafał
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 4/6] bcm53xx: increase nvram allocation size to 64k
On 2 April 2015 at 11:57, Ian Kent wrote:
> On Thu, 2015-04-02 at 17:47 +0800, Ian Kent wrote:
>> On Thu, 2015-04-02 at 09:45 +0200, Rafał Miłecki wrote:
>> > On 10 March 2015 at 04:30, Ian Kent wrote:
>> > > The R8000 nvram is larger than 32k, increase nvram allocation to
>> > > 64k to accomadate.
>> >
>> > I handled this by sending nvram.c patch for mainline:
>> > http://patchwork.linux-mips.org/patch/9651/
>> > And backporting all changes to bcm53xx:
>> > https://dev.openwrt.org/changeset/45204/
>>
>> OK, help me out with this patch.
>>
>> I thought it was necessary to calculate a from starting offset based on
>> mtd size and nvram size since the code assumes the nvram partition might
>> not start at 0 whereas in the patch it looks like a 0 starting offset is
>> assumed?
>>
>> When I was working on this area of code, IIRC, the from offset was
>> actually not 0.
>
> Mmm .. so that's probably wrong since ...
>
> mtd = get_mtd_device_nm("nvram");
>
> Should get us the start of the nvram partition at offset 0.
That's right, if something doesn't work for you, let me know.
--
Rafał
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/6] bcm53xx: update sprom from nvram to handle rev 11
Hi Ian,
On 10 March 2015 at 04:30, Ian Kent wrote:
> Add new sprom revision 11 variables to the nvram -> sprom reader.
>
> Signed-off-by: Ian Kent
There are few problems with bcm53xx's SPROM and I've few comments to your patch.
bcm53xx's SPROM driver is modified version of mainline
arch/mips/bcm74xx/sprom.c. It already differs a bit, but we can still
see the differences and try to mainline them. By adding more changes
to it we'll get lost and upsteaming changes will become more complex.
Other than that, current way of handling revisions is quite messy, I
guess you noticed it by yourself. I started reworking, see:
http://patchwork.linux-mips.org/patch/9659/
Again, my change if for upstream driver.
Also your changes to struct ssb_sprom may get complex to maintain, I
believe you should try to upstream them.
So my idea to resolve this situation is to:
1) sync bcm53xx SPROM driver with mainline one, let it differ only
with DT specific code
2) keep submitting SPROM changes to the mainline driver and just
backport them to bcm53xx
3) clear bcm47xx's sprom.c and work on moving it to the
drivers/firmware/broadcom/
I'm really happy you worked on SPROM rev 11 properties, it would be
great to get them as a patch for the bcm47xx's driver.
> ++ entry_count = ARRAY_SIZE(gains_info->rxgains5gmelnagaina);
> ++ for (j = 0; j < entry_count; j++) {
> ++ snprintf(postfix, sizeof(postfix), "%i", j);
> ++ snprintf(tmp, sizeof(tmp), "%i:%s", i,
> "rxgains5gmelnagaina");
> ++ nvram_read_u8(fill, postfix, tmp,
> ++&gains_info->rxgains5gmelnagaina[j], 0);
> ++ }
You shouldn't let unexpected NVRAM content crash your driver. Don't
trust the entry_count, verify it with your array size.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 4/6] bcm53xx: increase nvram allocation size to 64k
On 10 March 2015 at 04:30, Ian Kent wrote: > The R8000 nvram is larger than 32k, increase nvram allocation to > 64k to accomadate. I handled this by sending nvram.c patch for mainline: http://patchwork.linux-mips.org/patch/9651/ And backporting all changes to bcm53xx: https://dev.openwrt.org/changeset/45204/ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] reply： System halted on bcm4708 series board when booting openwrt trunk(kernel 3.14)
Please STOP sending HTML e-mails. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] I'd like to donate a Linksys WRT300N V1
On 17 March 2015 at 22:05, Alex Henrie wrote: > I just mailed the router. When it arrives, please send confirmation to > me and to treasu...@spi-inc.org. I just got it today, thanks! I disassembled it, it's really a PCMCIA wireless card, nice :) Quite an unique device! I had some problems installing OpenWrt, not sure what they were caused by. Ppl trying to install original firmware seemed to had these issues too, so they may be not related to OpenWrt firmware only. I got it as well for the original firmware, however after a reboot is suddenly succeeded. So I decided to install some older OpenWrt as I suspected it may be related to flash size. 12.09 was rejected, so I tried 10.03.1. It got accepted but I think it doesn't boot and I've soft bricked this router. I'll have to install serial console (requires soldering a header) and doing more tests, so it may take me a bit more of time. Anyway, I'm happy to have this device for experiments, thanks! -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH RFC] brcm47xx: image: use standard KERNEL_IMAGE to avoid warnings
KERNEL_IMAGE is used as target rule so reusing the same name causes: Makefile:326: warning: overriding recipe for target `bin/brcm47xx/vmlinux.lzma' Makefile:326: warning: ignoring old recipe for target `bin/brcm47xx/vmlinux.lzma' Makefile:326: warning: overriding recipe for target `build_dir/target-mipsel_74kc+dsp2_uClibc-0.9.33.2/linux-brcm47xx_mips74k/vmlinux.lzma' Makefile:326: warning: ignoring old recipe for target `build_dir/target-mipsel_74kc+dsp2_uClibc-0.9.33.2/linux-brcm47xx_mips74k/vmlinux.lzma' Unfortunately this will cause copying vmlinux.lzma over and over like: cp vmlinux.lzma FOO-kernel.bin which is redundant on brcm47xx where we never modify kernel image. Signed-off-by: Rafał Miłecki --- With this fix using new image building system adds another overhead because 99% of devices should share both: kernel (vmlinux.lzma) and TRX. I'm wondering if using new image building system in its current form makes any sense for this simple MIPS target. The gain from building images in parellel may be lost due to re-generating simple files. --- target/linux/brcm47xx/image/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/target/linux/brcm47xx/image/Makefile b/target/linux/brcm47xx/image/Makefile index 5410ed3..b46ab7b 100644 --- a/target/linux/brcm47xx/image/Makefile +++ b/target/linux/brcm47xx/image/Makefile @@ -138,8 +138,9 @@ DEVICE_VARS += DEVICE_ID VERSION DEVICE_VARS += BOARD_ID REGION define Device/Default + KERNEL := kernel-bin IMAGE_NAME = $$(IMAGE_PREFIX)-$$(1).$$(2) - KERNEL_IMAGE = vmlinux.lzma + KERNEL_NAME = vmlinux.lzma FILESYSTEMS := $(FS_64K) IMAGES := trx IMAGE/trx := trx-with-loader -- 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] [PATCH 1/2] ralink: add FireWRT power button
On 21 March 2015 at 23:18, John Crispin wrote:
>
>
> On 21/03/2015 23:15, Rafał Miłecki wrote:
>> On 21 March 2015 at 06:06, wengbj wrote:
>>> Signed-off-by: wengbj
>>> ---
>>> target/linux/ramips/dts/FIREWRT.dts |5 +
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/target/linux/ramips/dts/FIREWRT.dts
>>> b/target/linux/ramips/dts/FIREWRT.dts
>>> index 54f0e55..2b018e6 100644
>>> --- a/target/linux/ramips/dts/FIREWRT.dts
>>> +++ b/target/linux/ramips/dts/FIREWRT.dts
>>> @@ -103,6 +103,11 @@
>>> gpios = <&gpio0 18 1>;
>>> linux,code = <0x211>;
>>> };
>>> + power {
>>> + label = "power";
>>> + gpios = <&gpio0 23 1>;
>>> + linux,code = <116>;
>>> + };
>>
>> Could you break this bad habit and use KEY_* instead of magic numbers?
>> Like a KEY_POWER.
>>
>
> sure but this is out of scope of this patch and needs to be done
> globally for all dts files in the ralink target.
I don't mean changing any existing entry, just the one that was
suggested to be added.
I think it's OK to add it in a correct & nice form?
--
Rafał
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/2] ralink: add FireWRT power button
On 21 March 2015 at 06:06, wengbj wrote:
> Signed-off-by: wengbj
> ---
> target/linux/ramips/dts/FIREWRT.dts |5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/target/linux/ramips/dts/FIREWRT.dts
> b/target/linux/ramips/dts/FIREWRT.dts
> index 54f0e55..2b018e6 100644
> --- a/target/linux/ramips/dts/FIREWRT.dts
> +++ b/target/linux/ramips/dts/FIREWRT.dts
> @@ -103,6 +103,11 @@
> gpios = <&gpio0 18 1>;
> linux,code = <0x211>;
> };
> + power {
> + label = "power";
> + gpios = <&gpio0 23 1>;
> + linux,code = <116>;
> + };
Could you break this bad habit and use KEY_* instead of magic numbers?
Like a KEY_POWER.
--
Rafał
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH V3] b53: define registers available and needed on BCM5301X
They are also present on some BCM63xx switches. Signed-off-by: Rafał Miłecki --- .../generic/files/drivers/net/phy/b53/b53_regs.h | 32 ++ 1 file changed, 32 insertions(+) diff --git a/target/linux/generic/files/drivers/net/phy/b53/b53_regs.h b/target/linux/generic/files/drivers/net/phy/b53/b53_regs.h index 4899cc4..a4db1f1 100644 --- a/target/linux/generic/files/drivers/net/phy/b53/b53_regs.h +++ b/target/linux/generic/files/drivers/net/phy/b53/b53_regs.h @@ -50,6 +50,9 @@ /* Jumbo Frame Registers */ #define B53_JUMBO_PAGE 0x40 +/* CFP Configuration Registers Page */ +#define B53_CFP_PAGE 0xa1 + /* * Control Page registers */ @@ -99,6 +102,24 @@ #define B53_MC_FLOOD_MASK 0x34 #define B53_IPMC_FLOOD_MASK0x36 +/* + * Overriding ports 0-7 on devices with xMII interfaces (8 bit) + * For port 8 still use B53_PORT_OVERRIDE_CTRL + * Please note that not all ports are available on every hardware, e.g. BCM5301X + * don't include overriding port 6, BCM63xx also have some limitations. + */ +#define B53_GMII_PORT_OVERRIDE_CTRL(i) (0x58 + i) +#define GMII_PORT_OVERRIDE_LINK BIT(0) +#define GMII_PORT_OVERRIDE_FULL_DUPLEX BIT(1) /* 0 = Half Duplex */ +#define GMII_PORT_OVERRIDE_SPEED_S 2 +#define GMII_PORT_OVERRIDE_SPEED_10M (0 << PORT_OVERRIDE_SPEED_S) +#define GMII_PORT_OVERRIDE_SPEED_100M(1 << PORT_OVERRIDE_SPEED_S) +#define GMII_PORT_OVERRIDE_SPEED_1000M (2 << PORT_OVERRIDE_SPEED_S) +#define GMII_PORT_OVERRIDE_RX_FLOW BIT(4) +#define GMII_PORT_OVERRIDE_TX_FLOW BIT(5) +#define GMII_PORT_OVERRIDE_ENBIT(6) /* Use the register contents */ +#define GMII_PORT_OVERRIDE_SPEED_2000M BIT(7) /* BCM5301X only, requires setting 1000M */ + /* Software reset register (8 bit) */ #define B53_SOFTRESET 0x79 @@ -156,6 +177,10 @@ #define GC_FRM_MGMT_PORT_04 0x00 #define GC_FRM_MGMT_PORT_MII 0x80 +/* Enable BCM_HDR Tag on IMP port (8 bit) */ +#define B53_BRCM_HDR 0x03 +#define BRCM_HDR_EN BIT(0) + /* Device ID register (8 or 32 bit) */ #define B53_DEVICE_ID 0x30 @@ -310,4 +335,11 @@ #define JMS_MIN_SIZE 1518 #define JMS_MAX_SIZE 9724 +/* + * CFP Configuration Page Registers + */ + +/* CFP Control Register with ports map (8 bit) */ +#define B53_CFP_CTRL 0x00 + #endif /* !__B53_REGS_H */ -- 1.8.4.5 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH V2] b53: define registers available and needed on BCM5301X
They are also present on some BCM63xx switches. Signed-off-by: Rafał Miłecki --- .../generic/files/drivers/net/phy/b53/b53_regs.h | 27 ++ 1 file changed, 27 insertions(+) diff --git a/target/linux/generic/files/drivers/net/phy/b53/b53_regs.h b/target/linux/generic/files/drivers/net/phy/b53/b53_regs.h index 4899cc4..a393cfa 100644 --- a/target/linux/generic/files/drivers/net/phy/b53/b53_regs.h +++ b/target/linux/generic/files/drivers/net/phy/b53/b53_regs.h @@ -50,6 +50,9 @@ /* Jumbo Frame Registers */ #define B53_JUMBO_PAGE 0x40 +/* CFP Configuration Registers Page */ +#define B53_CFP_PAGE 0xa1 + /* * Control Page registers */ @@ -99,6 +102,20 @@ #define B53_MC_FLOOD_MASK 0x34 #define B53_IPMC_FLOOD_MASK0x36 +/* Overriding ports 0-5 and 7 on devices with xMII interfaces (8 bit) */ +/* For port 8 still use B53_PORT_OVERRIDE_CTRL */ +#define B53_GMII_PORT_OVERRIDE_CTRL(i) (0x58 + i) +#define GMII_PORT_OVERRIDE_LINK BIT(0) +#define GMII_PORT_OVERRIDE_FULL_DUPLEX BIT(1) /* 0 = Half Duplex */ +#define GMII_PORT_OVERRIDE_SPEED_S 2 +#define GMII_PORT_OVERRIDE_SPEED_10M (0 << PORT_OVERRIDE_SPEED_S) +#define GMII_PORT_OVERRIDE_SPEED_100M(1 << PORT_OVERRIDE_SPEED_S) +#define GMII_PORT_OVERRIDE_SPEED_1000M (2 << PORT_OVERRIDE_SPEED_S) +#define GMII_PORT_OVERRIDE_RX_FLOW BIT(4) +#define GMII_PORT_OVERRIDE_TX_FLOW BIT(5) +#define GMII_PORT_OVERRIDE_ENBIT(6) /* Use the register contents */ +#define GMII_PORT_OVERRIDE_SPEED_2000M BIT(7) /* BCM5301X only, requires setting 1000M */ + /* Software reset register (8 bit) */ #define B53_SOFTRESET 0x79 @@ -156,6 +173,9 @@ #define GC_FRM_MGMT_PORT_04 0x00 #define GC_FRM_MGMT_PORT_MII 0x80 +#define B53_BRCM_HDR 0x03 +#define BRCM_HDR_EN BIT(0) + /* Device ID register (8 or 32 bit) */ #define B53_DEVICE_ID 0x30 @@ -310,4 +330,11 @@ #define JMS_MIN_SIZE 1518 #define JMS_MAX_SIZE 9724 +/* + * CFP Configuration Page Registers + */ + +/* CFP Control Register with ports map (8 bit) */ +#define B53_CFP_CTRL 0x00 + #endif /* !__B53_REGS_H */ -- 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] [PATCH] b53: fix overriding port 8 state (if it is connected to CPU)
On 18 March 2015 at 11:28, Jonas Gorski wrote:
> On Wed, Mar 18, 2015 at 10:02 AM, Rafał Miłecki wrote:
>> Signed-off-by: Rafał Miłecki
>> ---
>> .../generic/files/drivers/net/phy/b53/b53_common.c | 23
>> +-
>> .../generic/files/drivers/net/phy/b53/b53_regs.h | 1 +
>> 2 files changed, 23 insertions(+), 1 deletion(-)
>>
>> diff --git a/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
>> b/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
>> index e44d194..4597742 100644
>> --- a/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
>> +++ b/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
>> @@ -525,7 +525,7 @@ static int b53_switch_reset(struct b53_device *dev)
>> return -EINVAL;
>> }
>> }
>> - } else if ((is531x5(dev) || is5301x(dev)) && dev->sw_dev.cpu_port ==
>> B53_CPU_PORT) {
>> + } else if (is531x5(dev) && dev->sw_dev.cpu_port == B53_CPU_PORT) {
>> u8 mii_port_override;
>>
>> b53_read8(dev, B53_CTRL_PAGE, B53_PORT_OVERRIDE_CTRL,
>> @@ -533,6 +533,27 @@ static int b53_switch_reset(struct b53_device *dev)
>> b53_write8(dev, B53_CTRL_PAGE, B53_PORT_OVERRIDE_CTRL,
>>mii_port_override | PORT_OVERRIDE_EN |
>>PORT_OVERRIDE_LINK);
>> + } else if (is5301x(dev)) {
>> + /*
>> +* CPU interface attached to port 8 requires specific
>> handling.
>> +* It uses different overriding register and extra ports 5
>> and 7
>> +* need to be configured as well.
>> +*/
>> + if (dev->sw_dev.cpu_port == 8) {
>> + u8 mii_port_override;
>> +
>> + b53_read8(dev, B53_CTRL_PAGE, B53_PORT_OVERRIDE_CTRL,
>> + &mii_port_override);
>> + mii_port_override |= PORT_OVERRIDE_LINK |
>> +PORT_OVERRIDE_RX_FLOW |
>> +PORT_OVERRIDE_TX_FLOW |
>> +PORT_OVERRIDE_SPEED_2000M |
>> +PORT_OVERRIDE_EN;
>> + b53_write8(dev, B53_CTRL_PAGE,
>> B53_PORT_OVERRIDE_CTRL,
>> + mii_port_override);
>> + } else {
>> + pr_warn("overriding CPU port other than 8 is not
>> supported yet\n");
>> + }
>> }
>>
>> b53_enable_mib(dev);
>
> How about
>
> @@ -530,9 +530,16 @@ static int b53_switch_reset(struct b53_device *dev)
>
> b53_read8(dev, B53_CTRL_PAGE, B53_PORT_OVERRIDE_CTRL,
> &mii_port_override);
> +
> + mii_port_override |= PORT_OVERRIDE_LINK | PORT_OVERRIDE_EN;
> +
> + if (is5301x(dev))
> + mii_port_override |= PORT_OVERRIDE_RX_FLOW |
> +PORT_OVERRIDE_TX_FLOW |
> +PORT_OVERRIDE_SPEED_2000M;
> +
> b53_write8(dev, B53_CTRL_PAGE, B53_PORT_OVERRIDE_CTRL,
> - mii_port_override | PORT_OVERRIDE_EN |
> - PORT_OVERRIDE_LINK);
> + mii_port_override);
> }
>
> b53_enable_mib(dev);
>
> instead of creating a full new branch?
As the comment says, this code for BCM5301X will be extended. This is
because of this 2000M speed, which requires configuring 3 ports. It
seems communication between switch and CPU interface with such speed
couldn't be handled with only a single port. Broadcom decided to use 3
ports in total for that.
I don't have that code ready and I also don't like patch bombs, so I
started with this simple change. However because of further
development plans I vote for a separated branch.
--
Rafał
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] b53: fix overriding port 8 state (if it is connected to CPU)
Signed-off-by: Rafał Miłecki
---
.../generic/files/drivers/net/phy/b53/b53_common.c | 23 +-
.../generic/files/drivers/net/phy/b53/b53_regs.h | 1 +
2 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
b/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
index e44d194..4597742 100644
--- a/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
+++ b/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
@@ -525,7 +525,7 @@ static int b53_switch_reset(struct b53_device *dev)
return -EINVAL;
}
}
- } else if ((is531x5(dev) || is5301x(dev)) && dev->sw_dev.cpu_port ==
B53_CPU_PORT) {
+ } else if (is531x5(dev) && dev->sw_dev.cpu_port == B53_CPU_PORT) {
u8 mii_port_override;
b53_read8(dev, B53_CTRL_PAGE, B53_PORT_OVERRIDE_CTRL,
@@ -533,6 +533,27 @@ static int b53_switch_reset(struct b53_device *dev)
b53_write8(dev, B53_CTRL_PAGE, B53_PORT_OVERRIDE_CTRL,
mii_port_override | PORT_OVERRIDE_EN |
PORT_OVERRIDE_LINK);
+ } else if (is5301x(dev)) {
+ /*
+* CPU interface attached to port 8 requires specific handling.
+* It uses different overriding register and extra ports 5 and 7
+* need to be configured as well.
+*/
+ if (dev->sw_dev.cpu_port == 8) {
+ u8 mii_port_override;
+
+ b53_read8(dev, B53_CTRL_PAGE, B53_PORT_OVERRIDE_CTRL,
+ &mii_port_override);
+ mii_port_override |= PORT_OVERRIDE_LINK |
+PORT_OVERRIDE_RX_FLOW |
+PORT_OVERRIDE_TX_FLOW |
+PORT_OVERRIDE_SPEED_2000M |
+PORT_OVERRIDE_EN;
+ b53_write8(dev, B53_CTRL_PAGE, B53_PORT_OVERRIDE_CTRL,
+ mii_port_override);
+ } else {
+ pr_warn("overriding CPU port other than 8 is not
supported yet\n");
+ }
}
b53_enable_mib(dev);
diff --git a/target/linux/generic/files/drivers/net/phy/b53/b53_regs.h
b/target/linux/generic/files/drivers/net/phy/b53/b53_regs.h
index 6d71493..129946d 100644
--- a/target/linux/generic/files/drivers/net/phy/b53/b53_regs.h
+++ b/target/linux/generic/files/drivers/net/phy/b53/b53_regs.h
@@ -86,6 +86,7 @@
#define PORT_OVERRIDE_RV_MII_25 BIT(4) /* BCM5325 only */
#define PORT_OVERRIDE_RX_FLOWBIT(4)
#define PORT_OVERRIDE_TX_FLOWBIT(5)
+#define PORT_OVERRIDE_SPEED_2000MBIT(6) /* BCM5301X only, requires
setting 1000M */
#define PORT_OVERRIDE_EN BIT(7) /* Use the register contents */
/* Power-down mode control */
--
1.8.4.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] b53: define registers available and needed on BCM5301X
Signed-off-by: Rafał Miłecki --- .../generic/files/drivers/net/phy/b53/b53_regs.h | 26 ++ 1 file changed, 26 insertions(+) diff --git a/target/linux/generic/files/drivers/net/phy/b53/b53_regs.h b/target/linux/generic/files/drivers/net/phy/b53/b53_regs.h index 4899cc4..6d71493 100644 --- a/target/linux/generic/files/drivers/net/phy/b53/b53_regs.h +++ b/target/linux/generic/files/drivers/net/phy/b53/b53_regs.h @@ -50,6 +50,9 @@ /* Jumbo Frame Registers */ #define B53_JUMBO_PAGE 0x40 +/* CFP Configuration Registers Page */ +#define B53_CFP_PAGE 0xa1 + /* * Control Page registers */ @@ -99,6 +102,20 @@ #define B53_MC_FLOOD_MASK 0x34 #define B53_IPMC_FLOOD_MASK0x36 +/* On BCM5301X we can override ports 0-5 and 7 as well */ +/* For port 8 still use B53_PORT_OVERRIDE_CTRL */ +#define B53_GMII_PORT_OVERRIDE_CTRL(i) (0x58 + i) +#define GMII_PORT_OVERRIDE_LINK BIT(0) +#define GMII_PORT_OVERRIDE_FULL_DUPLEX BIT(1) /* 0 = Half Duplex */ +#define GMII_PORT_OVERRIDE_SPEED_S 2 +#define GMII_PORT_OVERRIDE_SPEED_10M (0 << PORT_OVERRIDE_SPEED_S) +#define GMII_PORT_OVERRIDE_SPEED_100M(1 << PORT_OVERRIDE_SPEED_S) +#define GMII_PORT_OVERRIDE_SPEED_1000M (2 << PORT_OVERRIDE_SPEED_S) +#define GMII_PORT_OVERRIDE_RX_FLOW BIT(4) +#define GMII_PORT_OVERRIDE_TX_FLOW BIT(5) +#define GMII_PORT_OVERRIDE_ENBIT(6) /* Use the register contents */ +#define GMII_PORT_OVERRIDE_SPEED_2000M BIT(7) /* Requires setting 1000M */ + /* Software reset register (8 bit) */ #define B53_SOFTRESET 0x79 @@ -156,6 +173,9 @@ #define GC_FRM_MGMT_PORT_04 0x00 #define GC_FRM_MGMT_PORT_MII 0x80 +#define B53_BRCM_HDR 0x03 +#define BRCM_HDR_EN BIT(0) + /* Device ID register (8 or 32 bit) */ #define B53_DEVICE_ID 0x30 @@ -310,4 +330,10 @@ #define JMS_MIN_SIZE 1518 #define JMS_MAX_SIZE 9724 +/* + * CFP Configuration Page Registers + */ + +#define B53_CFP_CTRL 0x00 + #endif /* !__B53_REGS_H */ -- 1.8.4.5 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] b53: reverse duplex bit meaning for IMP state override register
Signed-off-by: Rafał Miłecki --- When reading bcmrobo.c code for BCM5301X I've noticed that it uses REG_CTRL_MIIPO (0x0e) with a following comment: /* default(1 << 1) DUPLX_MODE: * Full Duplex */ So I guess our bit definition may be reversed. Can someone verify this? --- target/linux/generic/files/drivers/net/phy/b53/b53_regs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/generic/files/drivers/net/phy/b53/b53_regs.h b/target/linux/generic/files/drivers/net/phy/b53/b53_regs.h index ba50915..4899cc4 100644 --- a/target/linux/generic/files/drivers/net/phy/b53/b53_regs.h +++ b/target/linux/generic/files/drivers/net/phy/b53/b53_regs.h @@ -75,7 +75,7 @@ /* IMP Port state override register (8 bit) */ #define B53_PORT_OVERRIDE_CTRL 0x0e #define PORT_OVERRIDE_LINK BIT(0) -#define PORT_OVERRIDE_HALF_DUPLEXBIT(1) /* 0 = Full Duplex */ +#define PORT_OVERRIDE_FULL_DUPLEXBIT(1) /* 0 = Half Duplex */ #define PORT_OVERRIDE_SPEED_S2 #define PORT_OVERRIDE_SPEED_10M (0 << PORT_OVERRIDE_SPEED_S) #define PORT_OVERRIDE_SPEED_100M (1 << PORT_OVERRIDE_SPEED_S) -- 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] [PATCH] kernel: Support kernel options required by systemd
On 14 March 2015 at 00:35, Jeff Waugh wrote: > (John: This patch takes into account r44765, but moves the FHANDLE config > stanza to a more understandable position in the file.) If you want to put some comments in your patch, place them below the "---". This way they won't be visible after applying patch with "git am". > These are all likely to be widely useful in this modern age, but my interest > is > primarily in systemd support. :-) > > c.f. > http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-apps/systemd/systemd-.ebuild?&view=markup#l118 > > Adapted from a patch by Adam Porter. > > Signed-off-by: Jeff Waugh > --- Right here. -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] I'd like to donate a Linksys WRT300N V1
On 13 March 2015 at 07:38, Alex Henrie wrote: > I have a spare Linksys WRT300N V1, and according to the wiki, OpenWrt > does not yet fully support it: > > http://wiki.openwrt.org/toh/linksys/wrt300n1 > http://wiki.openwrt.org/toh/linksys/wrt300n > > I would be happy to mail this router to anyone who is willing to work > on support for it. Thanks for your hard work! Hi Alex, I work on both Broadcom targets, brcm47xx and bcm53xx: http://git.openwrt.org/?p=openwrt.git&a=search&h=HEAD&st=author&s=rmilecki (History goes back to September only, previously Hauke was accepting my patches) I'm actually quite missing some SSB based router, would be nice to have one. So far I didn't ever test OpenWrt on one of these older devices. If the shipping cost will be sane for you, I'd be happy to get this device. -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH][RFT] mpc52xx: switch kernel to 3.18
On 1 March 2015 at 00:05, Rafał Miłecki wrote: > Signed-off-by: Rafał Miłecki > --- > Gabor: I can see you were bumping mpc52xx kernel in the past. Could you > try 3.18? Ping? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/6] bcm53xx: changes for R8000 so far
On 10 March 2015 at 12:29, Jonas Gorski wrote: > On Tue, Mar 10, 2015 at 4:30 AM, Ian Kent wrote: >> [OpenWrt-Devel] [PATCH 0/6] bcm53xx: changes for R8000 so far > > Ah, this is supposed to be the V2. > > Please version your patchsets when resubmitting, i.e. this would be > then [PATCH V2], and add a changelog to the individual patches (under > the tear line, so it won't land in the actual commit message when > accepted). Right. Something like git format-patch --subject-prefix="PATCH V2" No need to do it this time, I'll recognize V2 on my own. -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] System halted on bcm4708 series board when booting openwrt trunk (kernel 3.14)
On 10 March 2015 at 04:43, Tymon wrote: > my cpu is BCM958522ER which is the same series with 4708 as well, 32MB > ###boot log: (I updated the xxx-squashfs.trx to the flash) > > Hit any key to stop autoboot: 0 > Checking TRX Image at addr 1e20 ... >Uncompressing ... Primary TRX image OK > kernel args : console=ttyS0,115200 ubi.mtd=5 root=ubi0:rootfs ro > rootflags=sync rootfstype=ubifs user_debug=31 > Booting from Primary Partition > kernel_args console=ttyS0,115200 ubi.mtd=5 root=ubi0:rootfs ro > rootflags=sync rootfstype=ubifs user_debug=31 > Start addr 8000 machid 127f Parmameter addr 0010 ... > > Starting kernel ... > Uncompressing Linux... > > XZ-compressed data is corrupt > > -- System halted > > I want to know why this error arise, any hints will be appreciated. My guess is that it's some problem caused by this board using U-Boot. It's the first time I hear about someone trying Broadcom ARM, U-Boot an OpenWrt. I guess U-Boot doesn't like our kernel. Our config uses CONFIG_KERNEL_XZ=y, but we also seem to be using lzma, see target/linux/bcm53xx/image/Makefile. You may want to check how original firmware (SDK, whatever) builds & prepares the kernel. -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/6] bcm53xx - changes for R8000 so far
On 9 March 2015 at 10:21, Rafał Miłecki wrote: > On 9 March 2015 at 10:08, Ian Kent wrote: >> Here are some changes done while working to get the R8000 working. >> Some are straight forward while some require review. > > Thanks :) > > One request: please use "bcm53xx: " prefix, as it's what we do since always. > > I'll try to reply to all patches as I find a moment. Please sign-off-by every single patch. -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/6] bcm53xx - fixup early device id 8012
On 9 March 2015 at 10:08, Ian Kent wrote: > Looks like the BCM53012 has a similar problem to the BCM53011. Change looks OK, however I'd prefer you to simply modify existing patch 170-pcie2-bcma-add-new-PCIe2-driver-for-bcma.patch It still wasn't included/accepted mainline, so it's safe to update it without loosing any changes when submitting it upstream. I also don't think there is much point in having a single-line 171 patch. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/6] bcm53xx - changes for R8000 so far
On 9 March 2015 at 10:08, Ian Kent wrote: > Here are some changes done while working to get the R8000 working. > Some are straight forward while some require review. Thanks :) One request: please use "bcm53xx: " prefix, as it's what we do since always. I'll try to reply to all patches as I find a moment. -- Rafał ___ 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] kernel: refined one of 514-yaffs-3.6-use-delayed-work-instead-of-write_super.patch
On 2 March 2015 at 06:11, ngc wrote: > Modified 514-yaffs-3.6-use-delayed-work-instead-of-write_super.patch > which was included old trunk, to fit the current trunk kernel. > This needs to support the behavior when yaffs_auto_checkpoint is set '2', > in 3.6.x and later. > > I got worked with linux-3.14.x on ARM. > > signed-off-by: n...@ff.iij4u.or.jp I can't review that YAFFS2 work, but I believe you can't sign your patch without using a real name. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH][RFT] adm5120: switch kernel to 3.18
On 1 March 2015 at 14:28, Jonas Gorski wrote: > On Sun, Mar 1, 2015 at 1:04 AM, Rafał Miłecki wrote: > > Depending on your definition of works, at least with a 16 MiB RAM device: > It boots, but eventually OOM's: http://pastebin.com/5kR99CMG > > Adding the low_mem feature makes it not OOM on boot, but still does > not leave much memory free: > http://pastebin.com/uKfnd2XB Thanks a lot! adm5120: enable low_mem https://dev.openwrt.org/changeset/44587/ adm5120: switch kernel to 3.18 https://dev.openwrt.org/changeset/44588/ -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH][RFT] adm5120: switch kernel to 3.18
Signed-off-by: Rafał Miłecki --- Gabor: I can see you were working on adm5120 in the past. Could you test this patch? --- target/linux/adm5120/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/adm5120/Makefile b/target/linux/adm5120/Makefile index e58122d..b966372 100644 --- a/target/linux/adm5120/Makefile +++ b/target/linux/adm5120/Makefile @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk BOARD:=adm5120 BOARDNAME:=Infineon/ADMtek ADM5120 -KERNEL_PATCHVER:=3.8 +KERNEL_PATCHVER:=3.18 SUBTARGETS:=router_le router_be rb1xx INITRAMFS_EXTRA_FILES:= -- 1.8.4.5 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH][RFT] mpc52xx: switch kernel to 3.18
Signed-off-by: Rafał Miłecki --- Gabor: I can see you were bumping mpc52xx kernel in the past. Could you try 3.18? --- target/linux/mpc52xx/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/mpc52xx/Makefile b/target/linux/mpc52xx/Makefile index aa3c5a7..29309ae 100644 --- a/target/linux/mpc52xx/Makefile +++ b/target/linux/mpc52xx/Makefile @@ -12,7 +12,7 @@ BOARDNAME:=Freescale MPC52xx CPU_TYPE:=603e FEATURES:=targz ext4 -KERNEL_PATCHVER:=3.8 +KERNEL_PATCHVER:=3.18 include $(INCLUDE_DIR)/target.mk -- 1.8.4.5 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH][RFT] ep93xx: switch kernel to 3.18
Signed-off-by: Rafał Miłecki --- target/linux/ep93xx/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/ep93xx/Makefile b/target/linux/ep93xx/Makefile index 7e7422b..3da7ca9 100644 --- a/target/linux/ep93xx/Makefile +++ b/target/linux/ep93xx/Makefile @@ -13,7 +13,7 @@ FEATURES:=squashfs ext4 targz usb display sound CPU_TYPE:=arm920t MAINTAINER:=Florian Fainelli -KERNEL_PATCHVER:=3.8 +KERNEL_PATCHVER:=3.18 DEVICE_TYPE:=developerboard -- 1.8.4.5 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH][RFT] omap: switch kernel to 3.18
Signed-off-by: Rafał Miłecki --- Hey guys, My previous request (posted half a year ago) was completely ignored: [PATCH][RFT] omap: switch kernel to 3.14 https://lists.openwrt.org/pipermail/openwrt-devel/2014-September/027845.html I'll really appreciate if someone can try this patch. 3.13 is really an old kernel and all OpenWrt targets dropped it already. I really hope we can do the same for omap and drop 3.13 from generic. --- target/linux/omap/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/omap/Makefile b/target/linux/omap/Makefile index 03a2c24..20f7517 100644 --- a/target/linux/omap/Makefile +++ b/target/linux/omap/Makefile @@ -13,7 +13,7 @@ FEATURES:=usb usbgadget ext4 targz fpu audio display nand ubifs CPU_TYPE:=cortex-a9 CPU_SUBTYPE:=vfpv3 -KERNEL_PATCHVER:=3.13 +KERNEL_PATCHVER:=3.18 MAINTAINER:=Imre Kaloz -- 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] [PATCH 3/3] b53: create slave devices for ports
On 26 February 2015 at 19:24, Florian Fainelli wrote: > On 25/02/15 07:24, Alexandru Ardelean wrote: >> Feature implemented and tested on BCM53128. >> >> Slave devices logic copied from the Linux kernel from Marvell's DSA >> driver ( linux/net/dsa/ ). >> Also the logic for the Broadcom tag processing has been copied from there. > > There are different efforts here going on, and I would like to at least > 3 different people (you, Rafal and myself) can converge to an identical > solution that fits everybody here. I agree. I think we should focus on getting this cleared and accepted upstream. I don't think I want to keep adding features like port interfaces to swconfig. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] generic: several linux-4.0 fixes
On 25 February 2015 at 11:00, Felix Fietkau wrote: > On 2015-02-25 06:07, Rafał Miłecki wrote: >> On 24 February 2015 at 16:29, Álvaro Fernández Rojas >> wrote: >>> --- a/target/linux/generic/files/drivers/net/phy/swconfig.c >>> +++ b/target/linux/generic/files/drivers/net/phy/swconfig.c >>> @@ -396,7 +396,12 @@ swconfig_dump_attr(struct swconfig_callback *cb, void >>> *arg) >>> op->description)) >>> goto nla_put_failure; >>> >>> +#if (LINUX_VERSION_CODE < KERNEL_VERSION(4,0,0)) >>> return genlmsg_end(msg, hdr); >>> +#else >>> + genlmsg_end(msg, hdr); >>> + return msg->len; >>> +#endif >>> nla_put_failure: >>> genlmsg_cancel(msg, hdr); >>> return -EMSGSIZE; >> >> I need some help there. Wasn't genlmsg_end always returning 0 value >> (before 4.0)? If so, should you do "return 0" instead of "return >> msg->len;"? Don't you just change the returning value on success? > As far as I can see, it was returning skb->len. Anyways, the #if needs > to go. It should just use the same code for >= 4.0 and < 4.0 > Also, this patch needs to be split up by functionality. Having > everything in one big patch is harder to review. I misread the commit: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=053c095a82cf773075e83d7233b5cc19a1f73ece You're both right. -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] generic: several linux-4.0 fixes
On 24 February 2015 at 16:29, Álvaro Fernández Rojas wrote: > --- a/target/linux/generic/files/drivers/net/phy/swconfig.c > +++ b/target/linux/generic/files/drivers/net/phy/swconfig.c > @@ -396,7 +396,12 @@ swconfig_dump_attr(struct swconfig_callback *cb, void > *arg) > op->description)) > goto nla_put_failure; > > +#if (LINUX_VERSION_CODE < KERNEL_VERSION(4,0,0)) > return genlmsg_end(msg, hdr); > +#else > + genlmsg_end(msg, hdr); > + return msg->len; > +#endif > nla_put_failure: > genlmsg_cancel(msg, hdr); > return -EMSGSIZE; I need some help there. Wasn't genlmsg_end always returning 0 value (before 4.0)? If so, should you do "return 0" instead of "return msg->len;"? Don't you just change the returning value on success? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] generic: several linux-4.0 fixes
On 24 February 2015 at 16:29, Álvaro Fernández Rojas wrote: > diff --git a/include/kernel.mk b/include/kernel.mk > index e21d53a..18cb133 100644 > --- a/include/kernel.mk > +++ b/include/kernel.mk > @@ -52,7 +52,11 @@ else >LINUX_SOURCE:=linux-$(LINUX_VERSION).tar.xz >TESTING:=$(if $(findstring -rc,$(LINUX_VERSION)),/testing,) >ifeq ($(call qstrip,$(CONFIG_EXTERNAL_KERNEL_TREE))$(call > qstrip,$(CONFIG_KERNEL_GIT_CLONE_URI)),) > +ifeq ($(word 1,$(subst ., ,$(KERNEL_BASE))),3) >LINUX_SITE:=@KERNEL/linux/kernel/v3.x$(TESTING) > +else > + LINUX_SITE:=@KERNEL/linux/kernel/v4.x$(TESTING) > +endif >endif > >ifneq ($(TARGET_BUILD),1) I don't want the same problem when switching to 5.0, we should use something generic. I've already sent [PATCH] kernel.mk: handle major version dynamically , will commit it later if noone will NACK it. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] kernel.mk: handle major version dynamically
We can't simply hardcode v3.x directory name. Signed-off-by: Rafał Miłecki --- include/kernel.mk | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/kernel.mk b/include/kernel.mk index e21d53a..eb3e07a 100644 --- a/include/kernel.mk +++ b/include/kernel.mk @@ -52,7 +52,8 @@ else LINUX_SOURCE:=linux-$(LINUX_VERSION).tar.xz TESTING:=$(if $(findstring -rc,$(LINUX_VERSION)),/testing,) ifeq ($(call qstrip,$(CONFIG_EXTERNAL_KERNEL_TREE))$(call qstrip,$(CONFIG_KERNEL_GIT_CLONE_URI)),) - LINUX_SITE:=@KERNEL/linux/kernel/v3.x$(TESTING) + VER_DIR:=v$(word 1,$(subst ., ,$(LINUX_VERSION))).x + LINUX_SITE:=@KERNEL/linux/kernel/$(VER_DIR)$(TESTING) endif ifneq ($(TARGET_BUILD),1) -- 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] [PATCH RFT] kernel: mtdsplit_uimage: debug buf/header sizes
On 12 February 2015 at 21:04, John Crispin wrote: > [0.564000] Creating 4 MTD partitions on "spi32766.0": > [0.568000] 0x-0x0001 : "uboot" > [0.572000] 0x0001-0x0002 : "uboot-env" > [0.58] 0x0002-0x0003 : "calibration" > [0.584000] 0x0005-0x00ff : "firmware" > [0.596000] mtdsplit_uimage: [__mtdsplit_parse_uimage] buf:c0049000 > sizeof(*buf):1 > [0.60] mtdsplit_uimage: [__mtdsplit_parse_uimage] sizeof(*header):64 > [0.608000] mtdsplit_uimage: [read_uimage_header] buf:c0049000 > header_len:1 > [0.616000] mtdsplit_uimage: [uimage_find_edimax] buf:c0049000 len:1 > FW_EDIMAX_OFFSET + sizeof(*header):84 > [0.624000] mtdsplit_uimage: Buffer too small for checking Edimax header > [0.784000] Dedicated partitioner didn't split firmware partition, > please fill a bug report! > [0.788000] 0x00172108-0x00ff : "rootfs" > [0.796000] mtd: partition "rootfs" must either start or end on erase > block boundary or be smaller than an erase block -- forcing read-only > [0.808000] mtd: device 4 (rootfs) set to be root filesystem > [0.812000] 1 squashfs-split partitions found on MTD device rootfs > [0.82] 0x0034-0x00ff : "rootfs_data" > [1.916000] Realtek RTL8366RB ethernet switch driver version 0.2.4 > [1.924000] rtl8366rb rtl8366rb: using GPIO pins 491 (SDA) and 493 (SCK) > [1.928000] rtl8366rb rtl8366rb: RTL5937 ver. 3 chip found Thank you! My obvious bug was fixed in https://dev.openwrt.org/changeset/44424/ Please note that if you still get > Dedicated partitioner didn't split firmware partition, please fill a bug > report! with 44424, it means that there is something wrong in target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_uimage.c and we/you should look for a working reference code in 405-mtd-old-firmware-uimage-splitter.patch ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH RFT] kernel: mtdsplit_uimage: debug buf/header sizes
On 12 February 2015 at 20:25, John Crispin wrote: > yep, fixes the problem. please push it :) It just hides the problem, there is still something wrong with sizes. This patch it printing messages to help track the bug. Please provide an output ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH RFT] kernel: mtdsplit_uimage: debug buf/header sizes
---
John can you give it a try, please?
---
.../generic/files/drivers/mtd/mtdsplit/mtdsplit_uimage.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_uimage.c
b/target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_uimage.c
index 2bb5e9a..4abc4be 100644
--- a/target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_uimage.c
+++ b/target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_uimage.c
@@ -20,6 +20,8 @@
#include "mtdsplit.h"
+static int first_try = 1;
+
/*
* uimage_header itself is only 64B, but it may be prepended with another data.
* Currently the biggest size is for Edimax devices: 20B + 64B
@@ -60,6 +62,8 @@ read_uimage_header(struct mtd_info *mtd, size_t offset,
u_char *buf,
size_t retlen;
int ret;
+ if (first_try)
+ pr_info("[%s] buf:%p header_len:%zu\n", __FUNCTION__, buf,
header_len);
ret = mtd_read(mtd, offset, header_len, &retlen, buf);
if (ret) {
pr_debug("read error in \"%s\"\n", mtd->name);
@@ -106,11 +110,15 @@ static int __mtdsplit_parse_uimage(struct mtd_info
*master,
ret = -ENOMEM;
goto err_free_parts;
}
+ if (first_try)
+ pr_info("[%s] buf:%p sizeof(*buf):%u\n", __FUNCTION__, buf,
sizeof(*buf));
/* find uImage on erase block boundaries */
for (offset = 0; offset < master->size; offset += master->erasesize) {
struct uimage_header *header;
+ if (first_try)
+ pr_info("[%s] sizeof(*header):%u\n", __FUNCTION__,
sizeof(*header));
uimage_size = 0;
ret = read_uimage_header(master, offset, buf, sizeof(*buf));
@@ -308,8 +316,13 @@ static ssize_t uimage_find_edimax(u_char *buf, size_t len)
{
struct uimage_header *header;
+ if (first_try)
+ pr_info("[%s] buf:%p len:%zu FW_EDIMAX_OFFSET +
sizeof(*header):%u\n", __FUNCTION__, buf, len, FW_EDIMAX_OFFSET +
sizeof(*header));
+
if (len < FW_EDIMAX_OFFSET + sizeof(*header)) {
- pr_err("Buffer too small for checking Edimax header\n");
+ if (first_try)
+ pr_err("Buffer too small for checking Edimax header\n");
+ first_try = 0;
return -ENOSPC;
}
--
1.8.4.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Request for testing mtdsplit_uimage
As you could notice I've improved mtdsplit_uimage a bit: https://dev.openwrt.org/changeset/44412/ https://dev.openwrt.org/changeset/44413/ https://dev.openwrt.org/changeset/44414/ https://dev.openwrt.org/changeset/44415/ This should add support for Edimax devices, but... could also break something. Please try it and let me know if anything went wrong for you. -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v1 0/7] Add custom TRX header option
On 9 February 2015 at 21:52, Florian Fainelli wrote: > On 09/02/15 08:29, Will Sheppard wrote: >> Patchset to essentially add custom TRX header to all firmware produced. >> >> This is most useful for the Belkin routers from my experience. I'm not >> how other trx based firmwares modify the header for their own purposes. >> >> This is applied across the board so that the kernel, trx tools and mtd >> tools are all compiled with the specified header. >> >> I have modified the kernel specifically for the brcm47xx based boards to >> ensure the mtd parser looks for the correct magic. NOTE: This function will, >> for other boards, fail. > > I don't think this is desirable at all to have, for many reasons: A quick comment: I agree. This patchset looks hacky to me with all these magics set in config file. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/3] sunxi: add support for Linux 3.19
On 10 February 2015 at 15:09, Daniel Golle wrote: > simple-framebuffer now works on the A20. I'm really not sure about other developers opinion (will be happy to hear it), but I guess you could try to generate a patch using git and git format-patch -C That would allow ppl/developers to review changes you had to made. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/3] kernel: fix patches for 3.19
On 10 February 2015 at 15:06, Daniel Golle wrote: > 130, 771 and 772 were merged upstream. > 304 had to be refreshed to apply on the new sources. Nack. This should be part of the previous patch. With current split of your patches this one (2/3) fixes a kind of regression your just introduced in 1/3. Please merge these two patches into a single one. ___ 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] kernel: 3.19 was released
> kernel: 3.19 was released So what? Commit message is supposed to describe the change, not what has happened. -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] cmake.mk: ignores package CFLAGS
On 9 January 2015 at 10:51, Rafał Miłecki wrote: > If you look at include/cmake.mk you will notice followiing: > -DCMAKE_BUILD_TYPE=Release > It means that CMake uses CMAKE_C_FLAGS_RELEASE > > > I've created package and tested it using two variants: > > 1) TARGET_CFLAGS=-DFOO > This is what I got: > grep FOO build_dir/target-*/test/CMakeCache.txt > CMAKE_CXX_FLAGS:STRING='-DFOO ' > CMAKE_C_FLAGS:STRING='-DFOO ' > My app was compiled *without* FOO > > 2) CMAKE_OPTIONS=-DCMAKE_C_FLAGS_RELEASE="-DFOO" > This is what I got: > grep FOO build_dir/target-*/test/CMakeCache.txt > CMAKE_C_FLAGS_RELEASE:STRING=-DFOO > My app was compiled *with* FOO > > > I think there is a bug in cmake.mk. Since we use > -DCMAKE_BUILD_TYPE=Release > we can't really relay on > CFLAGS="$(TARGET_CFLAGS) $(EXTRA_CFLAGS)" > because it will result in > CMAKE_C_FLAGS > instead of > CMAKE_C_FLAGS_RELEASE Ping? -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH V3 libubox] uloop: ignore SIGPIPE by default
Most app don't want to crash because of unhandled SIGPIPE. It could
happen is such trivial situations like writing to socket.
Signed-off-by: Rafał Miłecki
---
V2: Replace signal call with sigaction
V3: Don't duplicate the code
---
uloop.c | 24
1 file changed, 24 insertions(+)
diff --git a/uloop.c b/uloop.c
index 9a77ce4..eed105f 100644
--- a/uloop.c
+++ b/uloop.c
@@ -582,6 +582,28 @@ static void uloop_install_handler(int signum, void
(*handler)(int), struct sigac
sigaction(signum, act, NULL);
}
+static void uloop_ignore_signal(int signum, bool ignore)
+{
+ struct sigaction s;
+ void *new_handler = NULL;
+
+ sigaction(signum, NULL, &s);
+
+ if (ignore) {
+ if (s.sa_handler == SIG_DFL) /* Ignore only if there isn't any
custom handler */
+ new_handler = SIG_IGN;
+ } else {
+ if (s.sa_handler == SIG_IGN) /* Restore only if noone modified
our SIG_IGN */
+ new_handler = SIG_DFL;
+ }
+
+ if (new_handler) {
+ s.sa_handler = new_handler;
+ s.sa_flags = 0;
+ sigaction(signum, &s, NULL);
+ }
+}
+
static void uloop_setup_signals(bool add)
{
static struct sigaction old_sigint, old_sigchld, old_sigterm;
@@ -589,6 +611,8 @@ static void uloop_setup_signals(bool add)
uloop_install_handler(SIGINT, uloop_handle_sigint, &old_sigint, add);
uloop_install_handler(SIGTERM, uloop_handle_sigint, &old_sigterm, add);
uloop_install_handler(SIGCHLD, uloop_sigchld, &old_sigchld, add);
+
+ uloop_ignore_signal(SIGPIPE, add);
}
static int uloop_get_next_timeout(struct timeval *tv)
--
1.8.4.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH V2 libubox] uloop: ignore SIGPIPE by default
Most app don't want to crash because of unhandled SIGPIPE. It could
happen is such trivial situations like writing to socket.
Signed-off-by: Rafał Miłecki
---
V2: Replace signal call with sigaction
---
uloop.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/uloop.c b/uloop.c
index 9a77ce4..baaef8d 100644
--- a/uloop.c
+++ b/uloop.c
@@ -582,6 +582,27 @@ static void uloop_install_handler(int signum, void
(*handler)(int), struct sigac
sigaction(signum, act, NULL);
}
+static void uloop_ignore_signal(int signum, bool ignore)
+{
+ struct sigaction s;
+
+ sigaction(signum, NULL, &s);
+
+ if (ignore) {
+ if (s.sa_handler == SIG_DFL) { /* Ignore only if there isn't
any custom handler */
+ s.sa_handler = SIG_IGN;
+ s.sa_flags = 0;
+ sigaction(signum, &s, NULL);
+ }
+ } else {
+ if (s.sa_handler == SIG_IGN) { /* Restore only if noone
modified our SIG_IGN */
+ s.sa_handler = SIG_DFL;
+ s.sa_flags = 0;
+ sigaction(signum, &s, NULL);
+ }
+ }
+}
+
static void uloop_setup_signals(bool add)
{
static struct sigaction old_sigint, old_sigchld, old_sigterm;
@@ -589,6 +610,8 @@ static void uloop_setup_signals(bool add)
uloop_install_handler(SIGINT, uloop_handle_sigint, &old_sigint, add);
uloop_install_handler(SIGTERM, uloop_handle_sigint, &old_sigterm, add);
uloop_install_handler(SIGCHLD, uloop_sigchld, &old_sigchld, add);
+
+ uloop_ignore_signal(SIGPIPE, add);
}
static int uloop_get_next_timeout(struct timeval *tv)
--
1.8.4.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH libubox] uloop: ignore SIGPIPE by default
Most app don't want to crash because of unhandled SIGPIPE. It could
happen is such trivial situations like writing to socket.
Signed-off-by: Rafał Miłecki
---
uloop.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/uloop.c b/uloop.c
index 9a77ce4..7d11bbc 100644
--- a/uloop.c
+++ b/uloop.c
@@ -582,6 +582,21 @@ static void uloop_install_handler(int signum, void
(*handler)(int), struct sigac
sigaction(signum, act, NULL);
}
+static void uloop_ignore_signal(int signum, bool ignore)
+{
+ struct sigaction s;
+
+ sigaction(signum, NULL, &s);
+
+ if (ignore) {
+ if (s.sa_handler == SIG_DFL) /* Ignore only if there isn't any
custom handler */
+ signal(signum, SIG_IGN);
+ } else {
+ if (s.sa_handler == SIG_IGN) /* Restore only if noone modified
our SIG_IGN */
+ signal(signum, SIG_DFL);
+ }
+}
+
static void uloop_setup_signals(bool add)
{
static struct sigaction old_sigint, old_sigchld, old_sigterm;
@@ -589,6 +604,8 @@ static void uloop_setup_signals(bool add)
uloop_install_handler(SIGINT, uloop_handle_sigint, &old_sigint, add);
uloop_install_handler(SIGTERM, uloop_handle_sigint, &old_sigterm, add);
uloop_install_handler(SIGCHLD, uloop_sigchld, &old_sigchld, add);
+
+ uloop_ignore_signal(SIGPIPE, add);
}
static int uloop_get_next_timeout(struct timeval *tv)
--
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] How to enable EARLY_PRINTK by default on ARM target?
On 25 January 2015 at 21:08, Florian Fainelli wrote: > Le 14/01/2015 22:54, Rafał Miłecki a écrit : >> I wanted bcm53xx kernels to be compiled with EARLY_PRINTK by default. >> This is safe, we enable "earlyprintk" using bootargs on tested devices >> only. >> >> So I have config option enabled in default configs: >>> grep EARLY_PRINTK target/linux/bcm53xx/config-3.1* >> target/linux/bcm53xx/config-3.14:CONFIG_EARLY_PRINTK=y >> target/linux/bcm53xx/config-3.18:CONFIG_EARLY_PRINTK=y >> >> However it gets overwritten by KERNEL_EARLY_PRINTK defined in >> config/Config-kernel.in. >> >> KERNEL_EARLY_PRINTK: >> 1) depends on arm - so non-ARM targets are not affected >> 2) default n - which disables it by default > > Would not "default y if TARGET_bcm53xx" achieve what you want here? Right, already implemented in https://dev.openwrt.org/changeset/43980/ , thanks. -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH uclient] allow sending requests with DELETE method
Signed-off-by: Rafał Miłecki
---
uclient-http.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/uclient-http.c b/uclient-http.c
index 9f9fac9..eb69702 100644
--- a/uclient-http.c
+++ b/uclient-http.c
@@ -41,6 +41,7 @@ enum request_type {
REQ_HEAD,
REQ_POST,
REQ_PUT,
+ REQ_DELETE,
__REQ_MAX
};
@@ -58,6 +59,7 @@ static const char * const request_types[__REQ_MAX] = {
[REQ_HEAD] = "HEAD",
[REQ_POST] = "POST",
[REQ_PUT] = "PUT",
+ [REQ_DELETE] = "DELETE",
};
struct uclient_http {
--
1.8.4.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH uclient] use const for char buffer in uclient_write
We are not supposed to modify it and ustream accepts const already.
Signed-off-by: Rafał Miłecki
---
uclient-backend.h | 2 +-
uclient-http.c| 2 +-
uclient.c | 2 +-
uclient.h | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/uclient-backend.h b/uclient-backend.h
index a5cf4f3..9ccc799 100644
--- a/uclient-backend.h
+++ b/uclient-backend.h
@@ -32,7 +32,7 @@ struct uclient_backend {
void (*disconnect)(struct uclient *cl);
int (*read)(struct uclient *cl, char *buf, unsigned int len);
- int (*write)(struct uclient *cl, char *buf, unsigned int len);
+ int (*write)(struct uclient *cl, const char *buf, unsigned int len);
};
void uclient_backend_set_error(struct uclient *cl, int code);
diff --git a/uclient-http.c b/uclient-http.c
index af43b05..9f9fac9 100644
--- a/uclient-http.c
+++ b/uclient-http.c
@@ -931,7 +931,7 @@ uclient_http_set_header(struct uclient *cl, const char
*name, const char *value)
}
static int
-uclient_http_send_data(struct uclient *cl, char *buf, unsigned int len)
+uclient_http_send_data(struct uclient *cl, const char *buf, unsigned int len)
{
struct uclient_http *uh = container_of(cl, struct uclient_http, uc);
diff --git a/uclient.c b/uclient.c
index d599763..21f6f5d 100644
--- a/uclient.c
+++ b/uclient.c
@@ -221,7 +221,7 @@ void uclient_free(struct uclient *cl)
free(url);
}
-int uclient_write(struct uclient *cl, char *buf, int len)
+int uclient_write(struct uclient *cl, const char *buf, int len)
{
if (!cl->backend->write)
return -1;
diff --git a/uclient.h b/uclient.h
index 5904a38..0c76f6e 100644
--- a/uclient.h
+++ b/uclient.h
@@ -106,7 +106,7 @@ int uclient_connect(struct uclient *cl);
void uclient_disconnect(struct uclient *cl);
int uclient_read(struct uclient *cl, char *buf, int len);
-int uclient_write(struct uclient *cl, char *buf, int len);
+int uclient_write(struct uclient *cl, const char *buf, int len);
int uclient_request(struct uclient *cl);
char *uclient_get_addr(char *dest, int *port, union uclient_addr *a);
--
1.8.4.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] uclient & libubox: handling SIGPIPE / EPIPE
I'm trying to use uclient to monitor my home network servers querying http://ip/status . So far I was using bash + curl, but I'm trying to learn libubox now. So today I accidentally queried some unknown machine (random IP) and my app crashed. What has happened: 1) When I first called "uclient_request", uclient opened socket and wrote GET /status HTTP/1.1 Host: 192.168.0.136 Inside the "ustream_fd_write", write returned -1 and errno was EAGAIN. 2) After handling control back to uloop there was another try of sending GET /status HTTP/1.1 Host: 192.168.0.136 but this time it has failed badly during the "write" call. There was SIGPIPE that wasn't handled and my app has been terminated. Should we somehow handle SIGPIPE in uclient or disable it using SO_NOSIGPIPE? -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] package-ipkg.mk: allow to install CC packages on older versions
On 21 January 2015 at 10:36, Christian Schoenebeck wrote: > Why to block users from using updated packages like ca-certificates, > privoxy or updated luci-apps Because we: 1) Don't want help users breaking their installations if they upgrade wrong package 2) Don't want to keep a list of packages that could be used from different releases The correct way is to provide upgraded package for the stable release (e.g. update package in BB branch). ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH V3 uclient] support for connection timeout
Signed-off-by: Rafał Miłecki
---
V2: Add uclient_set_timeout
Stop timer after receiving data
Start timer after fetching data by uclient user
V3: Fix missing braces in __uclient_notify_read, thanks John!
---
uclient-fetch.c | 4
uclient-http.c | 13 +++--
uclient.c | 36 +++-
uclient.h | 20
4 files changed, 70 insertions(+), 3 deletions(-)
diff --git a/uclient-fetch.c b/uclient-fetch.c
index 22f15c6..0617a02 100644
--- a/uclient-fetch.c
+++ b/uclient-fetch.c
@@ -194,6 +194,10 @@ static void handle_uclient_error(struct uclient *cl, int
code)
type = "Connection failed";
error_ret = 4;
break;
+ case UCLIENT_ERROR_TIMEDOUT:
+ type = "Connection timed out";
+ error_ret = 4;
+ break;
case UCLIENT_ERROR_SSL_INVALID_CERT:
type = "Invalid SSL certificate";
ignore = !verify;
diff --git a/uclient-http.c b/uclient-http.c
index c25e52f..af43b05 100644
--- a/uclient-http.c
+++ b/uclient-http.c
@@ -689,8 +689,13 @@ static void __uclient_notify_read(struct uclient_http *uh)
if (uh->eof)
return;
- if (uh->state == HTTP_STATE_RECV_DATA && uc->cb->data_read)
- uc->cb->data_read(uc);
+ if (uh->state == HTTP_STATE_RECV_DATA) {
+ /* Now it's uclient user turn to read some data */
+ uloop_timeout_cancel(&uc->connection_timeout);
+
+ if (uc->cb->data_read)
+ uc->cb->data_read(uc);
+ }
}
static void __uclient_notify_write(struct uclient_http *uh)
@@ -1030,6 +1035,10 @@ uclient_http_read(struct uclient *cl, char *buf,
unsigned int len)
uclient_notify_eof(uh);
+ /* Now that we consumed something and if this isn't EOF, start timer
again */
+ if (!uh->uc.eof && !cl->connection_timeout.pending)
+ uloop_timeout_set(&cl->connection_timeout, cl->timeout_msecs);
+
return len;
}
diff --git a/uclient.c b/uclient.c
index ab2d5b6..d599763 100644
--- a/uclient.c
+++ b/uclient.c
@@ -141,6 +141,16 @@ free:
return NULL;
}
+static void uclient_connection_timeout(struct uloop_timeout *timeout)
+{
+ struct uclient *cl = container_of(timeout, struct uclient,
connection_timeout);
+
+ if (cl->backend->disconnect)
+ cl->backend->disconnect(cl);
+
+ uclient_backend_set_error(cl, UCLIENT_ERROR_TIMEDOUT);
+}
+
struct uclient *uclient_new(const char *url_str, const char *auth_str, const
struct uclient_cb *cb)
{
struct uclient *cl;
@@ -157,6 +167,8 @@ struct uclient *uclient_new(const char *url_str, const char
*auth_str, const str
cl->backend = url->backend;
cl->cb = cb;
cl->url = url;
+ cl->timeout_msecs = UCLIENT_DEFAULT_TIMEOUT_MS;
+ cl->connection_timeout.cb = uclient_connection_timeout;
return cl;
}
@@ -182,6 +194,16 @@ int uclient_set_url(struct uclient *cl, const char
*url_str, const char *auth_st
return 0;
}
+int uclient_set_timeout(struct uclient *cl, int msecs)
+{
+ if (msecs <= 0)
+ return -EINVAL;
+
+ cl->timeout_msecs = msecs;
+
+ return 0;
+}
+
int uclient_connect(struct uclient *cl)
{
return cl->backend->connect(cl);
@@ -209,10 +231,18 @@ int uclient_write(struct uclient *cl, char *buf, int len)
int uclient_request(struct uclient *cl)
{
+ int err;
+
if (!cl->backend->request)
return -1;
- return cl->backend->request(cl);
+ err = cl->backend->request(cl);
+ if (err)
+ return err;
+
+ uloop_timeout_set(&cl->connection_timeout, cl->timeout_msecs);
+
+ return 0;
}
int uclient_read(struct uclient *cl, char *buf, int len)
@@ -225,6 +255,8 @@ int uclient_read(struct uclient *cl, char *buf, int len)
void uclient_disconnect(struct uclient *cl)
{
+ uloop_timeout_cancel(&cl->connection_timeout);
+
if (!cl->backend->disconnect)
return;
@@ -252,6 +284,7 @@ void __hidden uclient_backend_set_error(struct uclient *cl,
int code)
if (cl->error_code)
return;
+ uloop_timeout_cancel(&cl->connection_timeout);
cl->error_code = code;
uclient_backend_change_state(cl);
}
@@ -261,6 +294,7 @@ void __hidden uclient_backend_set_eof(struct uclient *cl)
if (cl->eof || cl->error_code)
return;
+ uloop_timeout_cancel(&cl->connection_timeout);
cl->eof = true;
uclient_backend_change_state(cl);
}
diff --git a/uclient.h b/uclient.h
index d5a0d5b..5904a38 100644
--- a/uclient.h
+++
[OpenWrt-Devel] [PATCH V2 uclient] support for connection timeout
Signed-off-by: Rafał Miłecki
---
V2: Add uclient_set_timeout
Stop timer after receiving data
Start timer after fetching data by uclient user
---
uclient-fetch.c | 4
uclient-http.c | 12 ++--
uclient.c | 36 +++-
uclient.h | 20
4 files changed, 69 insertions(+), 3 deletions(-)
diff --git a/uclient-fetch.c b/uclient-fetch.c
index 22f15c6..0617a02 100644
--- a/uclient-fetch.c
+++ b/uclient-fetch.c
@@ -194,6 +194,10 @@ static void handle_uclient_error(struct uclient *cl, int
code)
type = "Connection failed";
error_ret = 4;
break;
+ case UCLIENT_ERROR_TIMEDOUT:
+ type = "Connection timed out";
+ error_ret = 4;
+ break;
case UCLIENT_ERROR_SSL_INVALID_CERT:
type = "Invalid SSL certificate";
ignore = !verify;
diff --git a/uclient-http.c b/uclient-http.c
index c25e52f..38e7761 100644
--- a/uclient-http.c
+++ b/uclient-http.c
@@ -689,8 +689,12 @@ static void __uclient_notify_read(struct uclient_http *uh)
if (uh->eof)
return;
- if (uh->state == HTTP_STATE_RECV_DATA && uc->cb->data_read)
- uc->cb->data_read(uc);
+ if (uh->state == HTTP_STATE_RECV_DATA)
+ /* Now it's uclient user turn to read some data */
+ uloop_timeout_cancel(&uc->connection_timeout);
+
+ if (uc->cb->data_read)
+ uc->cb->data_read(uc);
}
static void __uclient_notify_write(struct uclient_http *uh)
@@ -1030,6 +1034,10 @@ uclient_http_read(struct uclient *cl, char *buf,
unsigned int len)
uclient_notify_eof(uh);
+ /* Now that we consumed something and if this isn't EOF, start timer
again */
+ if (!uh->uc.eof && !cl->connection_timeout.pending)
+ uloop_timeout_set(&cl->connection_timeout, cl->timeout_msecs);
+
return len;
}
diff --git a/uclient.c b/uclient.c
index ab2d5b6..d599763 100644
--- a/uclient.c
+++ b/uclient.c
@@ -141,6 +141,16 @@ free:
return NULL;
}
+static void uclient_connection_timeout(struct uloop_timeout *timeout)
+{
+ struct uclient *cl = container_of(timeout, struct uclient,
connection_timeout);
+
+ if (cl->backend->disconnect)
+ cl->backend->disconnect(cl);
+
+ uclient_backend_set_error(cl, UCLIENT_ERROR_TIMEDOUT);
+}
+
struct uclient *uclient_new(const char *url_str, const char *auth_str, const
struct uclient_cb *cb)
{
struct uclient *cl;
@@ -157,6 +167,8 @@ struct uclient *uclient_new(const char *url_str, const char
*auth_str, const str
cl->backend = url->backend;
cl->cb = cb;
cl->url = url;
+ cl->timeout_msecs = UCLIENT_DEFAULT_TIMEOUT_MS;
+ cl->connection_timeout.cb = uclient_connection_timeout;
return cl;
}
@@ -182,6 +194,16 @@ int uclient_set_url(struct uclient *cl, const char
*url_str, const char *auth_st
return 0;
}
+int uclient_set_timeout(struct uclient *cl, int msecs)
+{
+ if (msecs <= 0)
+ return -EINVAL;
+
+ cl->timeout_msecs = msecs;
+
+ return 0;
+}
+
int uclient_connect(struct uclient *cl)
{
return cl->backend->connect(cl);
@@ -209,10 +231,18 @@ int uclient_write(struct uclient *cl, char *buf, int len)
int uclient_request(struct uclient *cl)
{
+ int err;
+
if (!cl->backend->request)
return -1;
- return cl->backend->request(cl);
+ err = cl->backend->request(cl);
+ if (err)
+ return err;
+
+ uloop_timeout_set(&cl->connection_timeout, cl->timeout_msecs);
+
+ return 0;
}
int uclient_read(struct uclient *cl, char *buf, int len)
@@ -225,6 +255,8 @@ int uclient_read(struct uclient *cl, char *buf, int len)
void uclient_disconnect(struct uclient *cl)
{
+ uloop_timeout_cancel(&cl->connection_timeout);
+
if (!cl->backend->disconnect)
return;
@@ -252,6 +284,7 @@ void __hidden uclient_backend_set_error(struct uclient *cl,
int code)
if (cl->error_code)
return;
+ uloop_timeout_cancel(&cl->connection_timeout);
cl->error_code = code;
uclient_backend_change_state(cl);
}
@@ -261,6 +294,7 @@ void __hidden uclient_backend_set_eof(struct uclient *cl)
if (cl->eof || cl->error_code)
return;
+ uloop_timeout_cancel(&cl->connection_timeout);
cl->eof = true;
uclient_backend_change_state(cl);
}
diff --git a/uclient.h b/uclient.h
index d5a0d5b..5904a38 100644
--- a/uclient.h
+++ b/uclient.h
@@ -24,12 +24,15 @@
#include
#include
+#defi
[OpenWrt-Devel] [PATCH uclient] support for connection timeout
Signed-off-by: Rafał Miłecki
---
uclient-fetch.c | 4
uclient.c | 25 -
uclient.h | 4
3 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/uclient-fetch.c b/uclient-fetch.c
index 22f15c6..0617a02 100644
--- a/uclient-fetch.c
+++ b/uclient-fetch.c
@@ -194,6 +194,10 @@ static void handle_uclient_error(struct uclient *cl, int
code)
type = "Connection failed";
error_ret = 4;
break;
+ case UCLIENT_ERROR_TIMEDOUT:
+ type = "Connection timed out";
+ error_ret = 4;
+ break;
case UCLIENT_ERROR_SSL_INVALID_CERT:
type = "Invalid SSL certificate";
ignore = !verify;
diff --git a/uclient.c b/uclient.c
index ab2d5b6..a405179 100644
--- a/uclient.c
+++ b/uclient.c
@@ -207,12 +207,31 @@ int uclient_write(struct uclient *cl, char *buf, int len)
return cl->backend->write(cl, buf, len);
}
+static void uclient_request_timeout(struct uloop_timeout *timeout)
+{
+ struct uclient *cl = container_of(timeout, struct uclient,
request_timeout);
+
+ if (cl->backend->disconnect)
+ cl->backend->disconnect(cl);
+
+ uclient_backend_set_error(cl, UCLIENT_ERROR_TIMEDOUT);
+}
+
int uclient_request(struct uclient *cl)
{
+ int err;
+
if (!cl->backend->request)
return -1;
- return cl->backend->request(cl);
+ err = cl->backend->request(cl);
+ if (err)
+ return err;
+
+ cl->request_timeout.cb = uclient_request_timeout;
+ uloop_timeout_set(&cl->request_timeout,
UCLIENT_DEFAULT_CONNECTION_TIMEOUT_MS);
+
+ return 0;
}
int uclient_read(struct uclient *cl, char *buf, int len)
@@ -225,6 +244,8 @@ int uclient_read(struct uclient *cl, char *buf, int len)
void uclient_disconnect(struct uclient *cl)
{
+ uloop_timeout_cancel(&cl->request_timeout);
+
if (!cl->backend->disconnect)
return;
@@ -243,6 +264,8 @@ static void __uclient_backend_change_state(struct
uloop_timeout *timeout)
static void uclient_backend_change_state(struct uclient *cl)
{
+ uloop_timeout_cancel(&cl->request_timeout);
+
cl->timeout.cb = __uclient_backend_change_state;
uloop_timeout_set(&cl->timeout, 1);
}
diff --git a/uclient.h b/uclient.h
index d5a0d5b..095d894 100644
--- a/uclient.h
+++ b/uclient.h
@@ -24,12 +24,15 @@
#include
#include
+#define UCLIENT_DEFAULT_CONNECTION_TIMEOUT_MS 3
+
struct uclient_cb;
struct uclient_backend;
enum uclient_error_code {
UCLIENT_ERROR_UNKNOWN,
UCLIENT_ERROR_CONNECT,
+ UCLIENT_ERROR_TIMEDOUT,
UCLIENT_ERROR_SSL_INVALID_CERT,
UCLIENT_ERROR_SSL_CN_MISMATCH,
UCLIENT_ERROR_MISSING_SSL_CONTEXT,
@@ -67,6 +70,7 @@ struct uclient {
int status_code;
struct blob_attr *meta;
+ struct uloop_timeout request_timeout;
struct uloop_timeout timeout;
};
--
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] [PATCH uclient] http: wait for socket to be ready before using it
On 15 January 2015 at 13:17, Felix Fietkau wrote: > On 2015-01-15 12:50, Rafał Miłecki wrote: >> This is required as we use USOCK_NONBLOCK. > Are you sure? Theoretically, ustream should already handle it properly. > The first write fails if the socket is not connected yet, so ustream > will buffer the data and send it out again once epoll tells it that the > fd is writable. Maybe we were just thinking about different issues? See two of mine below: 1) time ./uclient-fetch http://192.168.0.1/ Downloading 'http://192.168.0.1/' Connecting to Unknown:32533 HTTP error 401 real0m0.008s (this Unknown:32533 should be IP + port) 2) time ./uclient-fetch http://192.168.1.15/ Downloading 'http://192.168.1.15/' Connecting to Unknown:32656 real2m7.191s (so it finally silently quits, but it takes 2 minutes, more than one could want to wait) -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH V2 libubox 1/2] usock: add helper waiting for socket to be ready
Signed-off-by: Rafał Miłecki
---
V2: Use poll instead of select
---
usock.c | 27 +++
usock.h | 11 +++
2 files changed, 38 insertions(+)
diff --git a/usock.c b/usock.c
index 04ed4ee..5bdd3ff 100644
--- a/usock.c
+++ b/usock.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -117,3 +118,29 @@ int usock(int type, const char *host, const char *service)
{
usock_set_flags(sock, type);
return sock;
}
+
+int usock_wait_ready(int fd, int msecs) {
+ struct pollfd fds[1];
+ int res;
+
+ fds[0].fd = fd;
+ fds[0].events = POLLOUT;
+
+ res = poll(fds, 1, msecs);
+ if (res < 0) {
+ return errno;
+ } else if (res == 0) {
+ return -ETIMEDOUT;
+ } else {
+ int err = 0;
+ socklen_t optlen = sizeof(err);
+
+ res = getsockopt(fd, SOL_SOCKET, SO_ERROR, &err, &optlen);
+ if (res)
+ return errno;
+ if (err)
+ return err;
+ }
+
+ return 0;
+}
diff --git a/usock.h b/usock.h
index 8f30add..c97fc40 100644
--- a/usock.h
+++ b/usock.h
@@ -32,4 +32,15 @@
int usock(int type, const char *host, const char *service);
+/**
+ * Wait for a socket to become ready.
+ *
+ * This may be useful for users of USOCK_NONBLOCK to wait (with a timeout)
+ * for a socket.
+ *
+ * @param fd file descriptor of socket
+ * @param msecs timeout in microseconds
+ */
+int usock_wait_ready(int fd, int msecs);
+
#endif /* USOCK_H_ */
--
1.8.4.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH uclient] http: wait for socket to be ready before using it
This is required as we use USOCK_NONBLOCK.
Signed-off-by: Rafał Miłecki
---
uclient-http.c | 5 +
uclient.h | 2 ++
2 files changed, 7 insertions(+)
diff --git a/uclient-http.c b/uclient-http.c
index c25e52f..82bef8a 100644
--- a/uclient-http.c
+++ b/uclient-http.c
@@ -108,6 +108,7 @@ static int uclient_do_connect(struct uclient_http *uh,
const char *port)
{
socklen_t sl;
int fd;
+ int err;
if (uh->uc.url->port)
port = uh->uc.url->port;
@@ -116,6 +117,10 @@ static int uclient_do_connect(struct uclient_http *uh,
const char *port)
if (fd < 0)
return -1;
+ err = usock_wait_ready(fd, UCLIENT_DEFAULT_CONNECTION_TIMEOUT_MS);
+ if (err)
+ return err;
+
ustream_fd_init(&uh->ufd, fd);
memset(&uh->uc.local_addr, 0, sizeof(uh->uc.local_addr));
diff --git a/uclient.h b/uclient.h
index d5a0d5b..d90b00a 100644
--- a/uclient.h
+++ b/uclient.h
@@ -24,6 +24,8 @@
#include
#include
+#define UCLIENT_DEFAULT_CONNECTION_TIMEOUT_MS 3
+
struct uclient_cb;
struct uclient_backend;
--
1.8.4.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH libubox 2/2] usock: set socket flags right after creating it
Otherwise some flags like USOCK_NONBLOCK wouldn't work as expected
(O_NONBLOCK affects connect behavior).
Signed-off-by: Rafał Miłecki
---
usock.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/usock.c b/usock.c
index 39909c1..7bde620 100644
--- a/usock.c
+++ b/usock.c
@@ -38,7 +38,7 @@ static void usock_set_flags(int sock, unsigned int type)
fcntl(sock, F_SETFL, fcntl(sock, F_GETFL) | O_NONBLOCK);
}
-static int usock_connect(struct sockaddr *sa, int sa_len, int family, int
socktype, bool server)
+static int usock_connect(int type, struct sockaddr *sa, int sa_len, int
family, int socktype, bool server)
{
int sock;
@@ -46,6 +46,8 @@ static int usock_connect(struct sockaddr *sa, int sa_len, int
family, int sockty
if (sock < 0)
return -1;
+ usock_set_flags(sock, type);
+
if (server) {
const int one = 1;
setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, &one, sizeof(one));
@@ -62,7 +64,7 @@ static int usock_connect(struct sockaddr *sa, int sa_len, int
family, int sockty
return -1;
}
-static int usock_unix(const char *host, int socktype, bool server)
+static int usock_unix(int type, const char *host, int socktype, bool server)
{
struct sockaddr_un sun = {.sun_family = AF_UNIX};
@@ -72,7 +74,7 @@ static int usock_unix(const char *host, int socktype, bool
server)
}
strcpy(sun.sun_path, host);
- return usock_connect((struct sockaddr*)&sun, sizeof(sun), AF_UNIX,
socktype, server);
+ return usock_connect(type, (struct sockaddr*)&sun, sizeof(sun),
AF_UNIX, socktype, server);
}
static int usock_inet(int type, const char *host, const char *service, int
socktype, bool server)
@@ -92,7 +94,7 @@ static int usock_inet(int type, const char *host, const char
*service, int sockt
return -1;
for (rp = result; rp != NULL; rp = rp->ai_next) {
- sock = usock_connect(rp->ai_addr, rp->ai_addrlen,
rp->ai_family, socktype, server);
+ sock = usock_connect(type, rp->ai_addr, rp->ai_addrlen,
rp->ai_family, socktype, server);
if (sock >= 0)
break;
}
@@ -107,14 +109,13 @@ int usock(int type, const char *host, const char
*service) {
int sock;
if (type & USOCK_UNIX)
- sock = usock_unix(host, socktype, server);
+ sock = usock_unix(type, host, socktype, server);
else
sock = usock_inet(type, host, service, socktype, server);
if (sock < 0)
return -1;
- usock_set_flags(sock, type);
return sock;
}
--
1.8.4.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH libubox 1/2] usock: add helper waiting for socket to be ready
Signed-off-by: Rafał Miłecki
---
usock.c | 30 ++
usock.h | 11 +++
2 files changed, 41 insertions(+)
diff --git a/usock.c b/usock.c
index 04ed4ee..39909c1 100644
--- a/usock.c
+++ b/usock.c
@@ -117,3 +117,33 @@ int usock(int type, const char *host, const char *service)
{
usock_set_flags(sock, type);
return sock;
}
+
+int usock_wait_ready(int fd, int msecs) {
+ fd_set fds;
+ struct timeval tv;
+ int res;
+
+ FD_ZERO(&fds);
+ FD_SET(fd, &fds);
+
+ tv.tv_sec = msecs / 1000;
+ tv.tv_usec = (msecs % 1000) * 1000;
+
+ res = select(fd + 1, NULL, &fds, NULL, &tv);
+ if (res < 0) {
+ return errno;
+ } else if (res == 0) {
+ return -ETIMEDOUT;
+ } else {
+ int err = 0;
+ socklen_t optlen = sizeof(err);
+
+ res = getsockopt(fd, SOL_SOCKET, SO_ERROR, &err, &optlen);
+ if (res)
+ return errno;
+ if (err)
+ return err;
+ }
+
+ return 0;
+}
diff --git a/usock.h b/usock.h
index 8f30add..c97fc40 100644
--- a/usock.h
+++ b/usock.h
@@ -32,4 +32,15 @@
int usock(int type, const char *host, const char *service);
+/**
+ * Wait for a socket to become ready.
+ *
+ * This may be useful for users of USOCK_NONBLOCK to wait (with a timeout)
+ * for a socket.
+ *
+ * @param fd file descriptor of socket
+ * @param msecs timeout in microseconds
+ */
+int usock_wait_ready(int fd, int msecs);
+
#endif /* USOCK_H_ */
--
1.8.4.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] How to enable EARLY_PRINTK by default on ARM target?
I wanted bcm53xx kernels to be compiled with EARLY_PRINTK by default. This is safe, we enable "earlyprintk" using bootargs on tested devices only. So I have config option enabled in default configs: > grep EARLY_PRINTK target/linux/bcm53xx/config-3.1* target/linux/bcm53xx/config-3.14:CONFIG_EARLY_PRINTK=y target/linux/bcm53xx/config-3.18:CONFIG_EARLY_PRINTK=y However it gets overwritten by KERNEL_EARLY_PRINTK defined in config/Config-kernel.in. KERNEL_EARLY_PRINTK: 1) depends on arm - so non-ARM targets are not affected 2) default n - which disables it by default -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/9] kernel: Allow ubi autoattach to run on NOR flash
On 13 January 2015 at 16:56, Maxime Ripard wrote: > Some devices out there only have a NOR flash to store the rootfs on. > > While using UBI is arguable on this kind of NAND, this is something that > should > be supported. So why use UBI at all? Doesn't it make more sense to stick to the JFFS2? You should be even able to easily create 2 different image types (one for NOR, one for NAND) in one target (see bcm53xx). ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] pivot_overlay doesn't work anymore
On 10 January 2015 at 12:54, Gianluca Anzolin wrote: > I just tried to install the latest CC trunk (r43901) on my netgear wndr4300, > a router with NAND flash on that uses UBIFS. > > I noticed that I cannot use an external /overlay anymore: while I can mount > the usb drive on any mountpoint, the '/overlay' target in /etc/config/fstab > is ignored and the rootfs is never switched to the new device. > > The funny fact is that on another different router this doesn't happen: that > router however doesn't rely on UBIFS since it uses NOR flash. > > So I tried to revert the latest change relevant to fstools (git-svn-id: > svn://svn.openwrt.org/openwrt/trunk@43868 > 3c298f89-4303-0410-b956-a3cf2f4a3e73) and pivot_overlay began to work again. > > I understand that commit is only an upgrade to the latest HEAD of fstools: > before starting to bisect I thought someone working on the code could have > an idea on what's really happening. > > I'll try to bisect this evening if needed. I guess I broke something, but I can't really say what and why. It works for me, but obviously there are mny different possible setups. You can see the list of fstools commits using following URL: http://nbd.name/gitweb.cgi?p=fstools.git;a=shortlog I'll need you to bisect them by changing PKG_SOURCE_VERSION in the package/system/fstools/Makefile What do we know so far: BAD 6a448a100c7ce8b8b85f262ba1258e54363da9cc ??? 1e4579556ca54bdf9ccb86933c64bc6094c04e9a ??? 0bc9aa72941d2e361e77b5ff7c4a742e1de98cc2 ??? a5076ad9c92895c54eb384b224e7af1a914f1fd9 ??? 9847f4e2769d0d808a846724f8dd74b83280fdd8 ??? 1a57eb9b7cc5e772d1090a23c51fdd4a01ec5df0 ??? 25a65a42bb0b2eb0b6c89b1803c703aadae8196b ??? 35056038c02a7cbd18b57a5f46a373d564c69693 GOOD 83cf8896a598fb9fc58da0a9bb4f137695f78853 So please open package/system/fstools/Makefile and change PKG_SOURCE_VERSION to something from the middle of above list. You can start e.g. from 9847f4e2769d0d808a846724f8dd74b83280fdd8. After you change PKG_SOURCE_VERSION to 9847f4e2769d0d808a846724f8dd74b83280fdd8, recompile OpenWrt, install it and try. Using above way, please find the first bad commit. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] cmake.mk: ignores package CFLAGS
If you look at include/cmake.mk you will notice followiing: -DCMAKE_BUILD_TYPE=Release It means that CMake uses CMAKE_C_FLAGS_RELEASE I've created package and tested it using two variants: 1) TARGET_CFLAGS=-DFOO This is what I got: grep FOO build_dir/target-*/test/CMakeCache.txt CMAKE_CXX_FLAGS:STRING='-DFOO ' CMAKE_C_FLAGS:STRING='-DFOO ' My app was compiled *without* FOO 2) CMAKE_OPTIONS=-DCMAKE_C_FLAGS_RELEASE="-DFOO" This is what I got: grep FOO build_dir/target-*/test/CMakeCache.txt CMAKE_C_FLAGS_RELEASE:STRING=-DFOO My app was compiled *with* FOO I think there is a bug in cmake.mk. Since we use -DCMAKE_BUILD_TYPE=Release we can't really relay on CFLAGS="$(TARGET_CFLAGS) $(EXTRA_CFLAGS)" because it will result in CMAKE_C_FLAGS instead of CMAKE_C_FLAGS_RELEASE -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] fstools: update to the latest git HEAD
This allows using UBIFS volume as overlay and adds support for Btrfs. Signed-off-by: Rafał Miłecki --- package/system/fstools/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/package/system/fstools/Makefile b/package/system/fstools/Makefile index 9e3dde7..a71401d 100644 --- a/package/system/fstools/Makefile +++ b/package/system/fstools/Makefile @@ -8,14 +8,14 @@ include $(TOPDIR)/rules.mk PKG_NAME:=fstools -PKG_VERSION:=2014-12-15 +PKG_VERSION:=2015-01-07 PKG_RELEASE=$(PKG_SOURCE_VERSION) PKG_SOURCE_PROTO:=git PKG_SOURCE_URL:=git://nbd.name/fstools.git PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION) -PKG_SOURCE_VERSION:=83cf8896a598fb9fc58da0a9bb4f137695f78853 +PKG_SOURCE_VERSION:=6a448a100c7ce8b8b85f262ba1258e54363da9cc PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_SOURCE_VERSION).tar.gz CMAKE_INSTALL:=1 PKG_CHECK_FORMAT_SECURITY:=0 -- 1.8.4.5 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] netifd: network reload ignores country change
I got wrong country set and couldn't use channels 12/13. So I set: wireless.radio1.country=pl however calling /etc/init.d/network reload didn't do anything. It seems netifd doesn't notice country change. -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] base-files: Use the same LED timing as before for preinit_regular.
On 29 December 2014 at 08:12, Vittorio G (VittGam) wrote:
> On 26 December 2014 at 09:53, Rafał Miłecki wrote:
>>
>> On 26 December 2014 at 09:51, Rafał Miłecki wrote:
>>>
>>> On 25 December 2014 at 02:28, Vittorio G (VittGam)
>>> wrote:
>>>>
>>>> Signed-off-by: Vittorio Gambaletta
>>>>
>>>> diff --git a/package/base-files/files/lib/functions/leds.sh
>>>> b/package/base-files/files/lib/functions/leds.sh
>>>> index 4ac8145..d4d4512 100644
>>>> --- a/package/base-files/files/lib/functions/leds.sh
>>>> +++ b/package/base-files/files/lib/functions/leds.sh
>>>> @@ -60,7 +60,7 @@ status_led_blink_fast() {
>>>> }
>>>>
>>>> status_led_blink_preinit() {
>>>> - led_timer $status_led 200 200
>>>> + led_timer $status_led 100 100
>>>> }
>>>>
>>>> status_led_blink_failsafe() {
>>>> @@ -68,5 +68,5 @@ status_led_blink_failsafe() {
>>>> }
>>>>
>>>> status_led_blink_preinit_regular() {
>>>> - led_timer $status_led 500 500
>>>> + led_timer $status_led 200 200
>>>> }
>>>
>>>
>>> 1) Why?
>>> 2) Explain "as before"
>>> 3) I don't think there is enough difference between 100ms and 200ms
>>
>>
>> 4) You don't mention status_led_blink_preinit(), but your patch also
>> touches it
>
>
> 1) I think that most OpenWrt users, like me, are accustomed to see a led
> pattern of 200ms. I thought it was a bad flash or something else bad when
> I've seen that 500ms blinking...
Is there any reason for that? Was 200ms ever used or documented by OpenWrt?
> 2) "As before" means that when failsafe is possible, it is indicated by a
> new pattern of 100ms. When it is not possible anymore, the
> "classic"/previous 200ms pattern is used.
"As before" and "new pattern" seem to be in conflict ;)
Same question (as above) about the 200ms. What makes it "classic" or "previous"?
500ms looks OK for me, just calm booting, not sure about other people
opinion. But I don't like using 50ms / 100ms / 200ms for 3 different
states because I find them too close/similar. Also if preinit was
always using 200ms (am I wrong? can you prove different interval?) I
don't think we should change it to 100ms.
--
Rafał
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] base-files: Use the same LED timing as before for preinit_regular.
On 26 December 2014 at 09:51, Rafał Miłecki wrote:
> On 25 December 2014 at 02:28, Vittorio G (VittGam)
> wrote:
>> Signed-off-by: Vittorio Gambaletta
>>
>> diff --git a/package/base-files/files/lib/functions/leds.sh
>> b/package/base-files/files/lib/functions/leds.sh
>> index 4ac8145..d4d4512 100644
>> --- a/package/base-files/files/lib/functions/leds.sh
>> +++ b/package/base-files/files/lib/functions/leds.sh
>> @@ -60,7 +60,7 @@ status_led_blink_fast() {
>> }
>>
>> status_led_blink_preinit() {
>> - led_timer $status_led 200 200
>> + led_timer $status_led 100 100
>> }
>>
>> status_led_blink_failsafe() {
>> @@ -68,5 +68,5 @@ status_led_blink_failsafe() {
>> }
>>
>> status_led_blink_preinit_regular() {
>> - led_timer $status_led 500 500
>> + led_timer $status_led 200 200
>> }
>
> 1) Why?
> 2) Explain "as before"
> 3) I don't think there is enough difference between 100ms and 200ms
4) You don't mention status_led_blink_preinit(), but your patch also touches it
--
Rafał
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] base-files: Use the same LED timing as before for preinit_regular.
On 25 December 2014 at 02:28, Vittorio G (VittGam) wrote:
> Signed-off-by: Vittorio Gambaletta
>
> diff --git a/package/base-files/files/lib/functions/leds.sh
> b/package/base-files/files/lib/functions/leds.sh
> index 4ac8145..d4d4512 100644
> --- a/package/base-files/files/lib/functions/leds.sh
> +++ b/package/base-files/files/lib/functions/leds.sh
> @@ -60,7 +60,7 @@ status_led_blink_fast() {
> }
>
> status_led_blink_preinit() {
> - led_timer $status_led 200 200
> + led_timer $status_led 100 100
> }
>
> status_led_blink_failsafe() {
> @@ -68,5 +68,5 @@ status_led_blink_failsafe() {
> }
>
> status_led_blink_preinit_regular() {
> - led_timer $status_led 500 500
> + led_timer $status_led 200 200
> }
1) Why?
2) Explain "as before"
3) I don't think there is enough difference between 100ms and 200ms
--
Rafał
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
