Re: [OpenWrt-Devel] The problems with getting Cairo to work
Hello Jon, On 01/18/12 03:19, jonsm...@gmail.com wrote: I think I finally found the problem with getting Cairo to work on ARM. What I thought was a problem with an index in the Truetype file actually turned out to be a code generation flaw in the 4.5-linaro compiler. The flaw was in libpixman which is a supporting library for cairo. Compiling libpixman with -O0 made everything work. O1,O2,O3,Os all failed. The flaw was causing random writes that corrupted memory. I identified the subroutine with the code generation problem but I didn't debug the assembly code. While I was working on this bug OpenWRT was updated to the 2012-1 release of 4.6 gcc-linaro. That release fixed the compiler bug that was causing openssl not to build. And guess what, libpixman now works at all optimization levels on that compiler. Thank you for your detailed analysis and letting us know about your progress and findings. If that may interest gcc developpers you might want to report the libxpixman bad code generation to their bugtracker in case they plan on releasing an updated gcc-4.5 release. So I hope my problems are gone for now. I have a dozen test programs and they are all running. I'm hoping the problem is truly fixed and hasn't just moved around again. Once I'm confident with stability I'll prepare patches moving cairo, pixman, freetype, liberation up to more recent versions. Plus I'll package the luaCairo wrapper. With those additions you'll be able to draw pretty pictures on screens with lua scripts. Allright, thanks! -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH V2] ar71xx: support for kernel 3.1
2012.01.18. 4:42 keltezéssel, Otto Solares Cabrera írta: On Thu, Dec 08, 2011 at 11:57:46PM +0100, Hartmut Knaack wrote: juhosg was working quite hard to get us out of sync, with decent support of nbd ;-) It took me a while, but we're finally back on the track. Minimum kernel version is probably still 3.1.1. Successfully tested with kernel 3.1.4 on a WR1043ND. Kernel version in the Makefile still needs to be adjusted manually. Any comments appreciated. Enjoy. Hi Harmut, do you have something for 3.2? I don't want to duplicate efforts :=) I'm working on that. -Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH V2] ar71xx: support for kernel 3.1
Hello, On 01/18/12 08:47, Dave Taht wrote: On Wed, Jan 18, 2012 at 4:42 AM, Otto Solares Cabreraso...@guug.org wrote: On Thu, Dec 08, 2011 at 11:57:46PM +0100, Hartmut Knaack wrote: juhosg was working quite hard to get us out of sync, with decent support of nbd ;-) It took me a while, but we're finally back on the track. Minimum kernel version is probably still 3.1.1. Successfully tested with kernel 3.1.4 on a WR1043ND. Kernel version in the Makefile still needs to be adjusted manually. Any comments appreciated. Enjoy. Hi Harmut, do you have something for 3.2? I don't want to duplicate efforts :=) Personally I feel that skipping 3.2 entirely and going to 3.3 is the right course, as that has byte queue limits, a fixed implementation of RED, aRED, multiple improvements to SFQ that make it scale up much better, and behave better in the general case, and a new combination of SFQ and RED that looks very promising. Well sure these are interesting features to pull from an updated kernel version, but it is not a reason for skipping 3.2 entirely, especially if we feel like making this the base kernel version for releasing Attitude Adjustement at some point. -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH V2] ar71xx: support for kernel 3.1
Otto Solares Cabrera schrieb: On Thu, Dec 08, 2011 at 11:57:46PM +0100, Hartmut Knaack wrote: juhosg was working quite hard to get us out of sync, with decent support of nbd ;-) It took me a while, but we're finally back on the track. Minimum kernel version is probably still 3.1.1. Successfully tested with kernel 3.1.4 on a WR1043ND. Kernel version in the Makefile still needs to be adjusted manually. Any comments appreciated. Enjoy. Hi Harmut, do you have something for 3.2? I don't want to duplicate efforts :=) I'd stick to 3.1 for the time being. As soon as IIO gets out of staging, I will probably do an update again :-) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH V2] ar71xx: support for kernel 3.1
On Jan 18, 2012, at 2:47 AM, Dave Taht wrote: On Wed, Jan 18, 2012 at 4:42 AM, Otto Solares Cabrera so...@guug.org wrote: On Thu, Dec 08, 2011 at 11:57:46PM +0100, Hartmut Knaack wrote: juhosg was working quite hard to get us out of sync, with decent support of nbd ;-) It took me a while, but we're finally back on the track. Minimum kernel version is probably still 3.1.1. Successfully tested with kernel 3.1.4 on a WR1043ND. Kernel version in the Makefile still needs to be adjusted manually. Any comments appreciated. Enjoy. Hi Harmut, do you have something for 3.2? I don't want to duplicate efforts :=) Personally I feel that skipping 3.2 entirely and going to 3.3 is the right course, as that has byte queue limits, a fixed implementation of RED, aRED, multiple improvements to SFQ that make it scale up much better, and behave better in the general case, and a new combination of SFQ and RED that looks very promising. I would definitely concur with dave on the 3.3 work, it would be nice, but some would like to start 3.2 and maybe even 3.1 and not be so cutting edge as we both are… My vote… 3.3 it would be nice to catch up -- Otto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Dave Täht SKYPE: davetaht US Tel: 1-239-829-5608 FR Tel: 0638645374 http://www.bufferbloat.net ___ 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
[OpenWrt-Devel] [PATCH] ltq_dsl_app support for taking pppoa link up and down
Hi, The attached patch adds a notify script to the dsl_cpe_control app to bring the relevant pppoa interface up (or down) whenever there is a line status change. As far as I can tell the existing hotplug mechanism doesn't work for non-br2684 based systems as there is no nas0 interface created, and hence no hotplug event ... so the ppp link stays down until you manually start it, people may be surviving by having an erroneous bridge configured (which seems to be the default), but clearly this isn't the right behaviour. The patch largely replicates the code from the atm hotplug script (with the addition of support for the link going down.) Signed-off-by: Lee Essen lee.es...@nowonline.co.uk ifx_cpe_ifup.patch Description: Binary data ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] The problems with getting Cairo to work
On Wed, Jan 18, 2012 at 4:15 AM, Florian Fainelli flor...@openwrt.org wrote: Hello Jon, On 01/18/12 03:19, jonsm...@gmail.com wrote: I think I finally found the problem with getting Cairo to work on ARM. What I thought was a problem with an index in the Truetype file actually turned out to be a code generation flaw in the 4.5-linaro compiler. The flaw was in libpixman which is a supporting library for cairo. Compiling libpixman with -O0 made everything work. O1,O2,O3,Os all failed. The flaw was causing random writes that corrupted memory. I identified the subroutine with the code generation problem but I didn't debug the assembly code. While I was working on this bug OpenWRT was updated to the 2012-1 release of 4.6 gcc-linaro. That release fixed the compiler bug that was causing openssl not to build. And guess what, libpixman now works at all optimization levels on that compiler. Thank you for your detailed analysis and letting us know about your progress and findings. If that may interest gcc developpers you might want to report the libxpixman bad code generation to their bugtracker in case they plan on releasing an updated gcc-4.5 release. I didn't track things down further since debugging is too painful without hardware watchpoints working. Some of these issues with gdb need to get fixed... Any ideas why the target ARM gdb doesn't work? run gdb ... This GDB was configured as arm-openwrt-linux... I'm sorry, Dave, I can't do that. Symbol format `elf32-littlearm' unknown. gdbremote works, but it doesn't support hardware breakpoints until the 7.x series and we're at 6.8. 7.2 won't build because it complains the C run-time is too old. Target gdb should support hardware breakpoints if I can get it running. So I hope my problems are gone for now. I have a dozen test programs and they are all running. I'm hoping the problem is truly fixed and hasn't just moved around again. Once I'm confident with stability I'll prepare patches moving cairo, pixman, freetype, liberation up to more recent versions. Plus I'll package the luaCairo wrapper. With those additions you'll be able to draw pretty pictures on screens with lua scripts. Allright, thanks! -- Florian -- Jon Smirl jonsm...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH V2] ar71xx: support for kernel 3.1
On 18/01/12 04:24 AM, Florian Fainelli wrote: Hello, On 01/18/12 08:47, Dave Taht wrote: On Wed, Jan 18, 2012 at 4:42 AM, Otto Solares Cabreraso...@guug.org wrote: On Thu, Dec 08, 2011 at 11:57:46PM +0100, Hartmut Knaack wrote: juhosg was working quite hard to get us out of sync, with decent support of nbd ;-) It took me a while, but we're finally back on the track. Minimum kernel version is probably still 3.1.1. Successfully tested with kernel 3.1.4 on a WR1043ND. Kernel version in the Makefile still needs to be adjusted manually. Any comments appreciated. Enjoy. Hi Harmut, do you have something for 3.2? I don't want to duplicate efforts :=) Personally I feel that skipping 3.2 entirely and going to 3.3 is the right course, as that has byte queue limits, a fixed implementation of RED, aRED, multiple improvements to SFQ that make it scale up much better, and behave better in the general case, and a new combination of SFQ and RED that looks very promising. Well sure these are interesting features to pull from an updated kernel version, but it is not a reason for skipping 3.2 entirely, especially if we feel like making this the base kernel version for releasing Attitude Adjustment at some point. -- Florian All of that is cool and all but it would need docs or to enabled by default. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Init Script to Foreground
I have look at this option but it applies to every time. So based on this solution i modified the rcS to look for my flag and set the foreground variable based on the result. Thanks for the help. Pawel On Wed, Jan 18, 2012 at 2:04 AM, Philip Prindeville philipp_s...@redfish-solutions.com wrote: I'm confused. So in /etc/config/system: config system option foreground 1 doesn't work for you? -Philip On 1/17/12 11:42 AM, Pawel Pastuszak wrote: Hello everybody, I have an odd question i am trying to find an way to have my init script on power up to take over the console so the process can be interrupted. It's pretty much if an flag is set to x in kernel arguments then do y but i want y to be the foreground process. What i notice all Init script are executed in background. Any thoughts for any one? Pawel ___ 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] [PATCH V2] ar71xx: support for kernel 3.1
On Wed, Jan 18, 2012 at 10:19:45AM +0100, Gabor Juhos wrote: 2012.01.18. 4:42 keltezéssel, Otto Solares Cabrera írta: On Thu, Dec 08, 2011 at 11:57:46PM +0100, Hartmut Knaack wrote: juhosg was working quite hard to get us out of sync, with decent support of nbd ;-) It took me a while, but we're finally back on the track. Minimum kernel version is probably still 3.1.1. Successfully tested with kernel 3.1.4 on a WR1043ND. Kernel version in the Makefile still needs to be adjusted manually. Any comments appreciated. Enjoy. Hi Harmut, do you have something for 3.2? I don't want to duplicate efforts :=) I'm working on that. Great! if you need help with testing let me know. Thank you. -- Otto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] x86/config-3.2: add linux-3.2 symbols for x86
The following symbols are missing for x86. Signed-off-by: Philip Prindeville phil...@redfish-solutions.com Index: target/linux/x86/config-default === --- target/linux/x86/config-default (revision 29776) +++ target/linux/x86/config-default (working copy) @@ -426,6 +425,7 @@ # CONFIG_X86_P4_CLOCKMOD is not set # CONFIG_X86_PAE is not set CONFIG_X86_PAT=y +# CONFIG_ARCH_RANDOM is not set # CONFIG_X86_PCC_CPUFREQ is not set CONFIG_X86_PLATFORM_DEVICES=y CONFIG_X86_PM_TIMER=y Index: target/linux/generic/config-3.2 === --- target/linux/generic/config-3.2 (revision 29776) +++ target/linux/generic/config-3.2 (working copy) @@ -1172,6 +1172,7 @@ # CONFIG_IWMC3200TOP is not set # CONFIG_IXGB is not set # CONFIG_IXGBE is not set +# CONFIG_IXGBEVF is not set # CONFIG_JBD is not set # CONFIG_JBD2_DEBUG is not set # CONFIG_JBD_DEBUG is not set @@ -1705,6 +1706,7 @@ CONFIG_NET_VENDOR_HP=y CONFIG_NET_VENDOR_INTEL=y CONFIG_NET_VENDOR_I825XX=y +# CONFIG_ZNET is not set CONFIG_NET_VENDOR_MARVELL=y CONFIG_NET_VENDOR_MELLANOX=y CONFIG_NET_VENDOR_MICREL=y ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] adm5120: fix support for kernel 2.6.38
This patch fixes the following issues I encountered while compiling kernel
2.6.38.8 for my Omnima Embedded Controller/Edimax BR6104KP:
- kernel comes up with machine selection during build, even though
everything was properly set in menuconfig
- USB api changes
Successfully built and tested with r29755.
Signed-off-by: Hartmut Knaack knaack.h [at] gmx.de
---
Index: target/linux/adm5120/router_le/config-2.6.38
===
--- target/linux/adm5120/router_le/config-2.6.38(Revision 29755)
+++ target/linux/adm5120/router_le/config-2.6.38(Arbeitskopie)
@@ -47,6 +47,7 @@
CONFIG_ARM_AMBA=y
# CONFIG_ARM_SP805_WATCHDOG is not set
CONFIG_ATA=m
+# CONFIG_ATH79 is not set
# CONFIG_BCM47XX is not set
# CONFIG_BCM63XX is not set
CONFIG_BITREVERSE=y
Index: target/linux/adm5120/patches-2.6.38/010-adm5120_usb_new_api.patch
===
--- target/linux/adm5120/patches-2.6.38/010-adm5120_usb_new_api.patch
(Revision 0)
+++ target/linux/adm5120/patches-2.6.38/010-adm5120_usb_new_api.patch
(Revision 0)
@@ -0,0 +1,57 @@
+Index: drivers/usb/host/adm5120-hcd.c
+===
+--- a/drivers/usb/host/adm5120-hcd.c
b/drivers/usb/host/adm5120-hcd.c
+@@ -32,6 +32,7 @@
+ #include linux/list.h
+ #include linux/usb.h
+ #include linux/usb/otg.h
++#include linux/usb/hcd.h
+ #include linux/dma-mapping.h
+ #include linux/dmapool.h
+ #include linux/reboot.h
+@@ -43,8 +44,6 @@
+ #include asm/unaligned.h
+ #include asm/byteorder.h
+
+-#include ../core/hcd.h
+-#include ../core/hub.h
+
+ #define DRIVER_VERSION0.27.0
+ #define DRIVER_AUTHORGabor Juhos juh...@openwrt.org
+@@ -571,7 +571,7 @@
+ periodic_reinit(ahcd);
+
+ /* use rhsc irqs after khubd is fully initialized */
+-hcd-poll_rh = 1;
++set_bit(HCD_FLAG_POLL_RH, hcd-flags);
+ hcd-uses_new_polling = 1;
+
+ #if 0
+@@ -688,7 +688,7 @@
+ */
+ admhc_vdbg(ahcd, Resume Detect\n);
+ admhc_intr_ack(ahcd, ADMHC_INTR_RESI);
+-hcd-poll_rh = 1;
++set_bit(HCD_FLAG_POLL_RH, hcd-flags);
+ if (ahcd-autostop) {
+ spin_lock(ahcd-lock);
+ admhc_rh_resume(ahcd);
+Index: drivers/usb/host/adm5120-hub.c
+===
+--- a/drivers/usb/host/adm5120-hub.c
b/drivers/usb/host/adm5120-hub.c
+@@ -106,8 +106,11 @@
+ }
+ }
+
+-hcd-poll_rh = admhc_root_hub_state_changes(ahcd, changed,
+-any_connected);
++if (admhc_root_hub_state_changes(ahcd, changed,
++any_connected))
++ set_bit(HCD_FLAG_POLL_RH, hcd-flags);
++else
++ clear_bit(HCD_FLAG_POLL_RH, hcd-flags);
+
+ done:
+ spin_unlock_irqrestore(ahcd-lock, flags);
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ltq_dsl_app support for taking pppoa link up and down
Hi Lee, On Wed, Jan 18, 2012 at 01:22:10PM +, lee.es...@nowonline.co.uk wrote: The attached patch adds a notify script to the dsl_cpe_control app to bring the relevant pppoa interface up (or down) whenever there is a line status change. As far as I can tell the existing hotplug mechanism doesn't work for non-br2684 based systems as there is no nas0 interface created, and hence no hotplug event ... so the ppp link stays down until you manually start it, people may be surviving by having an erroneous bridge configured (which seems to be the default), but clearly this isn't the right behaviour. The patch largely replicates the code from the atm hotplug script (with the addition of support for the link going down.) I did not test your patch yet but I think that regardles of the proto we should do ifup/ifdown. For example I use dhcp... + if [ $DSL_INTERFACE_STATUS = UP ]; then + if [ $proto = pppoa ] [ $up != 1 ] [ $auto = 1 ]; then + found=1 + ( sleep 1; ifup $ifc ) + fi + else + if [ $proto = pppoa ] [ $up = 1 ] [ $auto = 1 ]; then + found=1 + ( sleep 1; ifdown $ifc ) + fi + fi +done This is the part of the patch I'm refering to. Please send your patches inline in the future. Regards, Luka ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ltq_dsl_app support for taking pppoa link up and down
Hi Luka, On 18 Jan 2012, at 22:04, Luka Perkov open...@lukaperkov.net wrote: Hi Lee, On Wed, Jan 18, 2012 at 01:22:10PM +, lee.es...@nowonline.co.uk wrote: The attached patch adds a notify script to the dsl_cpe_control app to bring the relevant pppoa interface up (or down) whenever there is a line status change. As far as I can tell the existing hotplug mechanism doesn't work for non-br2684 based systems as there is no nas0 interface created, and hence no hotplug event ... so the ppp link stays down until you manually start it, people may be surviving by having an erroneous bridge configured (which seems to be the default), but clearly this isn't the right behaviour. The patch largely replicates the code from the atm hotplug script (with the addition of support for the link going down.) I did not test your patch yet but I think that regardles of the proto we should do ifup/ifdown. For example I use dhcp... I'm not sure I understand what you mean? If this script didn't look for pppoa interfaces then it would try to bring up any 'down' interfaces when the DSL line came up, and more worryingly it would take every interface down when the link went down. My understanding is that you either use a br2684 bridge (for pppoe based DSL providers) or pppoa for native pppoa DSL providers (although I've no experience of the bridge option so I am making some assumptions.) In the bridge case the ppp link comes up as part of the hotplug mechanism, but for pppoa you need to trigger it as per the patch. So I'm not sure why you would look at non pppoa interfaces? In fact the code is mostly copied from the hotplug atm script to ensure the behaviour is as similar as possible. + if [ $DSL_INTERFACE_STATUS = UP ]; then + if [ $proto = pppoa ] [ $up != 1 ] [ $auto = 1 ]; then + found=1 + ( sleep 1; ifup $ifc ) + fi + else + if [ $proto = pppoa ] [ $up = 1 ] [ $auto = 1 ]; then + found=1 + ( sleep 1; ifdown $ifc ) + fi + fi +done This is the part of the patch I'm refering to. Please send your patches inline in the future. Oops, apologies ... will do. Regards, Luka Regards, Lee. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2] x86/config-3.2: add linux-3.2 symbols for x86
The following symbols are missing for x86, in sorted order. Signed-off-by: Philip Prindeville phil...@redfish-solutions.com Index: target/linux/x86/config-default === --- target/linux/x86/config-default (revision 29776) +++ target/linux/x86/config-default (working copy) @@ -21,6 +21,7 @@ CONFIG_ARCH_MAY_HAVE_PC_FDC=y # CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set CONFIG_ARCH_POPULATES_NODE_MAP=y +# CONFIG_ARCH_RANDOM is not set CONFIG_ARCH_SELECT_MEMORY_MODEL=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y Index: target/linux/generic/config-3.2 === --- target/linux/generic/config-3.2 (revision 29776) +++ target/linux/generic/config-3.2 (working copy) @@ -1172,6 +1172,7 @@ # CONFIG_IWMC3200TOP is not set # CONFIG_IXGB is not set # CONFIG_IXGBE is not set +# CONFIG_IXGBEVF is not set # CONFIG_JBD is not set # CONFIG_JBD2_DEBUG is not set # CONFIG_JBD_DEBUG is not set @@ -3243,6 +3244,7 @@ CONFIG_ZISOFS=y CONFIG_ZLIB_DEFLATE=y CONFIG_ZLIB_INFLATE=y +# CONFIG_ZNET is not set CONFIG_ZONE_DMA=y CONFIG_ZONE_DMA_FLAG=1 # CONFIG_ZRAM is not set ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ltq_dsl_app support for taking pppoa link up and down
On Wed, Jan 18, 2012 at 10:27:26PM +, Lee Essen wrote: On 18 Jan 2012, at 22:04, Luka Perkov open...@lukaperkov.net wrote: On Wed, Jan 18, 2012 at 01:22:10PM +, lee.es...@nowonline.co.uk wrote: I'm not sure I understand what you mean? If this script didn't look for pppoa interfaces then it would try to bring up any 'down' interfaces when the DSL line came up, and more worryingly it would take every interface down when the link went down. My understanding is that you either use a br2684 bridge (for pppoe based DSL providers) or pppoa for native pppoa DSL providers (although I've no experience of the bridge option so I am making some assumptions.) In the bridge case the ppp link comes up as part of the hotplug mechanism, but for pppoa you need to trigger it as per the patch. So I'm not sure why you would look at non pppoa interfaces? In fact the code is mostly copied from the hotplug atm script to ensure the behaviour is as similar as possible. I was wrong. I'll try and test your patch tomorrow or this weekend... Luka ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RT3052F] Supporting Sitecom WL-341 (rebadged Sercomm IP1006RRv2 with half ram flash)
On Fri, Aug 5, 2011 at 9:47 PM, Marco Antonio Mauro marcu...@gmail.com wrote: Hi I have a Sitecom WL-341 and would like to know what was needed to run OpenWRT on it. It's Ralink based, with a RT3052F ASIC, has 4MB flash and 16MB ram (upgradable to 32 or more, has space and components to accommodate another TSOPII-54 (SDR?) SDRAM chip which pads are left not populated), USB (only data lines as it misses the 5V voltage regulator but I think it can be used with a powered USB hub) and a single pushbutton labelled WPS. Onboard components are: CPU: Ralink RT3052F (covered by glued on heatsink) running at 384MHz RAM: 1x EtronTech EM639165TS-6C 16MB, 1x free TSOPII-54 slot FLASH: 1x Macronix MX29LV320 4MB on bottom side 4xLAN and 1xWAN 100Mbps 1 button only Has a custom u-boot bootloader that is very buggy (TFTP reflash doesn't work, flashes at 0x5 and then tries to boot an image at 0x4) but if the single button the unit has is pressed briefly during boot the unit will use the same protocol as the Linksys NSLU2 that correctly flashes a complete image of the flash except for the bootloader and the NVRAM First 4 blocks of the flash contain the bootloader and nvram, last 64k block is unuseable as it contains the eRcOmM signature required by the bootloader (that starts the NSLU2-protocol reflash if it doesn't find that signature) for a grand total of 3.7Mb available for kernel and rootfs (but probably can be used with an external rootfs via USB) A firmware image can be found here: http://www.sitecom.com/download/4232/WL-341v3_v1012.img The file is a ZIP with a 512byte header, can be unzipped to have the complete firmware image (including bootloader) IP1006RRv2_16.bin that can also be used to reflash via NSLU2-protocol. The source code for the device is here: http://www.sitecom.com/documents/WL-341_GPL.tgz I didn't test it to see if it compiles to a working image or not though. I can post pictures of the board and a bootlog taken via the serial port if needed. Thanks in advance :) I worked on the device and after patching a number of things I built with current svn buildroot and my patches a sysupgrade working image that I then manually modified to get the windows nslu2 update application to reflash the device. I made the wiki page for the device with the status of the port and some information: http://wiki.openwrt.org/toh/sitecom/wl-341 I am now facing 3 problems and I need help: 1. The device has 6 unlabeled leds: 5 blue/amber and 1 blue but in the manufacturer provided source code there is no mention of the GPIOs used. How can I test it manually from openwrt so that at least I can provide the user the ability to use those from within the web interface? 2. The device boots successfully but I cannot enable the wifi access point. In the system log there is an error. You can see the log here: http://wiki.openwrt.org/toh/sitecom/wl-341#notes I personally think it's a not enough RAM problem, but the device tells me there is over 5MB of ram available at boot time so I'm a bit puzzled. 3. To generate an image that can be flashed directly using the windows update application it must satisfy some costraints: it must contain the bootloader that is already on the device even though it won't be flashed (256kb), then the kernel uImage at 0x4, then the rootfs and enough padding to get to 4MiB. The last 16bytes contain a magic (eRcOmM) that must be there at every boot else the router will go in recovery mode. I patched the partition table to avoid using the last flash block in all cases thereby protecting the signature, but I can't seem to figure out how to make the buildroot generate a valid flashable factory image. Basically I need the buildroot to concatenate: 4 blocks from a file; uImage and rootfs padded to 0x30 bytes, and then; 0x10 bytes that contain some parameters for the upgrade application and the eRcOmM magic. I'd like help on how to do those steps. Once I fix those problems (at least the wifi and the factory image ones) I'll prepare and submit a patch here. Thanks again. -- Marcus905 GPG pubkey: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x1FC0ECC932FE5FAC ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] upgrade baresip, restund, libre, librem to version 0.4.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, libre fails to build here, seems to lack an include of stdint.h in re_types.h : - -- 8 -- make -C /home/jow/devel/openwrt/trunk/build_dir/target-mips-linux-gnu/re-0.4.0 HAVE_LIBRESOLV= CC=mips-linux-gnu-gcc EXTRA_CFLAGS=-Os -pipe -mips32 - -mtune=mips32 -fno-caller-saves -msoft-float -fpic -DOPENWRT EXTRA_LFLAGS=-lm DES TDIR=/home/jow/devel/openwrt/trunk/build_dir/target-mips-linux-gnu/re-0.4.0/ipkg-install SYSROOT=/home/jow/devel/openwrt/trunk/staging_dir/toolchain-mips-linux-gnu SYSROOT_ALT=/home/jow/devel/openwrt/trunk/staging_dir/target-mips- linux-gnu/usr RELEASE=1 CROSS_COMPILE=mips-linux-gnu- OS=linux all install make[3]: Entering directory `/home/jow/devel/openwrt/trunk/build_dir/target-mips-linux-gnu/re-0.4.0' CC build-mips/sip/addr.o In file included from src/sip/addr.c:7:0: include/re_types.h:57:18: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'socklen_t' In file included from src/sip/addr.c:8:0: include/re_fmt.h:31:10: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'pl_u32' include/re_fmt.h:32:10: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'pl_x32' include/re_fmt.h:33:10: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'pl_u64' include/re_fmt.h:34:10: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'pl_x64' include/re_fmt.h:101:9: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ch_hex' include/re_fmt.h:105:22: error: expected ')' before '*' token include/re_fmt.h:114:49: warning: type defaults to 'int' in declaration of 'uint32_t' include/re_fmt.h:114:58: error: expected ';', ',' or ')' before '*' token ... - -- 8 -- ~ Jow -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8Xe/QACgkQdputYINPTPNiKgCgjTTVXeC7lPwLLqA3icElp6Bh ggQAoJzbyrPvH4MReBAhtVG+627/oYQ7 =U1l/ -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] crypto: fix regression introduced by r28897
Either remove the extra '\' or use a single assignment... Index: package/kernel/modules/crypto.mk === --- package/kernel/modules/crypto.mk(revision 29788) +++ package/kernel/modules/crypto.mk(working copy) @@ -385,7 +385,7 @@ FILES += $(LINUX_DIR)/crypto/blowfish.ko else FILES += $(LINUX_DIR)/crypto/blowfish_common.ko \ -FILES += $(LINUX_DIR)/crypto/blowfish_generic.ko +$(LINUX_DIR)/crypto/blowfish_generic.ko endif $(call AddDepends/crypto) endef ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
