[OpenWrt-Devel] X86 generic kernel version
Hi list. The x86_generic kernel is lagging behind (again) the last commit has a description stating it is no use ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Kernel test
Hello Guys, I'm newbie at openwrt, since now I've used allways boards with jtag. I have a cisco e3000 router, which I bought some time ago, and I think is time to give it a try with openwrt. I saw there's no official build for the router, but some promising test. My question is how you test/develop the kernel for this routers? Let's suppose I don't have the jtag access, and normally we don't hit with the first try (on a new kernel porting) a full working kernel. How you test those new kernels? Thanks!!! Alberich ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Kernel test
Do you have a serial port, and access to the bootloader? First step, generally, is to try a ramboot image. You transfer it and boot from ram using the boot loader. Watch the serial output to get an idea of what changes you need to support the board. ~Jonathan Bennett On Sat, Apr 28, 2012 at 6:58 AM, Alberich de megres alberich...@gmail.com wrote: Hello Guys, I'm newbie at openwrt, since now I've used allways boards with jtag. I have a cisco e3000 router, which I bought some time ago, and I think is time to give it a try with openwrt. I saw there's no official build for the router, but some promising test. My question is how you test/develop the kernel for this routers? Let's suppose I don't have the jtag access, and normally we don't hit with the first try (on a new kernel porting) a full working kernel. How you test those new kernels? Thanks!!! Alberich ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Kernel test
On 04/28/2012 01:58 PM, Alberich de megres wrote: Hello Guys, I'm newbie at openwrt, since now I've used allways boards with jtag. I have a cisco e3000 router, which I bought some time ago, and I think is time to give it a try with openwrt. I saw there's no official build for the router, but some promising test. My question is how you test/develop the kernel for this routers? Let's suppose I don't have the jtag access, and normally we don't hit with the first try (on a new kernel porting) a full working kernel. How you test those new kernels? Thanks!!! Alberich Hi Alberich, The Cisco e3000 uses the BCM4718 chip [0] which is partly supported by OpenWrt trunk, the generic image should work. OpenWrt should boot on your device and 2.4 GHz WLAN should work with 802.11g speed, 802.11n speed could work with broadcom-wl, I am currently working on getting brcmsmac to work on that SoC. But we do not have Ethernet support for that chip, someone has to implement this spec [1]. Hauke [0]: https://en.wikipedia.org/wiki/Linksys_routers#E3000 [1]: http://bcm-v4.sipsolutions.net/mac-gbit ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Kernel test
Hi, @Jonathan, how get access to the bootloader? do you send it to the router by streaming, or write it and then boot it? @Hauke, I saw there's partial support, and I was planning to implemente the eth support. But I found myself that I don't know mucho about the most basic step as I allways used jtag. I think now is time to move forward :D thanks for the replies! On Sat, Apr 28, 2012 at 2:52 PM, Hauke Mehrtens ha...@hauke-m.de wrote: On 04/28/2012 01:58 PM, Alberich de megres wrote: Hello Guys, I'm newbie at openwrt, since now I've used allways boards with jtag. I have a cisco e3000 router, which I bought some time ago, and I think is time to give it a try with openwrt. I saw there's no official build for the router, but some promising test. My question is how you test/develop the kernel for this routers? Let's suppose I don't have the jtag access, and normally we don't hit with the first try (on a new kernel porting) a full working kernel. How you test those new kernels? Thanks!!! Alberich Hi Alberich, The Cisco e3000 uses the BCM4718 chip [0] which is partly supported by OpenWrt trunk, the generic image should work. OpenWrt should boot on your device and 2.4 GHz WLAN should work with 802.11g speed, 802.11n speed could work with broadcom-wl, I am currently working on getting brcmsmac to work on that SoC. But we do not have Ethernet support for that chip, someone has to implement this spec [1]. Hauke [0]: https://en.wikipedia.org/wiki/Linksys_routers#E3000 [1]: http://bcm-v4.sipsolutions.net/mac-gbit ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Fixed: [PATCH 2/3] uhttpd URL-codec enhancements.
My apologies, the 2nd of those patches had a syntax error -- that's what
I get for making a last-minute edit, even to the comments, without
testing! :-p
Here is the corrected patch.
-- David
From d259cff104d2084455476b82e92a3a27524f4263 Mon Sep 17 00:00:00 2001
From: David Favro open...@meta-dynamic.com
Date: Fri, 27 Apr 2012 14:17:52 -0400
Subject: [PATCH] uhttpd URL-codec enhancements.
* uh_urlencode() and uh_urldecode() now return an error condition for
buffer-overflow and malformed-encoding rather than normal return with corrupt
or truncated data. As HTTP request processing is currently implemented, this
causes a 404 HTTP status returned to the client, while 400 is more
appropriate.
* Exposed urlencode() to Lua.
* Lua's uhttpd.urlencode() and .urldecode() now raise an error condition for
buffer-overflow and malformed-encoding rather than normal return with
incorrect data.
---
package/uhttpd/src/uhttpd-lua.c | 24 ++--
package/uhttpd/src/uhttpd-utils.c | 42 +++-
package/uhttpd/src/uhttpd.c |7 +++--
3 files changed, 52 insertions(+), 21 deletions(-)
diff --git a/package/uhttpd/src/uhttpd-lua.c b/package/uhttpd/src/uhttpd-lua.c
index c2efe33..a140dc2 100644
--- a/package/uhttpd/src/uhttpd-lua.c
+++ b/package/uhttpd/src/uhttpd-lua.c
@@ -108,19 +108,34 @@ static int uh_lua_sendc(lua_State *L)
return uh_lua_send_common(L, 1);
}
-static int uh_lua_urldecode(lua_State *L)
+static int uh_lua_str2str(lua_State *L, int (*xlate_func) (char *, int, const char *, int))
{
- size_t inlen, outlen;
+ size_t inlen;
+ int outlen;
const char *inbuf;
char outbuf[UH_LIMIT_MSGHEAD];
inbuf = luaL_checklstring(L, 1, inlen);
- outlen = uh_urldecode(outbuf, sizeof(outbuf), inbuf, inlen);
+ outlen = (* xlate_func)(outbuf, sizeof(outbuf), inbuf, inlen);
+ if( outlen 0 )
+ luaL_error( L, %s on URL-encode codec,
+ (outlen==-1) ? buffer overflow : malformed string );
lua_pushlstring(L, outbuf, outlen);
return 1;
}
+static int uh_lua_urldecode(lua_State *L)
+{
+ return uh_lua_str2str( L, uh_urldecode );
+}
+
+
+static int uh_lua_urlencode(lua_State *L)
+{
+ return uh_lua_str2str( L, uh_urlencode );
+}
+
lua_State * uh_lua_init(const char *handler)
{
@@ -146,6 +161,9 @@ lua_State * uh_lua_init(const char *handler)
lua_pushcfunction(L, uh_lua_urldecode);
lua_setfield(L, -2, urldecode);
+ lua_pushcfunction(L, uh_lua_urlencode);
+ lua_setfield(L, -2, urlencode);
+
/* _G.uhttpd = { ... } */
lua_setfield(L, LUA_GLOBALSINDEX, uhttpd);
diff --git a/package/uhttpd/src/uhttpd-utils.c b/package/uhttpd/src/uhttpd-utils.c
index 1073f3b..1dac33d 100644
--- a/package/uhttpd/src/uhttpd-utils.c
+++ b/package/uhttpd/src/uhttpd-utils.c
@@ -307,7 +307,7 @@ int uh_http_send(
/* blen is the size of buf; slen is the length of src. The input-string need
** not be, and the output string will not be, null-terminated. Returns the
-** length of the decoded string. */
+** length of the decoded string, -1 on buffer overflow, -2 on malformed string. */
int uh_urldecode(char *buf, int blen, const char *src, int slen)
{
int i;
@@ -329,7 +329,15 @@ int uh_urldecode(char *buf, int blen, const char *src, int slen)
}
else
{
-buf[len++] = '%';
+/* Encoding error: it's hard to think of a
+** scenario in which returning an incorrect
+** 'decoding' of the malformed string is
+** preferable to signaling an error condition. */
+#if 0 /* WORSE_IS_BETTER */
+buf[len++] = '%';
+#else
+return -2;
+#endif
}
}
else
@@ -338,12 +346,12 @@ int uh_urldecode(char *buf, int blen, const char *src, int slen)
}
}
- return len;
+ return (i == slen) ? len : -1;
}
/* blen is the size of buf; slen is the length of src. The input-string need
** not be, and the output string will not be, null-terminated. Returns the
-** length of the encoded string. */
+** length of the encoded string, or -1 on error (buffer overflow) */
int uh_urlencode(char *buf, int blen, const char *src, int slen)
{
int i;
@@ -365,11 +373,12 @@ int uh_urlencode(char *buf, int blen, const char *src, int slen)
}
else
{
+ len = -1;
break;
}
}
- return len;
+ return (i == slen) ? len : -1;
}
int uh_b64decode(char *buf, int blen, const unsigned char *src, int slen)
@@ -495,6 +504,9 @@ static char * canonpath(const char *path, char *path_resolved)
return NULL;
}
+/* Returns NULL on error.
+** NB: improperly encoded URL should give client 400 [Bad Syntax]; returning
+** NULL here causes 404 [Not Found], but that's not too unreasonable. */
struct path_info * uh_path_lookup(struct client *cl, const char *url)
{
static char path_phys[PATH_MAX];
@@ -530,21 +542,21 @@ struct path_info * uh_path_lookup(struct client *cl, const char *url)
/* urldecode component w/o query */
if( pathptr url )
- uh_urldecode(
-buffer[strlen(docroot)],
-sizeof(buffer) -
Re: [OpenWrt-Devel] Kernel test (on E3000)
Hi, On Sat, Apr 28, 2012 at 01:58:30PM +0200, Alberich de megres wrote: Let's suppose I don't have the jtag access, and normally we don't hit with the first try (on a new kernel porting) a full working kernel. How you test those new kernels? The E3000 has a serial port (hidden on the back side of the WAN port), and can be re-flashed on the boot rom from tftp - and on the serial console you can see later on what it likes or not :-) There's lots of info about that in the dd-wrt forum: http://www.dd-wrt.com/phpBB2/viewtopic.php?t=62998 http://www.dd-wrt.com/phpBB2/viewtopic.php?p=484264 http://www.dd-wrt.com/phpBB2/viewtopic.php?t=56739 I'm not sure if it has a jtag, but I've needed it - even if I had a kernel in flash that paniced on boot. (Note: I never tried openwrt on these, but the boot rom via serial port thingie is completely independent on the specific firmware you want to load - be it original linksys, dd-wrt or tomatoUSB :-) ) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpGMlT8yeguc.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Exhausted on finding a gpio for USB_POWER...
Hi,guys! I am finding the gpio to enable USB_POWER for tl-wr843n(arthoes ar9341).I've tried out all gpio number just can't power up the usb(with factory firmware it does).Can someone kind to help me solve this? These are the command I tried to find gpios,don't know if it's proper.But it works on leds. root@OpenWrt:~# echo 6 /sys/class/gpio/export root@OpenWrt:~# echo out /sys/class/gpio/gpio6/direction root@OpenWrt:~# echo 0 /sys/class/gpio/export root@OpenWrt:~# echo out /sys/class/gpio/gpio0/direction root@OpenWrt:~# echo 1 /sys/class/gpio/export root@OpenWrt:~# echo out /sys/class/gpio/gpio1/direction root@OpenWrt:~# echo 2 /sys/class/gpio/export root@OpenWrt:~# echo out /sys/class/gpio/gpio2/direction root@OpenWrt:~# echo 3 /sys/class/gpio/export root@OpenWrt:~# echo out /sys/class/gpio/gpio3/direction root@OpenWrt:~# echo 4 /sys/class/gpio/export root@OpenWrt:~# echo out /sys/class/gpio/gpio4/direction Mach is attached. mach-tl-wr843n.ok0428 Description: Binary data ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Exhausted on finding a gpio for USB_POWER...
Hi, Le samedi 28 avril 2012 19:01:03, Vince Huang a écrit : Hi,guys! I am finding the gpio to enable USB_POWER for tl-wr843n(arthoes ar9341).I've tried out all gpio number just can't power up the usb(with factory firmware it does).Can someone kind to help me solve this? These are the command I tried to find gpios,don't know if it's proper.But it works on leds. root@OpenWrt:~# echo 6 /sys/class/gpio/export root@OpenWrt:~# echo out /sys/class/gpio/gpio6/direction root@OpenWrt:~# echo 0 /sys/class/gpio/export root@OpenWrt:~# echo out /sys/class/gpio/gpio0/direction root@OpenWrt:~# echo 1 /sys/class/gpio/export root@OpenWrt:~# echo out /sys/class/gpio/gpio1/direction root@OpenWrt:~# echo 2 /sys/class/gpio/export root@OpenWrt:~# echo out /sys/class/gpio/gpio2/direction root@OpenWrt:~# echo 3 /sys/class/gpio/export root@OpenWrt:~# echo out /sys/class/gpio/gpio3/direction root@OpenWrt:~# echo 4 /sys/class/gpio/export root@OpenWrt:~# echo out /sys/class/gpio/gpio4/direction Mach is attached. Check whether the GPIO might be controlling the USB power using a pull-up/down GPIO. Set the GPIO direction to output, then back to input and see if that changes anything. -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] DHCP capability
No one seems to have disagreed with this, so I'll interpret that as consent. I'll also note that currently we currently don't support list dhcp_option for host configs. We should. It seems to be a trivial change to make. Can we make this change? Thanks, -Philip On 3/28/12 10:29 AM, Philip Prindeville wrote: Jo-Philipp, We started to talk about the following: config host option ip '192.168.1.25' option mac 'd0:27:88:59:38:e8' option name 'gwtest' option tag 'client' list dhcp_option 'option:domain-name,acme.net' config global option tag 'client' list dhcp_option 'option:router,192.168.1.253' list dhcp_option 'option:domain-search,redfish-solutions.com' and this should result in: dhcp-host=d0:27:88:59:38:e8,set:client,192.168.1.25,gwtest,option:domain-name,acme.net dhcp-option=tag:client,option:router,192.168.1.253,option:domain-search,redfish-solutions.com This would allow me to have a class of options associated with 'client' machines (i.e. machines given to me by customers to use on contracts for development that sit on my network) by simply associating them with the 'client' attribute, regardless of what network I put them on. Ditto, I could have: config mac option mac '00:0e:08:*:*:*' option tag 'sipura' option tag 'sipphone' config global option tag 'sipphone' list dhcp_option 'option:tftp-server,pbx.redfish-solutions.com' list dhcp_option 'option:120,192.168.1.1' config global option tag 'sippura' list dhcp_option 'option:bootfile-name,/firmware/spa942.cfg' which would generate: dhcp-mac=set:sipura,set:sipphone,00:0e:08:*:*:* dhcp-option=tag:sipphone,option:tftp-server,pbx.redfish-solutions.com,option:120,192.168.1.1 dhcp-option=tag:sipura,option:bootfile-name,/firmware/spa942.cfg also thinking that the field 'force' would be useful, i.e.: config global option tag 'sipphone' option force 1 list dhcp_option 'option:tftp-server,pbx.redfish-solutions.com' list dhcp_option 'option:120,192.168.1.1' dhcp-option-force=tag:sipphone,option:tftp-server,pbx.redfish-solutions.com,option:120,192.168.1.1 what do you think? -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] update and move util-linux(-ng) and update e2fsprogs
On 04/25/2012 01:33 AM, Luka Perkov wrote: You think that subject is too big... You did not see the patch yet ;) This patch makes several changes with util-linux-ng package: * moves it to util-linux (upstream name) * bumps it to last stable version 2.21.1 (was 2.13.0.1) * adds several new packages * sorts packages inside Makefile * removes patch, it has been applied upstream This patch makes some changes with e2fsprogs package: * bumps it to last stable version 1.42.2 * libraries have migrated from e2fsprogs to util-linux I could resend the patches separately but both would need to be applied. I would also like to maintain these packages. Signed-off-by: Luka Perkov open...@lukaperkov.net Applied, thanks ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/3 V1] remove the possibility to select eglibc trunk and disable eglibc SVN revision selection
On 04/23/2012 03:18 PM, Emmanuel Deloget wrote: When selecting a specific eglibc version, it comes with a specific SVN revision that should not be modified as it (more or less) correspond to a tagged release. This patch disable the possibility to select a specific SVN revision on known eglib versions. This patch also disables the possibility to select the trunk branch of eglibc. There are multiple reasons for that: * trunk/HEAD may not even compile * the OpenWRT built system makes using trunk/HEAD a difficult thing, as OpenWRT fetches the source tree and store it in a compressed tar archive. Subsequent build get the source from the tar archive - not from SVN, making the use of trunk/HEAD largelly innefective. * we cannot know the corresponding version of trunk/HEAD, meaning that we'll face compiling issues when we'll try to copy the libc files - unless the build system is fixed with this specific issue in mind. Signed-off-by: Emmanuel Deloget log...@free.fr Applied (slightly changed) - thanks ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/3 V1] correct eglibc version numbers
On 04/23/2012 02:54 PM, Emmanuel Deloget wrote: eglibc version number depends on the branch and on the maintenance release (i.e. the SVN revision). Changing the revision may change the maintenance version. This patch correlate the SVN revision to the correct version number - without this change, both eglibc 2.12 and eglibc 2.14 provoke build errors when compiling the base-files package (example, for 2.12): $ make package/base-files/compile V=1 make[1] package/base-files/compile make[2] -C package/opkg host-compile make[2] -C package/base-files-network compile make[2] -C package/base-files compile cp: cannot stat `/home/me/openwrt/trunk/staging_dir/toolchain-arm_v7-a_gcc-4.6-linaro_eglibc-trunk_eabi/lib/ld-2.12.so': No such file or directory make[2]: *** [/home/me/openwrt/trunk/bin/omap4/packages/libc_trunk-106_omap4.ipk] Error 1 make[1]: *** [package/base-files/compile] Error 2 make -r package/base-files/compile: build failed. Please re-run make with V=99 to see what's going on make: *** [package/base-files/compile] Erreur 1 Signed-off-by: Emmanuel Deloget log...@free.fr By the way: All your patches didn't apply out of the box due to whitespace errors. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Exhausted on finding a gpio for USB_POWER...
Hi, did you actually echo anything to /sys/class/gpio/gpioX/value? Vince Huang schrieb: Hi,guys! I am finding the gpio to enable USB_POWER for tl-wr843n(arthoes ar9341).I've tried out all gpio number just can't power up the usb(with factory firmware it does).Can someone kind to help me solve this? These are the command I tried to find gpios,don't know if it's proper.But it works on leds. root@OpenWrt:~# echo 6 /sys/class/gpio/export root@OpenWrt:~# echo out /sys/class/gpio/gpio6/direction root@OpenWrt:~# echo 0 /sys/class/gpio/export root@OpenWrt:~# echo out /sys/class/gpio/gpio0/direction root@OpenWrt:~# echo 1 /sys/class/gpio/export root@OpenWrt:~# echo out /sys/class/gpio/gpio1/direction root@OpenWrt:~# echo 2 /sys/class/gpio/export root@OpenWrt:~# echo out /sys/class/gpio/gpio2/direction root@OpenWrt:~# echo 3 /sys/class/gpio/export root@OpenWrt:~# echo out /sys/class/gpio/gpio3/direction root@OpenWrt:~# echo 4 /sys/class/gpio/export root@OpenWrt:~# echo out /sys/class/gpio/gpio4/direction Mach is attached. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Exhausted on finding a gpio for USB_POWER...
Thanks,found it with
echo in /sys/class/gpio/gpio4/direction
My usb stick is recognized right after this.
But I can't get usb initialize from mach!How to solve it?
I've added these lines to mach:
static void __init tl_wr843n_usb_setup(void)
{
/* enable power for the USB port */
gpio_request(TL_WR843N_GPIO_USB_POWER, USB power);
gpio_direction_output(TL_WR843N_GPIO_USB_POWER, 0); /* 1 is not
working,too */
ath79_register_usb();
}
tl_wr843n_usb_setup();
-- Original --
From: Florian Fainelliflor...@openwrt.org;
Date: Sun, Apr 29, 2012 01:09 AM
To: openwrt-developenwrt-devel@lists.openwrt.org;
Cc: Vince Huangaxish...@foxmail.com;
Subject: Re: [OpenWrt-Devel] Exhausted on finding a gpio for USB_POWER...
Hi,
Le samedi 28 avril 2012 19:01:03, Vince Huang a écrit :
Hi,guys!
I am finding the gpio to enable USB_POWER for tl-wr843n(arthoes
ar9341).I've tried out all gpio number just can't power up the usb(with
factory firmware it does).Can someone kind to help me solve this? These
are the command I tried to find gpios,don't know if it's proper.But it
works on leds. root@OpenWrt:~# echo 6 /sys/class/gpio/export
root@OpenWrt:~# echo out /sys/class/gpio/gpio6/direction
root@OpenWrt:~# echo 0 /sys/class/gpio/export
root@OpenWrt:~# echo out /sys/class/gpio/gpio0/direction
root@OpenWrt:~# echo 1 /sys/class/gpio/export
root@OpenWrt:~# echo out /sys/class/gpio/gpio1/direction
root@OpenWrt:~# echo 2 /sys/class/gpio/export
root@OpenWrt:~# echo out /sys/class/gpio/gpio2/direction
root@OpenWrt:~# echo 3 /sys/class/gpio/export
root@OpenWrt:~# echo out /sys/class/gpio/gpio3/direction
root@OpenWrt:~# echo 4 /sys/class/gpio/export
root@OpenWrt:~# echo out /sys/class/gpio/gpio4/direction
Mach is attached.
Check whether the GPIO might be controlling the USB power using a pull-up/down
GPIO. Set the GPIO direction to output, then back to input and see if that
changes anything.
--
Florian___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
