[OpenWrt-Devel] cyassl is causing build errors
I've experienced many build errors on bb-14.07 because of cyassl. For your information, cyassl can't be downloaded directly from its official site. There is a form that needs to be filled before Wolfssl allows downloading of cyassl-3.2.0.zip. Any attemt to download cyassl directly will cause redirection to html download form here. http://wolfssl.com/yaSSL/download/downloadForm.php To simplify the download process, I suggest preparing pre-downloaded cyassl source on OpenWrt mirror and modifying PKG_SOURCE_URL accordingly and removing http://www.yassl.com from PKG_SOURCE_URL. Thanks. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] rules for packages for-14.09 branch
Hello, What are the rules for updating packages in the "for-14.09" branch? Is this branch inactive, or bug fixes and CVEs should get in? regards, Nikos ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] brcm47xx: image: Enhance initramfs support to create chk and alternative nodictionary images
On 13/10/14 07:02, Rafał Miłecki wrote: > On 13 October 2014 00:35, Stephen Parry wrote: >> Enhance support for initramfs: >> - added commands to create chk images for flashing via tftp or >> stock firmware gui >> - added commands to generate nodictionary and noloader variants of trx >> images >> >> Signed-off-by: Stephen Parry > Thanks for your patch, I've partially commited it in r42889 > https://dev.openwrt.org/changeset/42889/ > > I still wonder how we could build firmwares for devices that need > noloader-nodictionary images. Your suggested call: > $(call Image/Build/$(SUBTARGET)/squashfs,initramfs) > will generate a standard (loader + dictionary) image for WNR3500L. The > same problem applies to the WNDR4500. > > Should we add something like > Image/Build/mips74k/devices-with-64k-blocks-noloader-nodictionary > ? And use some trick in it to use correct trx? I've just tested using the following approach in my own Makefile and this seems to work. define Image/Build/mips74k/devices-with-64k-blocks : $(call Image/Build/Chk,$(1)-noloader-nodictionary,wnr3500l_v1_north_america,U12H136T99_NETGEAR,2,$(patsubst jffs2-%,jffs2,$(1))) $(call Image/Build/Chk,$(1)-noloader-nodictionary,wnr3500l_v1_other_regions,U12H136T99_NETGEAR,1,$(patsubst jffs2-%,jffs2,$(1))) : endef Should I commit a new patch, including a change for the WNDR4500? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] CFE Source Code
Hi All, Does anybody know if / how I could get hold of the source code for the specific version of CFE on the WNR3500L? I am seriously tired of trying to get things to work with a bootloader that seems to have 'perverse', 'contrary' and 'broken' as it's middle names. Thanks Stephen Parry ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Watchdog support for AR531x and potential lockup
Hello !
OpenWrt already support watchdog for some Atheros devices (newer ar2315),
but still lack support for older ar531x. This topic already opened here:
https://lists.openwrt.org/pipermail/openwrt-devel/2008-April/002039.html
but without any response from devs. Hope today someone will answer :)
I also found potential lockup involving WDT for those devices
(have DWL-2100AP based ar2313a in my disposal for experiments)
1. Watchdog timer always decrement until zero, it cant be stopped at all.
2. Misc watchdog interrupt _always_ generated if timer is zero, does not
matter contents of CTRL register ! Flag in ISR register always set if
wdt timer equal zero.
3. Misc wdt interrupt flag in ISR can't be cleared until timer set to
some non-zero value !
Unfortunately code in current ar2315-wtd set timer to zero, with followed
eternal loop because ISR flag can't be cleared and interrupt routine
always called again and again (if not masked).
I added support for older ar531x (actually the same, but registers swapped,
so platform device now contain 2 mem resources instead of 1)
and add ability to turn hardware reset on during load (wdt without hardware
reset seems useless for me).
Those patches for code checking only, they not supposed to be committed !
If all ok I can create separated patches, because now watchdog support
exist in 100-board.patch (platform device) and 130-watchdog.patch.
--- ar5312.c.old2014-10-09 20:24:22.0 +0400
+++ ar5312.c2014-10-12 14:12:19.299881573 +0400
@@ -49,9 +49,10 @@
do_IRQ(AR5312_MISC_IRQ_AHB_PROC);
else if ((ar231x_misc_intrs & AR5312_ISR_UART0))
do_IRQ(AR5312_MISC_IRQ_UART0);
- else if (ar231x_misc_intrs & AR5312_ISR_WD)
+ else if (ar231x_misc_intrs & AR5312_ISR_WD) {
do_IRQ(AR5312_MISC_IRQ_WATCHDOG);
- else
+ ar231x_write_reg(AR5312_ISR, AR5312_ISR_WD);
+ } else
do_IRQ(AR5312_MISC_IRQ_NONE);
}
@@ -255,6 +256,31 @@
};
#endif
+static struct resource ar5312_wdt_res[] = {
+ {
+ .flags = IORESOURCE_MEM,
+ .start = AR5312_WD_TIMER,
+ .end = AR5312_WD_TIMER + 4 - 1,
+ },
+ {
+ .flags = IORESOURCE_MEM,
+ .start = AR5312_WD_CTRL,
+ .end = AR5312_WD_CTRL + 4 - 1,
+ },
+ {
+ .flags = IORESOURCE_IRQ,
+ .start = AR5312_MISC_IRQ_WATCHDOG,
+ .end = AR5312_MISC_IRQ_WATCHDOG,
+ }
+};
+
+static struct platform_device ar5312_wdt = {
+ .id = 0,
+ .name = "ar231x-wdt",
+ .resource = ar5312_wdt_res,
+ .num_resources = ARRAY_SIZE(ar5312_wdt_res)
+};
+
/*
* NB: This mapping size is larger than the actual flash size,
* but this shouldn't be a problem here, because the flash
@@ -327,6 +353,7 @@
}
platform_device_register(&ar5312_physmap_flash);
+ platform_device_register(&ar5312_wdt);
#ifdef CONFIG_LEDS_GPIO
ar5312_leds[0].gpio = config->sys_led_gpio;
--- ar2315.c.old2014-10-09 20:24:22.0 +0400
+++ ar2315.c2014-10-11 11:46:09.598278049 +0400
@@ -335,7 +335,12 @@
{
.flags = IORESOURCE_MEM,
.start = AR2315_WD,
- .end = AR2315_WD + 8 - 1,
+ .end = AR2315_WD + 4 - 1,
+ },
+ {
+ .flags = IORESOURCE_MEM,
+ .start = AR2315_WDC,
+ .end = AR2315_WDC + 4 - 1,
},
{
.flags = IORESOURCE_IRQ,
@@ -346,7 +351,7 @@
static struct platform_device ar2315_wdt = {
.id = 0,
- .name = "ar2315-wdt",
+ .name = "ar231x-wdt",
.resource = ar2315_wdt_res,
.num_resources = ARRAY_SIZE(ar2315_wdt_res)
};
--- ar2315-wtd.c2014-10-09 20:24:22.745638862 +0400
+++ ar231x-wdt.c2014-10-12 14:11:37.463673909 +0400
@@ -32,62 +32,71 @@
#include
#include
-#define DRIVER_NAME"ar2315-wdt"
+#define DRIVER_NAME"ar231x-wdt"
#define CLOCK_RATE 4000
#define HEARTBEAT(x) (x < 1 || x > 90 ? 20 : x)
-#define WDT_REG_TIMER 0x00
-#define WDT_REG_CTRL 0x04
+// comment this line if does not want WDT started during boot
+//#define WDT_START_ON_BOOT
#define WDT_CTRL_ACT_NONE 0x /* No action */
#define WDT_CTRL_ACT_NMI 0x0001 /* NMI on watchdog */
#define WDT_CTRL_ACT_RESET 0x0002 /* reset on watchdog */
-static int wdt_timeout = 20;
+#define WDT_CTRL_ACTIONWDT_CTRL_ACT_RESET
+
+static int wdt_timeout = 60;
static int started;
static int in_use;
-static void __iomem *wdt_base;
+static void __iomem *wdt_timer_reg;
+static void __iomem *wdt_ctrl_reg;
-static inline void ar2315_wdt_wr(unsigned reg, u32 val)
+static inline void ar231x_wdt_wr_timer(u32 val)
{
- iowrite32(val, wdt_base + reg);
+ iowrite32(val, wdt_timer_reg);
+}
+
+static inline void ar231x_w
Re: [OpenWrt-Devel] cyassl is causing build errors (Alive4Ever)
On Monday, October 13, 2014 09:49:15 AM openwrt-devel-requ...@lists.openwrt.org wrote: > Message: 4 > Date: Mon, 13 Oct 2014 14:20:07 +0700 > From: Alive4Ever > To: OpenWrt Development List > Subject: [OpenWrt-Devel] cyassl is causing build errors > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > I've experienced many build errors on bb-14.07 because of cyassl. > > For your information, cyassl can't be downloaded directly from its > official site. There is a form that needs to be filled before Wolfssl > allows downloading of cyassl-3.2.0.zip. Any attemt to download cyassl > directly will cause redirection to html download form here. > > http://wolfssl.com/yaSSL/download/downloadForm.php > > To simplify the download process, I suggest preparing pre-downloaded > cyassl source on OpenWrt mirror and modifying PKG_SOURCE_URL accordingly > and removing http://www.yassl.com from PKG_SOURCE_URL. > > Thanks. I tested with another internet connection and found that direct download from http://www.yassl.com worked fine. It seems that the culprit for redirection form is `transparent proxy` operated by my ISP. Direct connection to http://www.yassl.com without any `transparent proxy` middleman works fine. Although that's the cause of my problem, I still suggest to provide another mirror for cyassl in case main cyassl mirror prevents direct downloading for users behind `transparent proxy`. Thanks. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] CFE Source Code
On 13 October 2014 09:46, Stephen G. Parry wrote: > Does anybody know if / how I could get hold of the source code for the > specific version of CFE on the WNR3500L? I am seriously tired of trying > to get things to work with a bootloader that seems to have 'perverse', > 'contrary' and 'broken' as it's middle names. I don't think Netgear tends to release CFE sources. It's not GPL, they don't have to. Usually you can find CFE sources in Asus GPL packages. Few examples where I saw it: GPL_RT_AC66U_3004374979 GPL_RT_AC68U_3004374583 GPL_RT_N53_3004374130 GPL_RT_N66U_30043744422 RT-N16 You may try to get it, adjust for your device needs, compile, install. Of course having a flash programmer is must-have for that. I guess it'll need a lot of effort in general. -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] brcm47xx: image: Enhance initramfs support to create chk and alternative nodictionary images
On 13 October 2014 09:40, Stephen G. Parry wrote: > > On 13/10/14 07:02, Rafał Miłecki wrote: >> I still wonder how we could build firmwares for devices that need >> noloader-nodictionary images. Your suggested call: >> $(call Image/Build/$(SUBTARGET)/squashfs,initramfs) >> will generate a standard (loader + dictionary) image for WNR3500L. The >> same problem applies to the WNDR4500. >> >> Should we add something like >> Image/Build/mips74k/devices-with-64k-blocks-noloader-nodictionary >> ? And use some trick in it to use correct trx? > I've just tested using the following approach in my own Makefile and > this seems to work. > > define Image/Build/mips74k/devices-with-64k-blocks > : > $(call > Image/Build/Chk,$(1)-noloader-nodictionary,wnr3500l_v1_north_america,U12H136T99_NETGEAR,2,$(patsubst > jffs2-%,jffs2,$(1))) > $(call > Image/Build/Chk,$(1)-noloader-nodictionary,wnr3500l_v1_other_regions,U12H136T99_NETGEAR,1,$(patsubst > jffs2-%,jffs2,$(1))) I was thinking about something like that, just in a separated "define" to group such devices at one place. Btw. I didn't relize you use V1 with serial flash. Let's wait for Hauke's opinion. > Should I commit a new patch, including a change for the WNDR4500? I guess not yet, WNDR4500 is NAND devices, we should get UBI working first. -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Problems with ffmpeg and alsa-lib
Hello, I have two problems with libffmpeg and alsa-lib, both in trunk and BB: 1) Is that libffmpeg always selects alsa-lib, even when I only select libffmpeg-mini. According to the Makefile only libffmpeg-full is supposed to depend on alsa-lib. If i remove that dependency from libffmpeg-full in the Makefile I can compile all variants... What's wrong here? and is the alsa-lib dependency really needed? 2) I can not compile alsa-lib on my platforms (ar71xx and au1000 - both don't have a sound card), it fails with the following error: checking for mips-openwrt-linux-gcc... gcc checking whether the C compiler works... no configure: error: in `/home/br1/dev/openwrt/trunk/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/alsa-lib-1.0.28': configure: error: C compiler cannot create executables This does not look related to having a sound card or not :( In the meanwhile I have solved the problems by removing the alsa-lib dependency... Any ideas for a real fix? bruno ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Watchdog support for AR531x and potential lockup
Hi Sergey,
Interesting coincidence, I just spent the entire Sunday evening to
study the watchdog in the AR2315. I prepare patches for upstream
merging [1]. And also thinking about AR5312 support.
1. http://www.spinics.net/lists/linux-watchdog/msg05202.html
2014-10-13 11:49 GMT+04:00 Sergey Korolew :
> Hello !
>
> OpenWrt already support watchdog for some Atheros devices (newer ar2315),
> but still lack support for older ar531x. This topic already opened here:
> https://lists.openwrt.org/pipermail/openwrt-devel/2008-April/002039.html
> but without any response from devs. Hope today someone will answer :)
>
> I also found potential lockup involving WDT for those devices
> (have DWL-2100AP based ar2313a in my disposal for experiments)
>
> 1. Watchdog timer always decrement until zero, it cant be stopped at all.
Yep, same for AR2315+ SoCs. And if interrupt acknowledged by writing
one to ISR, then the timer starts counting again from 0x and
generates another one interrupt.
> 2. Misc watchdog interrupt _always_ generated if timer is zero, does not
> matter contents of CTRL register ! Flag in ISR register always set if
> wdt timer equal zero.
Same for AR2315+ SoCs.
> 3. Misc wdt interrupt flag in ISR can't be cleared until timer set to
> some non-zero value !
>
> Unfortunately code in current ar2315-wtd set timer to zero, with followed
> eternal loop because ISR flag can't be cleared and interrupt routine
> always called again and again (if not masked).
>
> I added support for older ar531x (actually the same, but registers swapped,
> so platform device now contain 2 mem resources instead of 1)
> and add ability to turn hardware reset on during load (wdt without hardware
> reset seems useless for me).
>
Hardware reset doesn't work on AR2315 since hw bug and cause freeze if
issued by watchdog. See details in AR2315 reset routine in
arch/mips/ar231x/ar2315.c
I would like to propose use different device id strings (e.g.
ar2315-watchdog and ar5312-watchdog) to distinguish SoCs models. This
would help to solve several issues:
- twisted registers (passing adjacent registers via different
resources seems a bit odd),
- possibility of hardware reset,
- detection of watchdog clock frequency, since according to Axel Gembe
patch DWL-2100AP's watchdog timer ticks at 48MHz.
> Those patches for code checking only, they not supposed to be committed !
> If all ok I can create separated patches, because now watchdog support
> exist in 100-board.patch (platform device) and 130-watchdog.patch.
>
> --- ar5312.c.old2014-10-09 20:24:22.0 +0400
> +++ ar5312.c2014-10-12 14:12:19.299881573 +0400
> @@ -49,9 +49,10 @@
> do_IRQ(AR5312_MISC_IRQ_AHB_PROC);
> else if ((ar231x_misc_intrs & AR5312_ISR_UART0))
> do_IRQ(AR5312_MISC_IRQ_UART0);
> - else if (ar231x_misc_intrs & AR5312_ISR_WD)
> + else if (ar231x_misc_intrs & AR5312_ISR_WD) {
> do_IRQ(AR5312_MISC_IRQ_WATCHDOG);
> - else
> + ar231x_write_reg(AR5312_ISR, AR5312_ISR_WD);
> + } else
> do_IRQ(AR5312_MISC_IRQ_NONE);
> }
>
> @@ -255,6 +256,31 @@
> };
> #endif
>
> +static struct resource ar5312_wdt_res[] = {
> + {
> + .flags = IORESOURCE_MEM,
> + .start = AR5312_WD_TIMER,
> + .end = AR5312_WD_TIMER + 4 - 1,
> + },
> + {
> + .flags = IORESOURCE_MEM,
> + .start = AR5312_WD_CTRL,
> + .end = AR5312_WD_CTRL + 4 - 1,
> + },
> + {
> + .flags = IORESOURCE_IRQ,
> + .start = AR5312_MISC_IRQ_WATCHDOG,
> + .end = AR5312_MISC_IRQ_WATCHDOG,
> + }
> +};
> +
> +static struct platform_device ar5312_wdt = {
> + .id = 0,
> + .name = "ar231x-wdt",
> + .resource = ar5312_wdt_res,
> + .num_resources = ARRAY_SIZE(ar5312_wdt_res)
> +};
> +
> /*
> * NB: This mapping size is larger than the actual flash size,
> * but this shouldn't be a problem here, because the flash
> @@ -327,6 +353,7 @@
> }
>
> platform_device_register(&ar5312_physmap_flash);
> + platform_device_register(&ar5312_wdt);
>
> #ifdef CONFIG_LEDS_GPIO
> ar5312_leds[0].gpio = config->sys_led_gpio;
>
>
> --- ar2315.c.old2014-10-09 20:24:22.0 +0400
> +++ ar2315.c2014-10-11 11:46:09.598278049 +0400
> @@ -335,7 +335,12 @@
> {
> .flags = IORESOURCE_MEM,
> .start = AR2315_WD,
> - .end = AR2315_WD + 8 - 1,
> + .end = AR2315_WD + 4 - 1,
> + },
> + {
> + .flags = IORESOURCE_MEM,
> + .start = AR2315_WDC,
> + .end = AR2315_WDC + 4 - 1,
> },
> {
> .flags = IORESOURCE_IRQ,
> @@ -346,7 +351,7 @@
>
> static struct platform_device ar2315_wdt = {
> .id = 0,
> - .name = "ar2315-wdt",
> + .name = "ar231x-wdt",
>
Re: [OpenWrt-Devel] Watchdog support for AR531x and potential lockup
Hello ! >> 1. Watchdog timer always decrement until zero, it cant be stopped at all. SR> Yep, same for AR2315+ SoCs. And if interrupt acknowledged by writing SR> one to ISR, then the timer starts counting again from 0x and SR> generates another one interrupt. Not for ar531x, timer does not overlapping zero on those devices even if ISR flag cleared, and, actually, produce next interrupt. So, setting timer to 0x does not harm both platforms. SR> Hardware reset doesn't work on AR2315 since hw bug and cause freeze if SR> issued by watchdog. See details in AR2315 reset routine in SR> arch/mips/ar231x/ar2315.c I tested hw reset on ar531x, and it works. Are you tested it ? Comments in ar2315_restart function are about different situation, not watchdog reset. SR> I would like to propose use different device id strings (e.g. SR> ar2315-watchdog and ar5312-watchdog) to distinguish SoCs models. This SR> would help to solve several issues: SR> - twisted registers (passing adjacent registers via different SR> resources seems a bit odd), Why ? +4-4 address play looks worse for me :) Who cares how registers placed in address map, if we can use two pointers for them ? :) SR> - possibility of hardware reset, SR> - detection of watchdog clock frequency, since according to Axel Gembe SR> patch DWL-2100AP's watchdog timer ticks at 48MHz. Well, interrupt generated each 96 second on my DWL-2100AP, 0x/96 resulting in 44Mhz clock. 40 MHz - 107 seconds timeout 48 Mhz - 89 seconds 60 sec limit should be enough. For me watchdog routines should be as simple as possible, without bells and whistles because of their life-critical status. -- Sergey mailto:d...@bittu.org.ru ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] ffmpeg on au1500 --disable-mips32r2
Hello again, ffmpeg tries to automatically enable optimizations for the MIPS platform, but for au1500 it automatically enables mips32r2, which this CPU does not support. For now, I could fix the problem by adding --disable-mips32r2 to FFMPEG_CONFIGURE, but again, this is probably not the correct solution for all platforms. How should it be done right? bruno ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ffmpeg on au1500 --disable-mips32r2
On 13.10.2014 17:55, Bruno Randolf wrote: > Hello again, > > ffmpeg tries to automatically enable optimizations for the MIPS > platform, but for au1500 it automatically enables mips32r2, which this > CPU does not support. > > For now, I could fix the problem by adding --disable-mips32r2 to > FFMPEG_CONFIGURE, but again, this is probably not the correct solution > for all platforms. How should it be done right? > use appropriate .config symbols (dunno which is the right one) and add something like $(if $(CONFIG_TARGET_au1000),--disable-mips32r2) to that FFMPEG_CONFIGURE ___ 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] failsafe-mode: print short help on commandline
Hi On 12/10/2014 16:23, Bastian Bittorf wrote: > [base-files] failsafe-mode: print short help on commandline > > Like mentioned in ticket https://dev.openwrt.org/ticket/11911 > this should make the IRC much quieter. Failsafe is somehow > special and even experienced users are helpless, because they > are not used to this seldom situation. Also: likely you have > no internet access in this mode, so you cannot use the wiki. as before, i like the idea however you claim "experienced users need help" and then you list /etc/config, passwd and reboot -f imho something does not fit right John P.S.: i thought i fixed the -f thing. sure it does not work without ? > this supersedes the old patches: > http://patchwork.openwrt.org/patch/3337/ > http://patchwork.openwrt.org/patch/3553/ > > Signed-off-by: Bastian Bittorf > --- > package/base-files/files/etc/banner.failsafe | 16 > package/base-files/files/etc/profile |1 + > 2 files changed, 17 insertions(+) > create mode 100644 package/base-files/files/etc/banner.failsafe > > diff --git a/package/base-files/files/etc/banner.failsafe > b/package/base-files/files/etc/banner.failsafe > new file mode 100644 > index 000..618a087 > --- /dev/null > +++ b/package/base-files/files/etc/banner.failsafe > @@ -0,0 +1,16 @@ > += FAILSAFE MODE active > +special commands: > +* firstboot reset settings to factory defaults > +* mount_root mount root-partition with config files > + > +after mount_root: > +* passwd change root's password > +* /etc/configdirectory with config files > + > +restart system with: > +* reboot -f reboots router > + > +for more help see: > +http://wiki.openwrt.org/doc/howto/generic.failsafe > +=== > + > diff --git a/package/base-files/files/etc/profile > b/package/base-files/files/etc/profile > index e9a7119..e72c377 100644 > --- a/package/base-files/files/etc/profile > +++ b/package/base-files/files/etc/profile > @@ -1,4 +1,5 @@ > #!/bin/sh > +[ -e /tmp/.failsafe ] && cat /etc/banner.failsafe > [ -f /etc/banner ] && cat /etc/banner > > export PATH=/usr/bin:/usr/sbin:/bin:/sbin ___ 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] failsafe-mode: print short help on commandline
* John Crispin [13.10.2014 21:18]: > as before, i like the idea however you claim "experienced users need > help" and then you list > > /etc/config, passwd and reboot -f "also experienced users" - this includes the mortal ones. even the "best" are not used to e.g. 'mount_root' and 'firstboot' > P.S.: i thought i fixed the -f thing. sure it does not work without ? i will check. are there other suggestions, which commands should be listed? i should do a grep "failsafe" $openwrt_irc_archive bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [PATCH V2] [boot] /init: allow easier customisation of ramfs boot.
On 13/10/2014 00:03, Stephen Parry wrote: > /init is the first pid 1 process in an initramfs environment. This fix adds > lines to check for the existence of /bin/ramfsinit or /sbin/ramfsinit and exec > if present. This allows packages to switch root early in the boot process. > This > will help support booting or kexecing from external storage and go some way > toward fixing ticket #17465. the ticket says extroot fails for !mtd. please elaborate on that. i would rather we fix extroot to handle this use case rather than build a way to bypass extroot > Signed-off-by: Stephen Parry > --- > V2: Improved script structure using elif > --- > target/linux/generic/base-files/init | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/target/linux/generic/base-files/init > b/target/linux/generic/base-files/init > index 514be57..e80b324 100755 > --- a/target/linux/generic/base-files/init > +++ b/target/linux/generic/base-files/init > @@ -1,4 +1,11 @@ > #!/bin/sh > # Copyright (C) 2006 OpenWrt.org > export INITRAMFS=1 > -exec /sbin/init > + > +if [ -e /bin/ramfsinit ]; then > + exec /bin/ramfsinit > +elif [ -e /sbin/ramfsinit ]; then > + exec /sbin/ramfsinit > +else > + exec /sbin/init > +fi ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Problems with ffmpeg and alsa-lib
1 - I will see what I can do to make alsa-lib optional for various configs. 2 - Building alsa-lib has no dependency on the host system's audio setup. The problem you are seeing is indeed a problem with your build environment, and what tools you have installed. More information is needed about our build system and target config before I can help you. /ted -Original Message- From: Bruno Randolf Sent: Monday, October 13, 2014 9:23 AM To: th...@kitschensync.net Cc: OpenWrt Devel List Subject: Problems with ffmpeg and alsa-lib Hello, I have two problems with libffmpeg and alsa-lib, both in trunk and BB: 1) Is that libffmpeg always selects alsa-lib, even when I only select libffmpeg-mini. According to the Makefile only libffmpeg-full is supposed to depend on alsa-lib. If i remove that dependency from libffmpeg-full in the Makefile I can compile all variants... What's wrong here? and is the alsa-lib dependency really needed? 2) I can not compile alsa-lib on my platforms (ar71xx and au1000 - both don't have a sound card), it fails with the following error: checking for mips-openwrt-linux-gcc... gcc checking whether the C compiler works... no configure: error: in `/home/br1/dev/openwrt/trunk/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/alsa-lib-1.0.28': configure: error: C compiler cannot create executables This does not look related to having a sound card or not :( In the meanwhile I have solved the problems by removing the alsa-lib dependency... Any ideas for a real fix? bruno ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] Fix LED definitions for the DRAGINO2 board
This patch fixes LED definitions for the DRAGINO2 board.
1. It renames the Router/USB led to System, as it is now marked "SYS" on the
board.
2. It gives control of the LAN and WAN leds and some other GPIOs to Linux.
3. It fixes the active_low property for the LAN and WAN leds.
4. It sets up WLAN, LAN and WAN leds in the UCI defaults.
5. It allows usage of the System led by the diag.sh script, so it will be used
to indicate boot and failsafe status.
Signed-off-by: Vittorio Gambaletta
diff --git a/target/linux/ar71xx/base-files/etc/diag.sh
b/target/linux/ar71xx/base-files/etc/diag.sh
index 1864b11..fa07f39 100755
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -62,6 +62,9 @@ get_status_led() {
dir-835-a1)
status_led="d-link:amber:power"
;;
+ dragino2)
+ status_led="dragino2:red:system"
+ ;;
eap300v2)
status_led="engenius:blue:power"
;;
diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
index d3b766d..5b9dbe7 100755
--- a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
+++ b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
@@ -65,6 +65,12 @@ db120)
ucidef_set_led_usbdev "usb" "USB" "db120:green:usb" "1-1"
;;
+dragino2)
+ ucidef_set_led_wlan "wlan" "WLAN" "dragino2:red:wlan" "phy0tpt"
+ ucidef_set_led_netdev "lan" "LAN" "dragino2:red:lan" "eth0"
+ ucidef_set_led_netdev "wan" "WAN" "dragino2:red:wan" "eth1"
+ ;;
+
eap300v2)
ucidef_set_led_netdev "lan" "LAN" "engenius:blue:lan" "eth0"
ucidef_set_led_wlan "wlan" "WLAN" "engenius:blue:wlan" "phy0tpt"
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-dragino2.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-dragino2.c
index 156fbe5..95bd6f4 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-dragino2.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-dragino2.c
@@ -3,6 +3,7 @@
*
* Copyright (C) 2011-2012 Gabor Juhos
* Copyright (C) 2012 Elektra Wagenrad
+ * Copyright (C) 2014 Vittorio Gambaletta
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License version 2 as published
@@ -27,12 +28,12 @@
#define DRAGINO2_GPIO_LED_WAN 17
/*
- * The following GPIO is actually named "Router" on the board.
- * However, since the "Router" feature is not supported as of yet
- * we use it to display USB activity.
+ * The following GPIO is named "SYS" on newer revisions of the the board.
+ * It was previously used to indicate USB activity, even though it was
+ * named "Router".
*/
-#define DRAGINO2_GPIO_LED_USB 28
+#define DRAGINO2_GPIO_LED_SYS 28
#define DRAGINO2_GPIO_BTN_JUMPSTART11
#define DRAGINO2_GPIO_BTN_RESET12
@@ -46,23 +47,23 @@
static struct gpio_led dragino2_leds_gpio[] __initdata = {
{
- .name = "dragino2:red:lan",
- .gpio = DRAGINO2_GPIO_LED_LAN,
- .active_low = 0,
- },
- {
.name = "dragino2:red:wlan",
.gpio = DRAGINO2_GPIO_LED_WLAN,
.active_low = 0,
},
- {
+ {
.name = "dragino2:red:wan",
.gpio = DRAGINO2_GPIO_LED_WAN,
- .active_low = 0,
+ .active_low = 1,
},
{
- .name = "dragino2:red:usb",
- .gpio = DRAGINO2_GPIO_LED_USB,
+ .name = "dragino2:red:lan",
+ .gpio = DRAGINO2_GPIO_LED_LAN,
+ .active_low = 1,
+ },
+ {
+ .name = "dragino2:red:system",
+ .gpio = DRAGINO2_GPIO_LED_SYS,
.active_low = 0,
},
};
@@ -99,15 +100,23 @@ static void __init dragino2_common_setup(void)
ath79_register_mdio(0, 0x0);
- /* Enable GPIO15 and GPIO16 and possibly GPIO26 and GPIO27 */
- ath79_gpio_function_disable(AR933X_GPIO_FUNC_ETH_SWITCH_LED2_EN |
- AR933X_GPIO_FUNC_ETH_SWITCH_LED3_EN);
+ /* Enable GPIO13, GPIO14, GPIO15, GPIO16 and GPIO17 */
+ ath79_gpio_function_disable(AR933X_GPIO_FUNC_ETH_SWITCH_LED0_EN |
+ AR933X_GPIO_FUNC_ETH_SWITCH_LED1_EN |
+ AR933X_GPIO_FUNC_ETH_SWITCH_LED2_EN |
+ AR933X_GPIO_FUNC_ETH_SWITCH_LED3_EN |
+ AR933X_GPIO_FUNC_ETH_SWITCH_LED4_EN);
- /* LAN ports */
+ /* LAN port */
ath79_register_eth(1);
/* WAN port */
ath79_register_eth(0);
+
+ /* Ena
[OpenWrt-Devel] [PATCH] Add u-APSD and WPA-PSK-file options to hostapd
This patch adds uapsd and wpa_psk_file options to hostapd.
It also fixes the hostapd_set_bss_options call in mac80211.sh.
The uapsd option sets the uapsd_advertisement_enabled flag in hostapd, only if
the adapter actually supports the option.
The wpa_psk_file offers the possibility to use a different WPA-PSK key for each
client. The directive points to a file with the following syntax:
> 00:11:22:33:44:55 passphrase_for_client_1
> 00:11:22:33:44:67 passphrase_for_client_2
> 00:11:22:33:44:89
> 0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef
So it is possible to specify both ASCII passphrases and raw 64-chars hex keys.
Signed-off-by: Vittorio Gambaletta
diff -aur /rom/lib/netifd/hostapd.sh /overlay/lib/netifd/hostapd.sh
--- /rom/lib/netifd/hostapd.sh 2014-10-12 12:59:38.0 +0200
+++ /overlay/lib/netifd/hostapd.sh 2014-10-14 00:03:52.0 +0200
@@ -100,7 +100,7 @@
hostapd_common_add_bss_config() {
config_add_string 'bssid:macaddr' 'ssid:string'
- config_add_boolean wds wmm hidden
+ config_add_boolean wds wmm uapsd hidden
config_add_int maxassoc max_inactivity
config_add_boolean disassoc_low_ack isolate short_preamble
@@ -134,6 +134,8 @@
config_add_string 'key1:wepkey' 'key2:wepkey' 'key3:wepkey'
'key4:wepkey' 'password:wpakey'
+ config_add_string wpa_psk_file
+
config_add_boolean wps_pushbutton wps_label ext_registrar wps_pbc_in_m1
config_add_string wps_device_type wps_device_name wps_manufacturer
wps_pin
@@ -161,7 +163,7 @@
maxassoc max_inactivity disassoc_low_ack isolate auth_cache \
wps_pushbutton wps_label ext_registrar wps_pbc_in_m1 \
wps_device_type wps_device_name wps_manufacturer wps_pin \
- macfilter ssid wmm hidden short_preamble rsn_preauth
+ macfilter ssid wmm uapsd hidden short_preamble rsn_preauth
set_default isolate 0
set_default maxassoc 0
@@ -170,6 +172,7 @@
set_default disassoc_low_ack 1
set_default hidden 0
set_default wmm 1
+ set_default uapsd 1
append bss_conf "ctrl_interface=/var/run/hostapd"
if [ "$isolate" -gt 0 ]; then
@@ -187,6 +190,10 @@
append bss_conf "wmm_enabled=$wmm" "$N"
append bss_conf "ignore_broadcast_ssid=$hidden" "$N"
+ [ -n "$phy" ] && iw phy "$phy" info 2>/dev/null | grep -q 'Device
supports AP-side u-APSD.' && {
+ append bss_conf "uapsd_advertisement_enabled=$uapsd" "$N"
+ }
+
[ "$wpa" -gt 0 ] && {
[ -n "$wpa_group_rekey" ] && append bss_conf
"wpa_group_rekey=$wpa_group_rekey" "$N"
[ -n "$wpa_pair_rekey" ] && append bss_conf
"wpa_ptk_rekey=$wpa_pair_rekey""$N"
@@ -201,7 +208,7 @@
wps_not_configured=1
;;
psk)
- json_get_vars key
+ json_get_vars key wpa_psk_file
if [ ${#key} -lt 8 ]; then
wireless_setup_vif_failed INVALID_WPA_PSK
return 1
@@ -210,6 +217,10 @@
else
append bss_conf "wpa_passphrase=$key" "$N"
fi
+ [ -n "$wpa_psk_file" ] && {
+ [ -e "$wpa_psk_file" ] || touch "$wpa_psk_file"
+ append bss_conf "wpa_psk_file=$wpa_psk_file"
"$N"
+ }
wps_possible=1
;;
eap)
diff -aur /rom/lib/netifd/wireless/mac80211.sh
/overlay/lib/netifd/wireless/mac80211.sh
--- /rom/lib/netifd/wireless/mac80211.sh2014-10-12 23:44:53.0
+0200
+++ /overlay/lib/netifd/wireless/mac80211.sh2014-10-13 23:59:39.0
+0200
@@ -310,7 +310,7 @@
hostapd_cfg=
append hostapd_cfg "$type=$ifname" "$N"
- hostapd_set_bss_options hostapd_cfg "$vif" || return 1
+ hostapd_set_bss_options hostapd_cfg "$phy" "$ifname" || return 1
json_get_vars wds dtim_period max_listen_int
set_default wds 0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ffmpeg on au1500 --disable-mips32r2
2014-10-13 9:16 GMT-07:00 Dirk Neukirchen : > On 13.10.2014 17:55, Bruno Randolf wrote: >> Hello again, >> >> ffmpeg tries to automatically enable optimizations for the MIPS >> platform, but for au1500 it automatically enables mips32r2, which this >> CPU does not support. >> >> For now, I could fix the problem by adding --disable-mips32r2 to >> FFMPEG_CONFIGURE, but again, this is probably not the correct solution >> for all platforms. How should it be done right? >> > use appropriate .config symbols (dunno which is the right one) and add > something like > > $(if $(CONFIG_TARGET_au1000),--disable-mips32r2) I would test for CPU_TYPE instead of the target, since au1000 is not the only one we support which is mips32r1 only. So something like: $(ifeq $(CONFIG_CPU_TYPE),"mips32",--disable-mips32r2) would probably work just fine. Anything that is mips32r2 sets a different CPU_TYPE, such as 24kec+dsp, 34kc, 74k or even mips32r2. -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [PATCH V2] [boot] /init: allow easier customisation of ramfs boot.
2014-10-13 12:44 GMT-07:00 John Crispin : > > On 13/10/2014 00:03, Stephen Parry wrote: >> /init is the first pid 1 process in an initramfs environment. This fix adds >> lines to check for the existence of /bin/ramfsinit or /sbin/ramfsinit and >> exec >> if present. This allows packages to switch root early in the boot process. >> This >> will help support booting or kexecing from external storage and go some way >> toward fixing ticket #17465. > > > the ticket says extroot fails for !mtd. please elaborate on that. i > would rather we fix extroot to handle this use case rather than build a > way to bypass extroot Agreed, should not we standardize on /linuxrc instead of ramfsinit, even though that is an initramfs, people might get confused even more with this custom script name. > > > > > > >> Signed-off-by: Stephen Parry >> --- >> V2: Improved script structure using elif >> --- >> target/linux/generic/base-files/init | 9 - >> 1 file changed, 8 insertions(+), 1 deletion(-) >> >> diff --git a/target/linux/generic/base-files/init >> b/target/linux/generic/base-files/init >> index 514be57..e80b324 100755 >> --- a/target/linux/generic/base-files/init >> +++ b/target/linux/generic/base-files/init >> @@ -1,4 +1,11 @@ >> #!/bin/sh >> # Copyright (C) 2006 OpenWrt.org >> export INITRAMFS=1 >> -exec /sbin/init >> + >> +if [ -e /bin/ramfsinit ]; then >> + exec /bin/ramfsinit >> +elif [ -e /sbin/ramfsinit ]; then >> + exec /sbin/ramfsinit >> +else >> + exec /sbin/init >> +fi > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] cyassl is causing build errors
2014-10-13 0:20 GMT-07:00 Alive4Ever : > I've experienced many build errors on bb-14.07 because of cyassl. Is there a build log somewhere that shows these build failures or is just download issues at this point? > > For your information, cyassl can't be downloaded directly from its > official site. There is a form that needs to be filled before Wolfssl > allows downloading of cyassl-3.2.0.zip. Any attemt to download cyassl > directly will cause redirection to html download form here. > > http://wolfssl.com/yaSSL/download/downloadForm.php > > To simplify the download process, I suggest preparing pre-downloaded > cyassl source on OpenWrt mirror and modifying PKG_SOURCE_URL accordingly > and removing http://www.yassl.com from PKG_SOURCE_URL. I am not seeing any checkbox for downloading cyassl-3.2.0.zip per se, so I don't know whether this is a bug on their form, their form is there because of the cryptography software restrictions that apply to exporting such technology to other countries. IANAL, but this export compliance restriction is not necessarily in contradiction with GPLv2, so it is not as simple as putting their zip archive on downloads.openwrt.org, by the same token, the agreement button is about GPLv2, not the export compliance, so we might be just fine after all with offering an alternate download method. -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
