can we have the same for BB please ?
On 06/10/2014 17:10, Eddi De Pieri wrote:
> Hi maintainers,
>
> As requested I'm trying to send my patch to the mail list.
>
> Whith these patch I'm able to:
> 1. get rt2800pci driver to probe the wifi board.
> 2. leds connected to stp to work again (some cha
spotted by buildbot brcm2708:
http://buildbot.openwrt.org:8010/builders/brcm2708/
Signed-off-by: Dirk Neukirchen
---
target/linux/generic/config-3.14 | 3 +++
1 file changed, 3 insertions(+)
diff --git a/target/linux/generic/config-3.14 b/target/linux/generic/config-3.14
index 2501f72..830efff
Hi Paul,
the trick is to add the OpenWrt source as package feed, this way you
gain access to libffi and any other core packages:
$ wget
https://downloads.openwrt.org/barrier_breaker/14.07/ar71xx/generic/OpenWrt-SDK-ar71xx-for-linux-x86_64-gcc-4.8-linaro_uClibc-0.9.33.2.tar.bz2
[...]
$ tar -xjf
On Fri, Oct 3, 2014 at 11:32 AM, Christian Schoenebeck
wrote:
> Hi,
> we got a new ticket inside OpenWrt Ticket #18018 with problems inside LuCI
> app.
> This is normally not an OpenWrt ticket it's a LuCI ticket, but the user don't
> know.
> If the user try to post the ticket at LuCI trac it tak
Hi.
In principle I have no objections but we need to figure out a way on how
to deal with translation files. If stuff is split out of the LuCI repo
you have to take of that yourself.
~ Jow
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
h
On 2014-10-07 08:15, Bastian Bittorf wrote:
> i seems that '/lib/netifd/wireless/mac80211.sh' sets
> the default distance to '0' if not defined via uci.
>
> what does that mean? dynamic ack or not?
> because 0 seems to be a valid value:
0 does not imply dynamic ACK, it is simply the minimum value.
On 2014-10-06 21:23, Pushpal Sidhu wrote:
> This patch originally failed to combine INTA/B/C/D onto a single ARM CPU
> interrupt. Instead, it mapped INTA/B/C and excluded D. This patch
> corrects the issue by mapping all four interrupts to the single ARM CPU
> interrupt. The original intent of the
On Tue, Oct 7, 2014 at 9:37 AM, John Crispin wrote:
> can we have the same for BB please ?
Sure, but later
Eddi
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Hi,
By comparing the gpio register on original firmware and openwrt I
found that Openwrt have gpio 38 as output, while the original firmware
leave this as gpio input even if i don't configured it as pcie-reset
on dts.
I think that this may damage when porting openwrt on new router board.
There
[base-files] shell-scripting: fix wrong usage of '==' operator
normally the '==' is used for invoking a regex parser and is a bashism.
all of the fixes just want to compare a string. the used busybox-ash
will silently "ignore" this mistake, but make it portable/clean at least.
this patch does not
Hello John,
I saw you had reworked my ctrl-alt-del patch for procd. Ok, but
unfortunately, it does not work for me.
What happens; when I press ctrl-alt-del on the unit, I get an
"attempting to kill init" panic.
This happens because the procd process exits. The kernel does not like
its init proce
* Felix Fietkau [07.10.2014 13:40]:
> On 2014-10-07 08:15, Bastian Bittorf wrote:
> > because 0 seems to be a valid value:
> 0 does not imply dynamic ACK, it is simply the minimum value.
> Enabling dynack by default would be a bad idea.
what does 0 mean? the wiki says: 0 meters away, so a short
a
I just had a thought-
Is it possible to move grabbing the SIGINT from uloop_run( ) to
uloop_init( ), with the possibility to execute a
uloop_call_this_to_end_loop() function which sets the uloop_cancelled
variable? (this could then be called from a signal handler without
exposing the uloop_cancell
Hello.
I was trying to bring up GRUB fallback feature on x86_64 based OpenWRT
build.
I used this article as a reference.
http://www.linuxscrew.com/2012/04/24/grub-fallback-boot-good-kernel-if-new-one-crashes/
It's for Fedora, but I hope, that I can do something similar for openwrt.
Here's my conf
since some weeks i have problems using 'macvlan'.
it works with r41037 / kernel 3.10.36 and does
not work with r42830 / kernel 3.10.49 or .55
what i do is this:
brctl addbr br-test
brctl addif br-test $WIFIDEV
ip link set dev br-test up
insmod macvlan
ip link add link br-test subdev0 address 02:c
>Message: 1
>Date: Tue, 07 Oct 2014 12:35:25 +0200
>From: Felix Fietkau
>To: mailinglist
>Subject: Re: [OpenWrt-Devel] Q: mac80211: defailt distance-settings 0
>Message-ID: <5433c1ed.5050...@openwrt.org>
>Content-Type: text/plain; charset=windows-1252
>
>On 2014-10-07 08:15, Bastian Bittorf w
Hi,
On Mon, Oct 06, 2014 at 01:47:28PM +0200, Maxime Ripard wrote:
> Hi,
>
> Since this patchset is rather big, I didn't posted it by mail, but as
> suggested on the openwrt documentation, hosted these patches on a
> server.
>
> This serie of patches aims at using the Linux 3.16 kernel on the mv
Am 07.10.2014 um 11:49 schrieb Jo-Philipp Wich:
> Hi.
>
> In principle I have no objections but we need to figure out a way on how
> to deal with translation files. If stuff is split out of the LuCI repo
> you have to take of that yourself.
>
> ~ Jow
>
Hi.
I think about abandoning the LuCI Trac entirely and only accept patches
sent to the mailinglist, I lack time and resources to keep it running
and spam-free.
So please resend the patches to the LuCI list in case you haven't done
already and I'll try to get them merged until tomorrow.
~ Jow
__
Message: 1 Date: Tue, 7 Oct 2014 17:17:40 +0200 From: Bastian Bittorf
To: mailinglist
Subject: Re: [OpenWrt-Devel] Q:
mac80211: default distance-settings 0 Message-ID:
<20141007151740.gj29...@medion.lan> Content-Type: text/plain;
charset=us-ascii * Felix Fietkau [07.10.2014 13:40]:
On 2014
On Tue, 2014-10-07 at 19:24 +0200, Jo-Philipp Wich wrote:
> Hi.
>
> I think about abandoning the LuCI Trac entirely and only accept patches
> sent to the mailinglist, I lack time and resources to keep it running
> and spam-free.
>
> So please resend the patches to the LuCI list in case you haven'
Am 07.10.2014 um 20:16 schrieb Nikos Mavrogiannopoulos:
> On Tue, 2014-10-07 at 19:24 +0200, Jo-Philipp Wich wrote:
>> Hi.
>>
>> I think about abandoning the LuCI Trac entirely and only accept patches
>> sent to the mailinglist, I lack time and resources to keep it running
>> and spam-free.
>>
>> S
Am 07.10.2014 um 20:16 schrieb Nikos Mavrogiannopoulos:
> On Tue, 2014-10-07 at 19:24 +0200, Jo-Philipp Wich wrote:
>> Hi.
>>
>> I think about abandoning the LuCI Trac entirely and only accept patches
>> sent to the mailinglist, I lack time and resources to keep it running
>> and spam-free.
>>
>> S
[BB 14.07]
In the Luci section for "Interface / General Setup", the is a parameter
"Hostname to send when requesting DHCP". That input field has a "ghost"
value of $HOSTNAME (meaning to me that its default value is $HOSTNAME).
However, entering the $HOSTNAME in the field changes the behavior. I
i apologize for repeating some of what i asked on the users list
recently, but i'm rapidly running out of ideas and would be massively
grateful for any assistance.
just yesterday, i was handed an obvious development board, based on
the MT7620A processor, and MT7610EN radio chip, and was asked
Have gpio driver adopt irqdomain support so that there are
non-overlapping allocations of irq numbers mapped to gpio's.
Signed-off-by: Pushpal Sidhu
---
.../cns3xxx/files/arch/arm/mach-cns3xxx/gpio.c | 30 +-
1 file changed, 23 insertions(+), 7 deletions(-)
diff --git a/
On Tue, Oct 7, 2014 at 7:02 PM, Justin Vallon wrote:
> So either:
>
> 1) The dhcp hostname option should be blank to indicate no default value
> (maintain current behavior)
> 2) When udhcpc is invoked, it should pass "-H $(hostname)" in case of
> default (make backend behave as Luci implies)
> IMO
On Tue, Oct 7, 2014 at 7:06 PM, Robert P. J. Day wrote:
> finally, given that this board looks like *someone's* dev board,
> would anyone know where it might have come from? there's no
> manufacturer name on it anywhere. in the ramips dts file MT7620a.dts,
> i can see a reference to a "Ralink MT
Another thought-
Are you reading the version number from the chip themselves (hardware)?
How does the current openwrt bootlog identify them? Same way?
On Tue, Oct 7, 2014 at 5:51 PM, Aaron Z wrote:
> On Tue, Oct 7, 2014 at 7:06 PM, Robert P. J. Day
> wrote:
> > finally, given that this board
On 10/7/14 8:46 PM, Aaron Z wrote:
> On Tue, Oct 7, 2014 at 7:02 PM, Justin Vallon wrote:
>> So either:
>>
>> 1) The dhcp hostname option should be blank to indicate no default value
>> (maintain current behavior)
>> 2) When udhcpc is invoked, it should pass "-H $(hostname)" in case of
>> default
30 matches
Mail list logo
