Hi all,
since i didn't hear anything about this in the last 6 weeks i like to
ask, if there are any problems/concerns to add this?
I would be more than happy to help :)
Thanks alot and have a nice week!
Ben
Am 02.06.2014 09:26, schrieb Ben:
Hi everybody,
to deploy minimal OpenWrt images on
I've tried to test this on an ar2317, but the series isn't applying cleanly to
today's trunk.
I got the first one to succeed, with some fuzz, the second applied cleanly, but
the third failed, and I stopped
trying.
Cheers,
Karl P
2014-07-12 17:33 GMT+04:00 Sergey Ryazanov
On 14/07/2014 12:59, Xiongfei Guo wrote:
Hi, john,
How is the luci, which version the luci will be used. Teh devel? or
luci will bump to 0.12?
Xiongfei Guo Credo Semi.
On 07/14/2014 05:12 PM, John Crispin wrote:
The OpenWrt developers are proud to announce the first release
On 14 July 2014 17:12, John Crispin j...@phrozen.org wrote:
The OpenWrt developers are proud to announce the first release
candidate of OpenWrt Barrier Breaker.
___ __
| |.-.-.-.| | | |..| |_
| - || _ | -__| ||
On 14/07/2014 13:13, Yousong Zhou wrote:
On 14 July 2014 17:12, John Crispin j...@phrozen.org wrote:
The OpenWrt developers are proud to announce the first release
candidate of OpenWrt Barrier Breaker. ___
__ | |.-.-.-.| | | |..|
|_ | - ||
Good to see package feed on GitHub.
Would be great if there was a full OpenWRT source mirror on GitHub, for
some reason git.openwrt.org refuses connections on HTTPS, both from my home
and work IPs.
On Mon, Jul 14, 2014 at 1:12 PM, John Crispin j...@phrozen.org wrote:
The OpenWrt developers
On 14 July 2014 19:15, John Crispin j...@phrozen.org wrote:
On 14/07/2014 13:13, Yousong Zhou wrote:
On 14 July 2014 17:12, John Crispin j...@phrozen.org wrote:
The OpenWrt developers are proud to announce the first release
candidate of OpenWrt Barrier Breaker. ___
__ |
Hello,
I wondered if it makes sense to post about MicroPython, but recent post
about Squirrel language prompted me to. So, there's a project to
implement, from scratch, very lean interpreter for Python3 scripting
language.
The project is well under way and currently implements good deal of
On Mon, Jul 14, 2014 at 11:12:01AM +0200, John Crispin wrote:
The OpenWrt developers are proud to announce the first release
candidate of OpenWrt Barrier Breaker.
Excellent news, thanks!
* Native IPv6-support
- RA DHCPv6+PD client and server
- Local prefix allocation
Interesting, MicroPython is great. By the way, Luci2 doesn't use Lua at all.
On Mon, Jul 14, 2014 at 4:20 PM, Paul Sokolovsky pmis...@gmail.com wrote:
Hello,
I wondered if it makes sense to post about MicroPython, but recent post
about Squirrel language prompted me to. So, there's a project
Hi Baptiste,
in general our current firewalling approach is to keep defaults for IPv4
and IPv6 relatively close (not considering NAT here of course). Opening
up the IPv6 firewall by default would be unexpected and I don't really
like the approach for that matter and honestly I don't trust
On Mon, 2014-07-14 at 15:17:13 +0400, Nick Shvelidze wrote:
Good to see package feed on GitHub.
Would be great if there was a full OpenWRT source mirror on GitHub,
for some reason git.openwrt.org refuses connections on HTTPS, both
from my home and work IPs.
Look at here :-)
Hi Steven,
On Mon, Jul 14, 2014 at 02:38:16PM +0200, Steven Barth wrote:
Hi Baptiste,
in general our current firewalling approach is to keep defaults for IPv4 and
IPv6 relatively close (not considering NAT here of course).
Could you detail the reasoning behind this approach? Don't confuse
Hello all,
this is good news, however bad news is that brcm47xx (generic) target is
still seriously broken, at least on Asus WL-500W. The problem is
absolutely reproducible, and I reported it some time ago, but
unfortunately it attracted very little interest here for some reason.
Don't take
On Monday, July 14, 2014 12:00:01 PM openwrt-devel-requ...@lists.openwrt.org
wrote:
The OpenWrt developers are proud to announce the first release
candidate of OpenWrt Barrier Breaker.
Glad to know that Barrier Breaker will be ready to rock.
Would it possible to include my ticket #17028 here? I
On 14 July 2014 15:57, Nikolai Zhubr n-a-zh...@yandex.ru wrote:
Additionally, there is now another (less important) problem. In 14.07
ethernet ports of WL-500W get initially configured as if it was e.g.
wl-500gp:
- WAN is assigned to eth0.2 instead of eth1.
- WAN6 is assigned to some @wan.
On 21 June 2014 18:36, Nikolai Zhubr n-a-zh...@yandex.ru wrote:
[ 637.43] [ cut here ]
[ 637.44] WARNING: at net/core/dev.c:2194
skb_warn_bad_offload+0xc0/0xe8()
[ 637.45] b44: caps=(0x4000, 0x) len=1500
data_len=0
14.07.2014 18:34, Rafał Miłecki:
Please create a ticket with boot log, nvram show and your default
(broken) /etc/config/network.
Done,
https://dev.openwrt.org/ticket/17111
(Note: trac does not seem to know about rc1 yet, therefore I had to mark
it for trunk)
Thank you.
Nikolai
.
14.07.2014 18:42, Rafał Miłecki:
[...]
[ 637.56] Call Trace:
[ 637.56] [80010bb4] show_stack+0x48/0x70
[ 637.57] [80019bd4] warn_slowpath_common+0x78/0xa8
[ 637.57] [80019c30] warn_slowpath_fmt+0x2c/0x38
[ 637.58] [801b27dc] skb_warn_bad_offload+0xc0/0xe8
[ 637.58]
2014-07-14 14:31 GMT+04:00 Karl Palsson ka...@tweak.net.au:
I've tried to test this on an ar2317, but the series isn't applying cleanly
to today's trunk.
I got the first one to succeed, with some fuzz, the second applied cleanly,
but the third failed, and I stopped
trying.
Sounds
On 2014-07-14 16:42, Rafał Miłecki wrote:
On 21 June 2014 18:36, Nikolai Zhubr n-a-zh...@yandex.ru wrote:
[ 637.43] [ cut here ]
[ 637.44] WARNING: at net/core/dev.c:2194
skb_warn_bad_offload+0xc0/0xe8()
[ 637.45] b44: caps=(0x4000,
On 14/07/2014 15:56, Alive4Ever wrote:
On Monday, July 14, 2014 12:00:01 PM
openwrt-devel-requ...@lists.openwrt.org wrote:
The OpenWrt developers are proud to announce the first release
candidate of OpenWrt Barrier Breaker.
Glad to know that Barrier Breaker will be ready to rock. Would it
On Mon, Jul 14, 2014 at 6:23 PM, Felix Fietkau n...@openwrt.org wrote:
On 2014-07-14 16:42, Rafał Miłecki wrote:
On 21 June 2014 18:36, Nikolai Zhubr n-a-zh...@yandex.ru wrote:
[ 637.43] [ cut here ]
[ 637.44] WARNING: at net/core/dev.c:2194
Hello,
* Claudio Leite (lei...@staticky.com) wrote:
Use pr_debug rather than pr_info since it is only relevant
for debugging.
Signed-off-by: Claudio Leite lei...@staticky.com
While we are talking about things for Barrier Breaker RC's, could this
patch be merged in? It was marked as accepted
2014-07-14 14:31 GMT+04:00 Karl Palsson ka...@tweak.net.au:
I've tried to test this on an ar2317, but the series isn't applying cleanly
to today's trunk.
I got the first one to succeed, with some fuzz, the second applied cleanly,
but the third failed, and I stopped
trying.
You right. I
ok, no idea why it is not in trunk but marked as accepted but i would
assume its my fault
thanks, merged in r41653
On 14/07/2014 18:55, Claudio Leite wrote:
Hello,
* Claudio Leite (lei...@staticky.com) wrote:
Use pr_debug rather than pr_info since it is only relevant for
debugging.
On 14/07/2014 19:05, Sergey Ryazanov wrote:
John, please, could you reject this series? I will send new one.
i just marked it as Changes Requested
John
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
Hello,
On Mon, 14 Jul 2014 16:29:42 +0400
Nick Shvelidze capt...@pirrate.me wrote:
Interesting, MicroPython is great. By the way, Luci2 doesn't use Lua
at all.
Yes, I heard from other replies, that's good news, hope it will be
ready for prime time soon.
Still, it would be nice to have good
Hi Sergey,
the oldpackages feed is unsupported and will not be updated any more.
If you want to submit packages or adopt packages from oldpackages which
are not there yet please go to https://github.com/openwrt/packages and
make a pull request there.
Cheers,
Steven
Hi.
Yes, I heard from other replies, that's good news, hope it will be
ready for prime time soon.
Still, it would be nice to have good unbloated language for rapid app
development in constrained environments, like most routers on which
OpenWRT runs. I made initial proof of concept web
Move eeprom extraction from scripts to dts files.
Additionally there are few other changes like:
- whitespace fixes
- add partition labels where needed
- BR6524N board doesn't exist (lost in translation?)
- fix Edimax 3g-6200nl model
- add wmac eeprom to dts for Asus RT-N14U board
Compile tested
14.07.2014 20:44, Jonas Gorski:
[...]
If I were to speculate wildly, I would guess that B44_RXMAXLEN refers to
the maximum frame length, not the maximum buffer length - and in the
code, it's being fed with the maximum buffer length.
This would allow the hardware to receive slightly oversized
Hello,
On Mon, 14 Jul 2014 22:16:03 +0200
Jo-Philipp Wich j...@openwrt.org wrote:
Hi.
Yes, I heard from other replies, that's good news, hope it will be
ready for prime time soon.
Still, it would be nice to have good unbloated language for rapid
app development in constrained
On 14 July 2014 18:44, Jonas Gorski j...@openwrt.org wrote:
On Mon, Jul 14, 2014 at 6:23 PM, Felix Fietkau n...@openwrt.org wrote:
It looks to me like the hardware is overwriting the skb shared info (at
the end of the skb data buffer), possibly because the configured maximum
frame length may
Hi everyone,
Le lundi 14 juillet 2014 à 22:17 +0900, Baptiste Jonglez a écrit :
On Mon, Jul 14, 2014 at 02:38:16PM +0200, Steven Barth wrote:
Hi Baptiste,
in general our current firewalling approach is to keep defaults for IPv4 and
IPv6 relatively close (not considering NAT here of
On Mon, Jul 14, 2014 at 11:48 PM, Nikolai Zhubr n-a-zh...@yandex.ru wrote:
14.07.2014 20:44, Jonas Gorski:
[...]
If I were to speculate wildly, I would guess that B44_RXMAXLEN refers to
the maximum frame length, not the maximum buffer length - and in the
code, it's being fed with the maximum
Main goals of this series:
* Simplify interface between arch code and SoC drivers
* Simplify internal realization of arch code
* Make code consistent with mainstream kernel rules and practice
This series extensively tested with FON2202 (ar2315 based) and D-Link
DWL-2100AP (ar2313 based), but
Acknowledge watchdog interrupt in arch irq dispatcher and remove odd
watchdog enable call from probe function.
Signed-off-by: Sergey Ryazanov ryazanov@gmail.com
---
target/linux/atheros/patches-3.10/100-board.patch| 7 ---
target/linux/atheros/patches-3.10/130-watchdog.patch | 5
Make sparse happy :)
Signed-off-by: Sergey Ryazanov ryazanov@gmail.com
---
target/linux/atheros/patches-3.10/100-board.patch | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/target/linux/atheros/patches-3.10/100-board.patch
* update driver id to be consistent with other ar231x drivers
* remove odd module_{init,exit}
* add module metadata (description, name, etc.)
Signed-off-by: Sergey Ryazanov ryazanov@gmail.com
---
target/linux/atheros/patches-3.10/100-board.patch | 2 +-
Rename config symbol to AR2315_WDT to avoid confusion with other Atheros
SoCs.
Signed-off-by: Sergey Ryazanov ryazanov@gmail.com
---
target/linux/atheros/config-3.10 | 2 +-
target/linux/atheros/patches-3.10/130-watchdog.patch | 11 ++-
2 files changed, 7
Rename interrupt control handlers to be consistent with operation names
and add IRQ chips names.
Signed-off-by: Sergey Ryazanov ryazanov@gmail.com
---
target/linux/atheros/patches-3.10/100-board.patch | 45 ---
1 file changed, 24 insertions(+), 21 deletions(-)
diff --git
* Pass iomem and IRQ via platform device resources
* Remap iomem and use iowrite32 accessor function
Signed-off-by: Sergey Ryazanov ryazanov@gmail.com
---
target/linux/atheros/patches-3.10/100-board.patch | 17 +++-
.../linux/atheros/patches-3.10/130-watchdog.patch | 45
Align code with AR5312 realization.
Signed-off-by: Sergey Ryazanov ryazanov@gmail.com
---
target/linux/atheros/patches-3.10/100-board.patch | 47 --
.../atheros/patches-3.10/105-ar2315_pci.patch | 15 +++
2 files changed, 34 insertions(+), 28 deletions(-)
diff
Move driver code to respective vendor subdirectory and fix config
symbol name.
Signed-off-by: Sergey Ryazanov ryazanov@gmail.com
---
target/linux/atheros/config-3.10 | 2 +-
.../atheros/patches-3.10/110-ar2313_ethernet.patch | 59 +++---
Pass reset_set and reset_clear callback functions pointers via
platform_data instead of reset register address.
Signed-off-by: Sergey Ryazanov ryazanov@gmail.com
---
target/linux/atheros/patches-3.10/100-board.patch | 49 ++
Signed-off-by: Sergey Ryazanov ryazanov@gmail.com
---
target/linux/atheros/patches-3.10/100-board.patch | 34 +++---
.../atheros/patches-3.10/105-ar2315_pci.patch | 6 ++--
2 files changed, 14 insertions(+), 26 deletions(-)
diff --git
Currently AR5312 misc IRQ numbers are used for AR2315+ chips, what cause
us to use switch-case to map IRQ number to ISR bit. Introduce AR2315
specific misc IRQs set and simplify interrupt (un)mask operation.
Signed-off-by: Sergey Ryazanov ryazanov@gmail.com
---
Each SoCs generation has own independent gpiolib realization, so we
have no reason to keep these realizations in semiuniversal form.
Following modifications are made:
* Remove valid_mask field
* Remove ar231x_gpio_chip structure
* Rename AR2315_GPIO_CR to AR2315_GPIO_DIR
* Fix count of AR5312
Signed-off-by: Sergey Ryazanov ryazanov@gmail.com
---
target/linux/atheros/patches-3.10/100-board.patch| 20 ++--
.../atheros/patches-3.10/110-ar2313_ethernet.patch | 19 ---
.../patches-3.10/220-enet_micrel_workaround.patch| 6 +++---
3 files
Use 32-bit aligned I/O and update base UART address (remove +3 offset).
Signed-off-by: Sergey Ryazanov ryazanov@gmail.com
---
target/linux/atheros/patches-3.10/100-board.patch| 6 +++---
target/linux/atheros/patches-3.10/101-early-printk-support.patch | 4 ++--
2 files
Pass only physical address to 8250 serial port driver and set flag to
remap I/O memory inside the driver. Also fix AR5312 UART base address
definition, which seems specified already mapped.
Signed-off-by: Sergey Ryazanov ryazanov@gmail.com
---
Pass PHY I/O memory region via platform resources and remap them
unconditionally.
Signed-off-by: Sergey Ryazanov ryazanov@gmail.com
---
target/linux/atheros/patches-3.10/100-board.patch | 57 ++
.../atheros/patches-3.10/110-ar2313_ethernet.patch | 48 +++---
Use AR2315_ prefix for macroses specific to AR2315/AR2316/AR2317 chips,
use AR5312_ prefix for macroses specific to AR5312/AR2312/AR2313 chips,
and use AR231X_ prefix for common macroses.
This patch should not cause any functional changes, only make clear
which macros is common and which macros
2014-07-14 21:05 GMT+04:00 Sergey Ryazanov ryazanov@gmail.com:
2014-07-14 14:31 GMT+04:00 Karl Palsson ka...@tweak.net.au:
I've tried to test this on an ar2317, but the series isn't applying cleanly
to today's trunk.
I got the first one to succeed, with some fuzz, the second applied
55 matches
Mail list logo
