Re: [OpenWrt-Devel] Build logs of Barrier Breaker RCs
narf, i deleted the rc3 folder last night so i can build the next iteration this week. i do not recall seeing fastd in the list of failed packages. i will have a look out for it and ping you if i see any breakage On 01/09/2014 01:02, Matthias Schiffer wrote: Hi, I've noticed that the package fastd (which I maintain) is missing from some targets in all Barrier Breaker RCs, for example on x86. It does exist though on ar71xx, and everything is fine in the current trunk snapshots. I can't find any issues when building BB myself either. Are the build logs available somewhere so I can find out what is wrong? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] compatible = ralink,mt7620a-spi, ralink,rt2880-spi;
just checked the code and the datasheet and there is a register init
missing i think, i will dig into this during the week
On 01/09/2014 08:25, John Crispin wrote:
Hi,
that patch subject is utterly wrong. the real desc would be
add support for the 2nd CS line on mt7620a and add a special
device_id for this.
however, as you only register the CS with the spi driver and are
missing the actuall /cs1 mux init, this patch is wrong/incomplete as
it relies on the bootloader to have setup the cs line already and has
a misleading desription.
John
On 31/08/2014 22:55, Luis Soltero wrote:
Hello All,
the mt7620a.dtsi makes reference to mt7620a-spi but this node does
not exist in spi.c. The following patch address this.
here is the entry in the dts file... spi@b00 {
compatible = ralink,mt7620a-spi, ralink,rt2880-spi;
reg = 0xb00 0x100;
resets = rstctrl 18;
reset-names = spi;
#address-cells = 1;
#size-cells = 1;
status = disabled;
pinctrl-names = default;
pinctrl-0 = spi_pins;
};
the following mus be added to the DTS file to use it.
spi@b00 {
status = okay;
num-cs = 2;
m25p80@0 { snip
here is the patch.
--luis
___ openwrt-devel
mailing list openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH][RFC]mac80211: rt2x00 correctly set ht20/ht40 filter
On 01/09/2014 01:22, Daniel Golle wrote: Hi Serge! Please do not send HTML emails. Your submissions are not useful for anyone if the mail body is HTML formatted and your mail application corrupted the white-space formatting. That's sad because your work will not be appreciated due to formalities which are easy to fulfil. Please read https://dev.openwrt.org/wiki/SubmittingPatches and have a look at the archive to get an impression why this is needed: https://lists.openwrt.org/pipermail/openwrt-devel/2014-August/027718.html also note that your patch was dropped by patchwork.openwrt.org for the same reasons and thus cannot be easily applied and merged. I suggest you should consider using git send-email to avoid these difficulties in future. It required quite some manual work to even read your patch. First of all, your patch applies to rt2x00, so please send it to the rt2x00 users mailing list. http://rt2x00.serialmonkey.com/mailman/listinfo/users_rt2x00.serialmonkey.com To add it to patches applied to mac80211 in OpenWrt, you'd have to create a patch adding a patch-file to package/kernel/mac80211/patches/ Please read http://wiki.openwrt.org/doc/devel/patches Anyway, I'm still glad you figured out why rt2x00 performs bad in HT40 mode on these chips. Thank you for that! I manually applied your patch and am about to test it on DIR-615-H1 ;) Cheers Daniel Hi, valid critique, i am manually merging it into BB and CC now. please do not use html emails next time John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] uClibc bug: epoll_pwait broken on OpenWrt x86
Sure, I've attached my testcase (source and compiled for Barrier Breaker).
Matthias
On 09/01/2014 08:31 AM, Waldemar Brodkorb wrote:
Hi,
can you provide a simple testcase showing the bug?
best regards
Waldemar
Am 01.09.2014 um 00:53 schrieb Matthias Schiffer
mschif...@universe-factory.net:
Hi,
I'm posting this on both the OpenWrt and the uClibc lists to hopefully
find someone who has an idea how the code in question might ever have
worked (if it ever has...). The issue probably affects not only
epoll_pwait, but also other syscall6 on i386. It can be seen on all
OpenWrt versions ranging from Attitude Adjustment to Barrier Breaker
(and probably also the current trunk).
I noticed that epoll_pwait always returns EINVAL when I supply a signal
set; analzing it with gdb I found out that %ebp contains a stack address
instead of the length of the signal set (which should be 8).
Looking at the generated code reveals this:
b360 __libc_epoll_pwait:
b360: 55 push %ebp
b361: 57 push %edi
b362: 56 push %esi
b363: 53 push %ebx
b364: 51 push %ecx
b365: e8 eb ef ff ff call a355 __x86.get_pc_thunk.bx
b36a: 81 c3 8a 4c 04 00 add$0x44c8a,%ebx
b370: 8b 74 24 24 mov0x24(%esp),%esi
b374: 8b 7c 24 28 mov0x28(%esp),%edi
b378: c7 04 24 08 00 00 00movl $0x8,(%esp) #1
b37f: 65 a1 0c 00 00 00 mov%gs:0xc,%eax
b385: 85 c0 test %eax,%eax
b387: 75 33 jneb3bc
__libc_epoll_pwait+0x5c
b389: 8b 44 24 18 mov0x18(%esp),%eax
b38d: 8b 4c 24 1c mov0x1c(%esp),%ecx
b391: 8b 54 24 20 mov0x20(%esp),%edx
b395: 53 push %ebx #2
b396: 89 c3 mov%eax,%ebx
b398: 55 push %ebp #3
b399: 8b 2c 24mov(%esp),%ebp #4
b39c: b8 3f 01 00 00 mov$0x13f,%eax
b3a1: cd 80 int$0x80
...
As can be seen, the value 8 is moved onto the stack at #1 and is
supposed to be moved to %ebp at #4. Unfortunately, #2 and #3 move the
stack pointer...
___
uClibc mailing list
ucl...@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
epoll_test
Description: Binary data
#include sys/epoll.h
#include unistd.h
#include signal.h
#include stdio.h
int main() {
int efd = epoll_create1(0);
struct epoll_event event = { .events = EPOLLIN };
epoll_ctl(efd, EPOLL_CTL_ADD, STDIN_FILENO, event);
sigset_t set;
sigemptyset(set);
if (epoll_pwait(efd, event, 1, 1000, set) 0)
perror(epoll_pwait);
return 0;
}
signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] lantiq: BTHOMEHUBV2B use bigger mtd partition for kernel
On Wed, 2014-08-27 at 08:43 +0200, Ben Mulvihill wrote: The bb-rc3 image for the BTHOMEHUBV2B is too big for its mtd partition. This patch corrects the partition sizes in the device tree. This patch should really go in before bb-final, otherwise the BTHOMEHUBV2B images won't be useable. I do apologise for not spotting this straight away. Many thanks, Ben Hi, I see this has been merged with changeset 42316. Many thanks for that. But at the moment it is only in trunk, not BB branch. Should I do anything else to get it included there as well? Many thanks, Ben ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] lantiq: BTHOMEHUBV2B use bigger mtd partition for kernel
On 01/09/2014 12:41, Ben Mulvihill wrote: On Wed, 2014-08-27 at 08:43 +0200, Ben Mulvihill wrote: The bb-rc3 image for the BTHOMEHUBV2B is too big for its mtd partition. This patch corrects the partition sizes in the device tree. This patch should really go in before bb-final, otherwise the BTHOMEHUBV2B images won't be useable. I do apologise for not spotting this straight away. Many thanks, Ben Hi, I see this has been merged with changeset 42316. Many thanks for that. But at the moment it is only in trunk, not BB branch. Should I do anything else to get it included there as well? Many thanks, Ben wait for another hour. i will push it today with the other ~75 backports. i am just doing some test builds before the push ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] lantiq: BTHOMEHUBV2B use bigger mtd partition for kernel
Brilliant! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH][RFC]mac80211: rt2x00 correctly set ht20/ht40 filter
I'm double sorry. My patch need sed 's/RF3320/RF3322/g' :(. 01.09.2014, 17:04, "John Crispin" blo...@openwrt.org:On 01/09/2014 01:22, Daniel Golle wrote: Hi Serge! Please do not send HTML emails. Your submissions are not useful for anyone if the mail body is HTML formatted and your mail application corrupted the white-space formatting. That's sad because your work will not be appreciated due to formalities which are easy to fulfil. Please read https://dev.openwrt.org/wiki/SubmittingPatches and have a look at the archive to get an impression why this is needed: https://lists.openwrt.org/pipermail/openwrt-devel/2014-August/027718.htmlalso note that your patch was dropped by patchwork.openwrt.org for the same reasons and thus cannot be easily applied and merged. I suggest you should consider using git send-email to avoid these difficulties in future. It required quite some manual work to even read your patch. First of all, your patch applies to rt2x00, so please send it to the rt2x00 users mailing list. http://rt2x00.serialmonkey.com/mailman/listinfo/users_rt2x00.serialmonkey.com To add it to patches applied to mac80211 in OpenWrt, you'd have to create a patch adding a patch-file to package/kernel/mac80211/patches/ Please read http://wiki.openwrt.org/doc/devel/patches Anyway, I'm still glad you figured out why rt2x00 performs bad in HT40 mode on these chips. Thank you for that! I manually applied your patch and am about to test it on DIR-615-H1 ;) Cheers DanielHi,valid critique, i am manually merging it into BB and CC now. please donot use html emails next timeJohn___openwrt-devel mailing listopenwrt-devel@lists.openwrt.orghttps://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ---serge ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] compatible = ralink,mt7620a-spi, ralink,rt2880-spi;
Hello John,
OK. thanks for our comments. So... is it worth pursuing this to get it right
or is it so wrong that we should just
forget it and retract the whole thing? Your mesg is unclear. Let me know what
you want me to do.
Thanks,
--luis
On 9/1/14, 2:25 AM, John Crispin wrote:
Hi,
that patch subject is utterly wrong. the real desc would be
add support for the 2nd CS line on mt7620a and add a special
device_id for this.
however, as you only register the CS with the spi driver and are
missing the actuall /cs1 mux init, this patch is wrong/incomplete as
it relies on the bootloader to have setup the cs line already and has
a misleading desription.
John
On 31/08/2014 22:55, Luis Soltero wrote:
Hello All,
the mt7620a.dtsi makes reference to mt7620a-spi but this node does
not exist in spi.c. The following patch address this.
here is the entry in the dts file... spi@b00 {
compatible = ralink,mt7620a-spi, ralink,rt2880-spi;
reg = 0xb00 0x100;
resets = rstctrl 18;
reset-names = spi;
#address-cells = 1;
#size-cells = 1;
status = disabled;
pinctrl-names = default;
pinctrl-0 = spi_pins;
};
the following mus be added to the DTS file to use it.
spi@b00 {
status = okay;
num-cs = 2;
m25p80@0 { snip
here is the patch.
--luis
___ openwrt-devel
mailing list openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
--
Luis Soltero, Ph.D., MCS
Director of Software Development, CTO
Global Marine Networks, LLC
StarPilot, LLC
Tel: +1.865.379.8723
Fax: +1.865.681.5017
E-Mail: lsolt...@globalmarinenet.net
Web: http://www.globalmarinenet.net
Web: http://www.redportglobal.com
Web: http://www.starpilotllc.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] compatible = ralink,mt7620a-spi, ralink,rt2880-spi;
Hi Luis,
i am planning to look at this during the week as i need to fix up spi
support for mt7628 anyhow. i will look at this at the same time
John
On 01/09/2014 16:51, Luis Soltero wrote:
Hello John,
OK. thanks for our comments. So... is it worth pursuing this to
get it right or is it so wrong that we should just forget it and
retract the whole thing? Your mesg is unclear. Let me know what
you want me to do.
Thanks,
--luis
On 9/1/14, 2:25 AM, John Crispin wrote:
Hi,
that patch subject is utterly wrong. the real desc would be
add support for the 2nd CS line on mt7620a and add a special
device_id for this.
however, as you only register the CS with the spi driver and are
missing the actuall /cs1 mux init, this patch is wrong/incomplete
as it relies on the bootloader to have setup the cs line already
and has a misleading desription.
John
On 31/08/2014 22:55, Luis Soltero wrote:
Hello All,
the mt7620a.dtsi makes reference to mt7620a-spi but this node
does not exist in spi.c. The following patch address this.
here is the entry in the dts file... spi@b00 {
compatible = ralink,mt7620a-spi, ralink,rt2880-spi;
reg = 0xb00 0x100;
resets = rstctrl 18;
reset-names = spi;
#address-cells = 1;
#size-cells = 1;
status = disabled;
pinctrl-names = default;
pinctrl-0 = spi_pins;
};
the following mus be added to the DTS file to use it.
spi@b00 {
status = okay;
num-cs = 2;
m25p80@0 { snip
here is the patch.
--luis
___ openwrt-devel
mailing list openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 3/3] ar71xx: correctly detect hardware revision on TP-LINK Archer C5 and C7
Signed-off-by: Matthias Schiffer mschif...@universe-factory.net
---
target/linux/ar71xx/base-files/lib/ar71xx.sh | 7 +++
1 file changed, 7 insertions(+)
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index 18e07a4..f188578 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -214,6 +214,13 @@ tplink_board_detect() {
934100*)
model=NC-LINK SMART-300
;;
+ c5*)
+ model=TP-Link Archer C5
+ ;;
+ 75*|\
+ c7*)
+ model=TP-Link Archer C7
+ ;;
*)
hwver=
;;
--
2.1.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/3] ar71xx: simplify TP-LINK model detection
All TP-LINK machine names begin with TP-LINK, so there's no need to check for
more specific model names. This also allows adding new models like the Archer
series more easily.
Signed-off-by: Matthias Schiffer mschif...@universe-factory.net
---
target/linux/ar71xx/base-files/lib/ar71xx.sh | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index 1e96b6d..d26ac3d 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -744,11 +744,7 @@ ar71xx_board_detect() {
;;
esac
- case $machine in
- *TL-WR* | *TL-WA* | *TL-MR* | *TL-WD*)
- tplink_board_detect $machine
- ;;
- esac
+ [ ${machine:0:8} = 'TP-LINK ' ] tplink_board_detect $machine
[ -z $name ] name=unknown
--
2.1.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/3] ar71xx: fix syntax for TP-LINK TL-WR941N/ND / Rosewill RNX-N360RT detection
[ ] conditions should use = instead of == for string equality.
Signed-off-by: Matthias Schiffer mschif...@universe-factory.net
---
target/linux/ar71xx/base-files/lib/ar71xx.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index d26ac3d..18e07a4 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -152,7 +152,7 @@ tplink_board_detect() {
model=TP-Link TL-WA901N/ND
;;
094100*)
- if [ $hwid == 09410002 -a $mid == 00420001 ]; then
+ if [ $hwid = 09410002 -a $mid = 00420001 ]; then
model=Rosewill RNX-N360RT
hwver=
else
--
2.1.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 6in4 does not recover after wan outage
On 26 Aug 2014 03:52, Richard Mortimer richm+open...@oldelvet.org.uk wrote: Hi, On 23/08/2014 00:19, Weedy wrote: On Fri, Aug 22, 2014 at 9:15 AM, Richard Mortimer richm+open...@oldelvet.org.uk wrote: However I've noticed that if the ADSL line drops then when it recovers my SiXXS 6in4 tunnel does not automatically re-establish the connection. Incase you need it fixed now, here's a workaround. Throw this in like /etc/hotplug.d/iface/99-6in4-fix. Many thanks. I've tested that and it does indeed workaround the problem. Best Regards No problem. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] compatible = ralink,mt7620a-spi, ralink,rt2880-spi;
Hello John,
I have confirmed that the patch is totally bogus and should be ignored.
Having said that there are some issues that I
think need to be looked at.
interestingly enough this all came about as I tried to add a second SPI device
to the MT7620a... Much like what is
discussed here
http://comments.gmane.org/gmane.comp.embedded.openwrt.devel/24633
what i found is that when looking at the SPI definition in mt7620a.dtsi
spi@b00
{
compatible = ralink,mt7620a-spi, ralink,rt2880-spi;
reg = 0xb00
0x100;
resets = rstctrl
18;
reset-names =
spi;
#address-cells =
1;
#size-cells =
1;
status =
disabled;
pinctrl-names =
default;
pinctrl-0 =
spi_pins;
};
that
a) there is no entry ralink,mt7620a-spi in mt7620.c which is what I was
trying to address in my patch (albeit incorrectly)
b) using the original mt7620.c its possible to use ralink,mt5350-spi which
has num_cs set to 2.
c) that ralink,rt2880-spi must be removed from the compatibility list or a
cs1 = max cs error will result on
initialization resulting in the second device not being registered.
So
spi@b00
{
compatible =
ralink,mt5350-spi
reg = 0xb00
0x100;
resets = rstctrl
18;
reset-names =
spi;
#address-cells =
1;
