Hi All,
I am trying to split the toolchain out of my main openwrt build, after
generating the toolchain i moved it to a new location from
staging_dir/toolchain-powerpc_gcc-4.3.3_glibc-2.7 and set up and new
build that points to the toolchain.
I am using Revision: 20023.
Is there any think that I
This patch adds an option to menuconfig for ifxmips-dsl-api to enable/disable
the debug output. By default the debug output is switched off.
Signed-off-by: Ithamar R. Adema
---
package/ifxmips-dsl-api/Config.in |5 +
package/ifxmips-dsl-api/Makefile |9
On Fri, 2010-03-12 at 14:06 -0600, Bruno Wolff III wrote:
> I took a look at the backfire beta a few days ago to see if there was
> ebtables support and ifb support. I didn't find either, but I am seeing
> ebtables support in the snapshots, so i will assume it will be there in
> the end.
As I unde
Committed r20191.
Travis
On Wed, Mar 10, 2010 at 1:51 PM, Stefan Monnier
wrote:
> Simple typo.
>
>
> Stefan
>
>
> Index: net/dhcp-forwarder/files/dhcp-fwd.init
> ===
> --- net/dhcp-forwarder/files/dhcp-fwd.init (révision
We will not update busybox before the next release unless there is a need to.
Travis
On Tue, Mar 9, 2010 at 10:57 AM, Peter Wagner wrote:
> Hi,
>
> this is my busybox update patch...
>
> please apply
>
> greets
>
> ___
> openwrt-devel mailing list
> op
Committed r20190.
Travis
On Mon, Mar 8, 2010 at 2:10 PM, wrote:
> find attached the announced patch for fuse.
> changes:
> - latest fuse 2.8.3
> - includes now the kernel module for kernel 2.4
> - builds parallel
> - fuse-utils includes now ulockmgr_server
>
> fuse24 should be deleted from trun
Committed r20189.
Travis
2010/3/8 Raphaël HUCK :
> Hi,
>
> this patches fixes iproute2 parallel build.
>
> -Raphael
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
>
_
committed r20188.
Travis
2010/3/8 Raphaël HUCK :
> Hi,
>
> this patch fixes iptables parallel build.
>
> -Raphael
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
>
___
Committed r20187.
Travis
2010/3/8 Raphaël HUCK :
> Hi,
>
> this patch fixes gdb parallel build.
>
> -Raphael
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
>
Committed r20186.
Travis
2010/3/8 Raphaël HUCK :
> Hi,
>
> this patch fixes openssl parallel build.
>
> -Raphael
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
>
Committed in r20185. Sorry for the delay in committing it.
Travis
On Sat, Mar 13, 2010 at 7:19 PM, Matthias Buecher / Germany
wrote:
> Switch Marvell Orion CPU to kernel 2.6.32 plus LED support for all LEDs
> on LinkSys WRT350Nv2.
>
> Signed-off by: Matthias Buecher and Dirk Teurlings
>
>
>
>
Switch Marvell Orion CPU to kernel 2.6.32 plus LED support for all LEDs
on LinkSys WRT350Nv2.
Signed-off by: Matthias Buecher and Dirk Teurlings
Several forum members and I are running 2.6.32 on Marvell Orion CPU
since January without any problems.
Unfortunately Orion CPU feels a little abando
Signed-off-by: Ithamar R. Adema
---
package/br2684ctl/files/br2684ctl |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/package/br2684ctl/files/br2684ctl
b/package/br2684ctl/files/br2684ctl
index 739baab..7ba7044 100755
--- a/package/br2684ctl/files/br2684ctl
+++ b/pack
Hi
On 14 March 2010 00:07, Joerg Albert wrote:
> On 03/13/2010 09:29 PM, Jonas Gorski wrote:
> The revision of the AR7240 is 2. Another way to identify the device may be
> the ID of the
> integrated PHYs (AR7240 004d:d041)
If the revision is different we can use that. Unfortunately the ar8316
a
On 03/13/2010 09:29 PM, Jonas Gorski wrote:
> I am currently adapting the ar8216 driver to support the ar8316[1],
> and therefore it probably the best to combine the effort (and there
> won't be a race whose patch gets accepted first ;-).
Must have missed this thread searching for ar7240 only. I'
This fixes the following BUG:
BUG: sleeping function called from invalid context at mm/slab.c:3055
in_atomic(): 0, irqs_disabled(): 1, pid: 253, name: dd
1 lock held by dd/253:
#0: (&state->mutex){..}, at: [<80148294>] uart_open+0x7c/0x448
Call Trace:
[<8000a1ac>] dump_stack+0x8/0x34
[<8008a
This enables ifxmips-based devices to make use of the switch infrastructure too.
Signed-off-by: Ithamar R. Adema
---
.../ifxmips/patches-2.6.30/130-ethernet.patch | 121 ++--
1 files changed, 111 insertions(+), 10 deletions(-)
diff --git a/target/linux/ifxmips/patches-2.6.
Use ifxmips_mtd->erasesize instead of numeric constant for rounding the uImage
size to the next erase block. The code will now handle erase block sizes other
then 64k correctly.
Tested with 128k erasesize.
Signed-off-by: Ithamar R. Adema
---
target/linux/ifxmips/patches-2.6.30/140-mtd.patch |
This patchset implements PHY support for ifxmips devices, some more PCI
controller configurability, and fixes a few bugs. For details, see the
individual patches.
Ithamar R. Adema (6):
[ifxmips] Implement PHY support for ethernet driver.
[ifxmips] Calculate PCI BARMASK11 register value dynam
Signed-off-by: Ithamar R. Adema
---
target/linux/ifxmips/image/Makefile |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/target/linux/ifxmips/image/Makefile
b/target/linux/ifxmips/image/Makefile
index 15e0bc5..67037c9 100644
--- a/target/linux/ifxmips/image/Makefile
+
The PCI BARMASK11 register defines how much memory is accessible from a PCI
Master on the PCI bus. This is dependent on the amount of memory installed on
the device, so calculate it instead of hardcoding the value for 32M devices.
Signed-off-by: Ithamar R. Adema
---
.../ifxmips/files/arch/mips
Since ifxmips_find_board() uses chiprev to detect what board we're running on,
we should retrieve chiprev _first_ and only then call ifxmips_find_board().
Signed-off-by: Ithamar R. Adema
---
.../linux/ifxmips/files/arch/mips/ifxmips/board.c |4 +++-
1 files changed, 3 insertions(+), 1 dele
As the pins used for PCI REQ signals can be reused for other purposes, make it
possible for boards to specify which REQ pins are truly available for use by
the PCI controller. This prevents signals on those pins used for other purposes
to not cause PCI Master Aborts and similar errors.
Signed-o
Hi
On 13 March 2010 18:31, Joerg Albert wrote:
> I guess we need swconfig support for the built-in switch (if possible). I'll
> try to adapt the 8216
> code.
I am currently adapting the ar8216 driver to support the ar8316[1],
and therefore it probably the best to combine the effort (and there
w
On 03/02/2010 12:04 AM, Dennis Bartsch wrote:
> But my question is left to be answered. Does this bridge which is
> created over the LAN-ports really mean that the CPU is doing the
> bridging?? Performance-wise this would be a bad behaviour.
Looks like this. With svn r20176 and two PC on LAN por
There are some problem with setuptools whie compile deluge
http://pastebin.com/4JBqcd8b
--
Pozdrawiam, Artur
http://artekw.net / GG: 151817 / JID: art...@jabbim.pl
http://digi-led.pl
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https:
26 matches
Mail list logo
