[OpenWrt-Devel] [Bug: Busybox 1.22.1] false return 0 instead of 1 with '--help' switch.
I'm using an embedded system with busybox v1.22.1, running Openwrt Chaos Chalmer r42321, mips24k AR9330 When I call 'busybox false --help', the return status is zero. I think it has nothing todo with openwrt, because it's the output of busybox, not the problem on openwrt performance. I feel it's strange, because GNU coreutils false binary gives return status 1, even when invoked with '--help' switch. I also notice that Ubuntu busybox false, which is version 1.21.1 performs the same behaviour as GNU coreutils. Since /bin/false is linked to busybox and configured to disable login for daemon users, it will pose s security hole if this zero return status is exploited. I mark this as bug because busybox false doesn't return 'false'. Is this behaviour intended with busybox false implementation? Thanks. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] mt7620a serial port driver ordering of nodes uart/uartlite vs ttyS0/ttyS1 patch
hm... it still seems that the board integrator should be able to determine the
node name for the device. Implementing a
scheme based on base address still hard wires the node name to the port and
does not provide the flexibility of changing
it.Absolutely depending on the load order is quirky... however knowing that
gives you some flexibility in the naming.
I think the real answer is to add a property that allows you to specify the
order. Then you can order the devices
however you like.
i worry that implementing something on the base address is actually worse than
what we currently have.
look forward to your thoughts.
--luis
On 8/30/14, 2:35 AM, John Crispin wrote:
> Hi
>
> On Lantiq we derive the port numbering from the base addr that gets
> used for early printk. i will implement a similar solution for ralink.
> having to rely on the load order seems quirky.
>
> John
>
> On 29/08/2014 23:56, Luis Soltero wrote:
>> Hello All,
>>
>> Most mt7620a routers defined in the target/linux/ramips/dts have
>> exactly one serial port defined which is used for the console. The
>> serial port driver links this to node /dev/ttyS0.
>>
>> However. one (and now 2) devices use the mt7620a serial port lines
>> for use as a second real serial port (uart@500 in the dts).
>> Currently when when more than one serial port is defined the boot
>> sequence starts with the console attached to uartlite but as soon
>> as the serial port driver driver is loaded it deactivates the
>> console and assigns it to /dev/ttyS1 (which is the node created for
>> uartlite). So on these systems using the standard dts
>> configuration the mt7620a enhanced uart is bound to /dev/ttyS0 and
>> uartlite is bound /dev/ttyS1.
>>
>> This causes the console serial port to stop displaying output
>> unless the following is added to the dts definition
>>
>> chosen { bootargs = "console=ttyS1,57600"; };
>>
>> which redefines the console to /dev/ttyS1... this configuration
>> works fine. However some (including me) find this very
>> irritating. These few routers defining a second serial port differ
>> from all the others in their definition of /dev/ttyS0 as the
>> console.
>>
>> So... for consistency it seems that it would be much better for **
>> ALL ** routers regardless of the number of serial ports define
>> /dev/ttyS0 as the console port.
>>
>> The reason for the renumbering is due to the serial port driver to
>> assign nodes on a first come first basis in the dts definition.
>> Since in mt7620a.dtsi (included by most/all 7620a router board
>> definitions) the definition for uart@500 is before that for
>> uartlite@00. So uart gets assigned /dev/ttyS0 while uartlite gets
>> /dev/ttyS1. You can't fault the serial driver for doing it. After
>> all it really doesn't know for what purpose the serial port is to
>> be used.
>>
>> A logical extension to the serial port dts properties would be to
>> add a "node-name" or "node-order" or "node-number" property that
>> would allow the integrator to specify the node number or the node
>> name for the serial port. However these properties don't exist (or
>> at least they were not obvious in either the source code or the
>> documentation). So... a simple "fix" for the ordering is to
>> reorder the definitions in mt7620a.dtsi.
>>
>> This reordering affects exactly one mt7620a router in the dts
>> definitions as of r42293 (NA930.dts).
>>
>> Attached you will find a patch which modifies both mt7620a.dtsi and
>> NA930.dts assigning the console to /dev/ttyS0 for devices with more
>> than one serial port.
>>
>> Note that a similar issue applies to the RT5350. Although we are
>> currently not working with that architecture I am happy to supply a
>> patch if the community would like one.
>>
>> here is a snippet from the boot log of our mt7620a board showing a
>> console happily bound to /dev/ttyS0 and the second serial port
>> bound to /dev/ttyS1
>>
>> [0.35] Serial: 8250/16550 driver, 2 ports, IRQ sharing
>> disabled [0.37] 1c00.uartlite: ttyS0 at MMIO 0x1c00
>> (irq = 20) is a 16550A [0.38] console [ttyS0] enabled,
>> bootconsole disabled [0.38] console [ttyS0] enabled,
>> bootconsole disabled [0.41] 1500.uart: ttyS1 at MMIO
>> 0x1500 (irq = 13) is a 16550A
>>
>>
>> --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
Re: [OpenWrt-Devel] mt7620a serial port driver ordering of nodes uart/uartlite vs ttyS0/ttyS1 patch
apparently our problem is not new and the existing solution is the
"linux,stdout-path" syntax
so stdout-path = &uartf; should work (... maybe)
jonas just pointed this out to me
On 30/08/2014 11:37, Luis Soltero wrote:
> hm... it still seems that the board integrator should be able to determine
> the node name for the device. Implementing a
> scheme based on base address still hard wires the node name to the port and
> does not provide the flexibility of changing
> it.Absolutely depending on the load order is quirky... however knowing
> that gives you some flexibility in the naming.
>
> I think the real answer is to add a property that allows you to specify the
> order. Then you can order the devices
> however you like.
>
> i worry that implementing something on the base address is actually worse
> than what we currently have.
>
> look forward to your thoughts.
>
> --luis
>
> On 8/30/14, 2:35 AM, John Crispin wrote:
>> Hi
>>
>> On Lantiq we derive the port numbering from the base addr that gets
>> used for early printk. i will implement a similar solution for ralink.
>> having to rely on the load order seems quirky.
>>
>> John
>>
>> On 29/08/2014 23:56, Luis Soltero wrote:
>>> Hello All,
>>>
>>> Most mt7620a routers defined in the target/linux/ramips/dts have
>>> exactly one serial port defined which is used for the console. The
>>> serial port driver links this to node /dev/ttyS0.
>>>
>>> However. one (and now 2) devices use the mt7620a serial port lines
>>> for use as a second real serial port (uart@500 in the dts).
>>> Currently when when more than one serial port is defined the boot
>>> sequence starts with the console attached to uartlite but as soon
>>> as the serial port driver driver is loaded it deactivates the
>>> console and assigns it to /dev/ttyS1 (which is the node created for
>>> uartlite). So on these systems using the standard dts
>>> configuration the mt7620a enhanced uart is bound to /dev/ttyS0 and
>>> uartlite is bound /dev/ttyS1.
>>>
>>> This causes the console serial port to stop displaying output
>>> unless the following is added to the dts definition
>>>
>>> chosen { bootargs = "console=ttyS1,57600"; };
>>>
>>> which redefines the console to /dev/ttyS1... this configuration
>>> works fine. However some (including me) find this very
>>> irritating. These few routers defining a second serial port differ
>>> from all the others in their definition of /dev/ttyS0 as the
>>> console.
>>>
>>> So... for consistency it seems that it would be much better for **
>>> ALL ** routers regardless of the number of serial ports define
>>> /dev/ttyS0 as the console port.
>>>
>>> The reason for the renumbering is due to the serial port driver to
>>> assign nodes on a first come first basis in the dts definition.
>>> Since in mt7620a.dtsi (included by most/all 7620a router board
>>> definitions) the definition for uart@500 is before that for
>>> uartlite@00. So uart gets assigned /dev/ttyS0 while uartlite gets
>>> /dev/ttyS1. You can't fault the serial driver for doing it. After
>>> all it really doesn't know for what purpose the serial port is to
>>> be used.
>>>
>>> A logical extension to the serial port dts properties would be to
>>> add a "node-name" or "node-order" or "node-number" property that
>>> would allow the integrator to specify the node number or the node
>>> name for the serial port. However these properties don't exist (or
>>> at least they were not obvious in either the source code or the
>>> documentation). So... a simple "fix" for the ordering is to
>>> reorder the definitions in mt7620a.dtsi.
>>>
>>> This reordering affects exactly one mt7620a router in the dts
>>> definitions as of r42293 (NA930.dts).
>>>
>>> Attached you will find a patch which modifies both mt7620a.dtsi and
>>> NA930.dts assigning the console to /dev/ttyS0 for devices with more
>>> than one serial port.
>>>
>>> Note that a similar issue applies to the RT5350. Although we are
>>> currently not working with that architecture I am happy to supply a
>>> patch if the community would like one.
>>>
>>> here is a snippet from the boot log of our mt7620a board showing a
>>> console happily bound to /dev/ttyS0 and the second serial port
>>> bound to /dev/ttyS1
>>>
>>> [0.35] Serial: 8250/16550 driver, 2 ports, IRQ sharing
>>> disabled [0.37] 1c00.uartlite: ttyS0 at MMIO 0x1c00
>>> (irq = 20) is a 16550A [0.38] console [ttyS0] enabled,
>>> bootconsole disabled [0.38] console [ttyS0] enabled,
>>> bootconsole disabled [0.41] 1500.uart: ttyS1 at MMIO
>>> 0x1500 (irq = 13) is a 16550A
>>>
>>>
>>> --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.open
Re: [OpenWrt-Devel] gigabit router !
On 29/08/14 14:26, Daniel Petre wrote: > Hello, > is there any OpenWrt compatible gigabit router that can do more than 400 > Mbit/s WAN to LAN except linksys wrt1900ac ? > I know netgear wndr3700/wndr3800 and tp-link wr1043nd do around 380-400 > Mbit/s but is there any other hardware more powerful with OpenWrt support? > Thanks! I didn't test it but somebody say Compex WPJ344 and some miniPCIe Compex: http://wiki.openwrt.org/toh/compex/wpj344 And with Compex patches on ath10k driver for 802.11ac (so not 100% OpenWrt). ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] mt7620a serial port driver ordering of nodes uart/uartlite vs ttyS0/ttyS1 patch
Title: The Device Tree: Plug and play for Embedded Linux
If i am understanding correctly this something added to chosen to
bind the console to a specific uart... as in
/dts-v1/; /{
#address-cells = <1>; #size-cells = <1>;
compatible = "xlnx,zynq-zed"; interrupt-parent = <&gic>;
model = "Xillinux for Zedboard";
aliases {
serial0 = &ps7_uart_1;
};
chosen {
bootargs = "consoleblank=0 root=/dev/mmcblk0p2 rw rootwait
earlyprintk";
linux,stdout-path = "/axi@0/uart@E0001000";
};
but does not solve the problem of binding a specific uart to a node
name. i.e. uartline ==> /dev/ttyS0 and uart ==> /dev/ttyS1
interestingly the aliases {} in this example catches my attention.
maybe the ordering is handled by aliases{}?
hm... maybe some experimentation is in order here.
--luis
On 8/30/14, 6:07 AM, John Crispin
wrote:
apparently our problem is not new and the existing solution is the
"linux,stdout-path" syntax
so stdout-path = &uartf; should work (... maybe)
jonas just pointed this out to me
On 30/08/2014 11:37, Luis Soltero wrote:
hm... it still seems that the board integrator should be able to determine the node name for the device. Implementing a
scheme based on base address still hard wires the node name to the port and does not provide the flexibility of changing
it.Absolutely depending on the load order is quirky... however knowing that gives you some flexibility in the naming.
I think the real answer is to add a property that allows you to specify the order. Then you can order the devices
however you like.
i worry that implementing something on the base address is actually worse than what we currently have.
look forward to your thoughts.
--luis
On 8/30/14, 2:35 AM, John Crispin wrote:
Hi
On Lantiq we derive the port numbering from the base addr that gets
used for early printk. i will implement a similar solution for ralink.
having to rely on the load order seems quirky.
John
On 29/08/2014 23:56, Luis Soltero wrote:
Hello All,
Most mt7620a routers defined in the target/linux/ramips/dts have
exactly one serial port defined which is used for the console. The
serial port driver links this to node /dev/ttyS0.
However. one (and now 2) devices use the mt7620a serial port lines
for use as a second real serial port (uart@500 in the dts).
Currently when when more than one serial port is defined the boot
sequence starts with the console attached to uartlite but as soon
as the serial port driver driver is loaded it deactivates the
console and assigns it to /dev/ttyS1 (which is the node created for
uartlite). So on these systems using the standard dts
configuration the mt7620a enhanced uart is bound to /dev/ttyS0 and
uartlite is bound /dev/ttyS1.
This causes the console serial port to stop displaying output
unless the following is added to the dts definition
chosen { bootargs = "console=ttyS1,57600"; };
which redefines the console to /dev/ttyS1... this configuration
works fine. However some (including me) find this very
irritating. These few routers defining a second serial port differ
from all the others in their definition of /dev/ttyS0 as the
console.
So... for consistency it seems that it would be much better for **
ALL ** routers regardless of the number of serial ports define
/dev/ttyS0 as the console port.
The reason for the renumbering is due to the serial port driver to
assign nodes on a first come first basis in the dts definition.
Since in mt7620a.dtsi (included by most/all 7620a router board
definitions) the definition for uart@500 is before that for
uartlite@00. So uart gets assigned /dev/ttyS0 while uartlite gets
/dev/ttyS1. You can't fault the serial driver for doing it. After
all it really doesn't know for what purpose the serial port is to
be used.
A logical extension to the serial port dts properties would be to
add a "node-name" or "node-order" or "node-number" property that
would allow the integrator to specify the node number or the node
name for the serial port. However these properties don't exist (or
at least they were not obvious in either the source code or the
documentation). So... a simple "fix" for the ordering is to
reorder the definitions in mt7620a.dtsi.
This reordering affects exactly one mt7620a router in the dts
definitions as of r42293 (NA930.dts).
Attached you will find a patch which modifies both mt7620a.dtsi and
NA930.dts assigning the console to /dev/ttyS0 for devices with more
than one serial port.
Note that a similar issue applies to the RT5350. Although we are
currently not working with that architecture I am happy to supply a
patch if the community would like one.
here is a snippet from the boot log of our mt7620a board showing a
console happily bound to /dev/ttyS0 and the second serial port
boun
Re: [OpenWrt-Devel] mt7620a serial port driver ordering of nodes uart/uartlite vs ttyS0/ttyS1 patch
Title: The Device Tree: Plug and play for Embedded Linux
this...
aliases
{&
nbsp;&nbs
p;
serial0 =
"/palmbus@1000/uartlite@c00";
};
&nb
sp;
chosen
{&
nbsp;&nbs
p;
bootargs =
"console=ttyS0,57600";
linux,stdout-path =
"/palmbus@1000/uartlite@c00";
};
did not work..
[ 0.34] msgmni has been set to 247
[ 0.35] io scheduler noop registered
[ 0.35] io scheduler deadline registered (default)
[ 0.36] Serial: 8250/16550 driver, 2 ports, IRQ sharing
disabled
[ 0.38] 1500.uart: ttyS0 at MMIO 0x1500 (irq = 13) is
a 16550A
[ 0.39] console [ttyS0] enabled, bootconsole disabled
uart and not uartlite was assigned to /dev/ttyS0
--luis
On 8/30/14, 7:30 AM, Luis Soltero
wrote:
If i am understanding correctly this something added to chosen to
bind the console to a specific uart... as in
/dts-v1/; /{
#address-cells = <1>; #size-cells = <1>;
compatible = "xlnx,zynq-zed"; interrupt-parent = <&gic>;
model = "Xillinux for Zedboard";
aliases {
serial0 = &ps7_uart_1;
};
chosen {
bootargs = "consoleblank=0 root=/dev/mmcblk0p2 rw rootwait
earlyprintk";
linux,stdout-path = "/axi@0/uart@E0001000";
};
but does not solve the problem of binding a specific uart to a
node name. i.e. uartline ==> /dev/ttyS0 and uart ==>
/dev/ttyS1
interestingly the aliases {} in this example catches my
attention. maybe the ordering is handled by aliases{}?
hm... maybe some experimentation is in order here.
--luis
On 8/30/14, 6:07 AM, John Crispin
wrote:
apparently our problem is not new and the existing solution is the
"linux,stdout-path" syntax
so stdout-path = &uartf; should work (... maybe)
jonas just pointed this out to me
On 30/08/2014 11:37, Luis Soltero wrote:
hm... it still seems that the board integrator should be able to determine the node name for the device. Implementing a
scheme based on base address still hard wires the node name to the port and does not provide the flexibility of changing
it.Absolutely depending on the load order is quirky... however knowing that gives you some flexibility in the naming.
I think the real answer is to add a property that allows you to specify the order. Then you can order the devices
however you like.
i worry that implementing something on the base address is actually worse than what we currently have.
look forward to your thoughts.
--luis
On 8/30/14, 2:35 AM, John Crispin wrote:
Hi
On Lantiq we derive the port numbering from the base addr that gets
used for early printk. i will implement a similar solution for ralink.
having to rely on the load order seems quirky.
John
On 29/08/2014 23:56, Luis Soltero wrote:
Hello All,
Most mt7620a routers defined in the target/linux/ramips/dts have
exactly one serial port defined which is used for the console. The
serial port driver links this to node /dev/ttyS0.
However. one (and now 2) devices use the mt7620a serial port lines
for use as a second real serial port (uart@500 in the dts).
Currently when when more than one serial port is defined the boot
sequence starts with the console attached to uartlite but as soon
as the serial port driver driver is loaded it deactivates the
console and assigns it to /dev/ttyS1 (which is the node created for
uartlite). So on these systems using the standard dts
configuration the mt7620a enhanced uart is bound to /dev/ttyS0 and
uartlite is bound /dev/ttyS1.
This causes the console serial port to stop displaying output
unless t
Re: [OpenWrt-Devel] [Bug: Busybox 1.22.1] false return 0 instead of 1 with '--help' switch.
* Alive4ever [29.08.2014 14:03]: > I'm using an embedded system with busybox v1.22.1, running Openwrt Chaos > Chalmer r42321, mips24k AR9330 > > When I call 'busybox false --help', the return status is zero. I think it has > nothing todo with openwrt, because it's the output of busybox, not the > problem on openwrt performance. I feel it's strange, because GNU coreutils > false binary gives return status 1, even when invoked with '--help' switch. I > also notice that Ubuntu busybox false, which is version 1.21.1 performs the > same behaviour as GNU coreutils. > i cannot see a bug here on OpenWrt: root@box:~ busybox false --help BusyBox v1.22.1 (2014-08-28 18:55:30 EDT) multi-call binary. Usage: false Return an exit code of FALSE (1) root@box:~ echo $? 0 root@box:~ false --help root@box:~ echo $? 1 root@box:~ false bla root@box:~ echo $? 1 bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] gigabit router !
* Daniel Petre [30.08.2014 07:42]: > is there any OpenWrt compatible gigabit router that can do more than > 400 Mbit/s WAN to LAN except linksys wrt1900ac ? > I know netgear wndr3700/wndr3800 and tp-link wr1043nd do around > 380-400 Mbit/s but is there any other hardware more powerful with > OpenWrt support? you can just use a cheap x86-board with 2 x Gigabit RJ45, e.g. GigaByte GA-J1900N-D3V bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] gigabit router !
On 30/08/14 08:47, Bastian Bittorf wrote: * Daniel Petre [30.08.2014 07:42]: is there any OpenWrt compatible gigabit router that can do more than 400 Mbit/s WAN to LAN except linksys wrt1900ac ? I know netgear wndr3700/wndr3800 and tp-link wr1043nd do around 380-400 Mbit/s but is there any other hardware more powerful with OpenWrt support? you can just use a cheap x86-board with 2 x Gigabit RJ45, e.g. GigaByte GA-J1900N-D3V Thanks for the hint, i'm just using a setup like this but with another mini itx gigabyte board, a bit cheaper, with usb2. Works awesome but i was wondering about a wireless router with OpenWrt support more powerful.. bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] gigabit router !
On Fri, Aug 29, 2014 at 3:26 PM, Daniel Petre wrote: > is there any OpenWrt compatible gigabit router that can do more than 400 > Mbit/s WAN to LAN except linksys wrt1900ac ? Mikrotik and Ubiquiti gigabit routers will easily do 400Mb from LAN to WAN, and can get 700-800Mb depending on your routing and firewall rules. -- Soren Harward ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Toolchain issue: Significant decrease in performance of binaries produced by Barrier Breaker relative to Attitude Adjustment
Hi, I've noticed that the code produced by Barrier Breaker's toolchain sometimes has significantly worse performance that that built by Attitude Adjustment. I can see this extremely with the VPN tool "fastd" developed and maintained by me: On the same Barrier Breaker system, a binary built by the default Barrier Breaker toolchain (GCC 4.8-linaro) gets about 35% less throughput than one built with Attitude Adjustment (GCC 4.6-linaro). With the 4.6-linaro toolchain of Barrier Breaker, I still get 20% worse performance than with the 4.6-linaro of Attitude Adjustment. Do you have any suggestions what I can do to solve or analyze the issue? Any compiler flags I should try fiddling with? Optimizing with -Os vs. -O3 doesn't seem to make a difference. Thanks, Matthias 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] Toolchain issue: Significant decrease in performance of binaries produced by Barrier Breaker relative to Attitude Adjustment
On 08/30/2014 06:42 PM, Matthias Schiffer wrote: > Hi, > I've noticed that the code produced by Barrier Breaker's toolchain > sometimes has significantly worse performance that that built by > Attitude Adjustment. > > I can see this extremely with the VPN tool "fastd" developed and > maintained by me: On the same Barrier Breaker system, a binary built by > the default Barrier Breaker toolchain (GCC 4.8-linaro) gets about 35% > less throughput than one built with Attitude Adjustment (GCC > 4.6-linaro). With the 4.6-linaro toolchain of Barrier Breaker, I still > get 20% worse performance than with the 4.6-linaro of Attitude Adjustment. > > Do you have any suggestions what I can do to solve or analyze the issue? > Any compiler flags I should try fiddling with? Optimizing with -Os vs. > -O3 doesn't seem to make a difference. > > Thanks, > Matthias > I forgot to tell that this is on ar71xx. 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] Toolchain issue: Significant decrease in performance of binaries produced by Barrier Breaker relative to Attitude Adjustment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/30/2014 06:45 PM, Matthias Schiffer wrote: > On 08/30/2014 06:42 PM, Matthias Schiffer wrote: >> Hi, I've noticed that the code produced by Barrier Breaker's >> toolchain sometimes has significantly worse performance that that >> built by Attitude Adjustment. >> >> I can see this extremely with the VPN tool "fastd" developed and >> maintained by me: On the same Barrier Breaker system, a binary >> built by the default Barrier Breaker toolchain (GCC 4.8-linaro) >> gets about 35% less throughput than one built with Attitude >> Adjustment (GCC 4.6-linaro). With the 4.6-linaro toolchain of >> Barrier Breaker, I still get 20% worse performance than with the >> 4.6-linaro of Attitude Adjustment. >> >> Do you have any suggestions what I can do to solve or analyze the >> issue? Any compiler flags I should try fiddling with? Optimizing >> with -Os vs. -O3 doesn't seem to make a difference. >> >> Thanks, Matthias >> > > I forgot to tell that this is on ar71xx. This could be a problem caused by mips16. We use that in BB to create smaller binaries. but Jonas saw a performance problem in some applications, mostly stuff doing crypto (big integer calculations). Can you try to build the BB toolchain without the mips16 feature in target/linux/ar71xx/Makefile and try your application again. Hauke -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJUAgDuAAoJEIZ0px9YPRMyoaIP/2poElmUMxw/LyDL4I5Il/c3 eYsqGmB13PTYhnRBnHKfokG/1us43Q6bZgMx6AqktEEp+rCGfB4N771ed653YEwU q2SiKIvMU+7z3bPfON9tie6lRA3Ubv/BlSXHS/PKFpJ3H0veywitvqDRhywEfsD6 JCo44Vh5o6p5CTCc3HFJ5FvH/UUiNBEtvSSAbMOBM/z+cO1dJL40yFKf49WLL9BI hTVXaUCbQpBFlISl8202IZJkxNDvpytHMRMPmy1ntweHalOXhmHYEL1BsJszxeZO ntmCIa6lhZnA2JvzZda/drle6Wo9t51QUH/DCf9xL6FgdTyWnEE1QUkJpvkxJlH+ 2iZIpK0FVQ3QFxFQ1eFloSjiiGZUbkhAGknQXLRa/6FfU/QNGSzysgqRrtK8Ekji RdUfQLTKrq6r8vwOGVo2QwB0tAKjoCOm8PTGyctGcIXAZqs5+jb8SdVmHirmR5dm 1IVGIbsI4UvN2lkbgz/Xkz0y0E8en0uo/4/vclv62RzC6PYh0j7GJoI0CUJUDEyI h5ZFbAj54F3v+riEB0YYPKBeS9CF2Gv6PVTGc1szIkc7lvURDk3aMiPc/hwqQ6E7 RFepHBQ0HLf8wzXa6d709P5/xEWVlER4kbWOI4Iij84fyUbLdI6pASnihX0GaP6h RRQ5Z7nUAcns46VMtAzp =e4/e -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Toolchain issue: Significant decrease in performance of binaries produced by Barrier Breaker relative to Attitude Adjustment
On 2014-08-30 18:45, Matthias Schiffer wrote: > On 08/30/2014 06:42 PM, Matthias Schiffer wrote: >> Hi, >> I've noticed that the code produced by Barrier Breaker's toolchain >> sometimes has significantly worse performance that that built by >> Attitude Adjustment. >> >> I can see this extremely with the VPN tool "fastd" developed and >> maintained by me: On the same Barrier Breaker system, a binary built by >> the default Barrier Breaker toolchain (GCC 4.8-linaro) gets about 35% >> less throughput than one built with Attitude Adjustment (GCC >> 4.6-linaro). With the 4.6-linaro toolchain of Barrier Breaker, I still >> get 20% worse performance than with the 4.6-linaro of Attitude Adjustment. >> >> Do you have any suggestions what I can do to solve or analyze the issue? >> Any compiler flags I should try fiddling with? Optimizing with -Os vs. >> -O3 doesn't seem to make a difference. >> >> Thanks, >> Matthias >> > > I forgot to tell that this is on ar71xx. Did you try disabling mips16 support for fastd? PKG_USE_MIPS16:=0 - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Toolchain issue: Significant decrease in performance of binaries produced by Barrier Breaker relative to Attitude Adjustment
On 08/30/2014 06:54 PM, Felix Fietkau wrote: > On 2014-08-30 18:45, Matthias Schiffer wrote: >> On 08/30/2014 06:42 PM, Matthias Schiffer wrote: >>> Hi, >>> I've noticed that the code produced by Barrier Breaker's toolchain >>> sometimes has significantly worse performance that that built by >>> Attitude Adjustment. >>> >>> I can see this extremely with the VPN tool "fastd" developed and >>> maintained by me: On the same Barrier Breaker system, a binary built by >>> the default Barrier Breaker toolchain (GCC 4.8-linaro) gets about 35% >>> less throughput than one built with Attitude Adjustment (GCC >>> 4.6-linaro). With the 4.6-linaro toolchain of Barrier Breaker, I still >>> get 20% worse performance than with the 4.6-linaro of Attitude Adjustment. >>> >>> Do you have any suggestions what I can do to solve or analyze the issue? >>> Any compiler flags I should try fiddling with? Optimizing with -Os vs. >>> -O3 doesn't seem to make a difference. >>> >>> Thanks, >>> Matthias >>> >> >> I forgot to tell that this is on ar71xx. > Did you try disabling mips16 support for fastd? > > PKG_USE_MIPS16:=0 > > - Felix > That actually did the trick when applying it to the package nacl which contains some of the crypto algorithms used by fastd :) I'll update nacl with the option added. Thanks, Matthias 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] Toolchain issue: Significant decrease in performance of binaries produced by Barrier Breaker relative to Attitude Adjustment
On 2014-08-30 18:51, Hauke Mehrtens wrote: > On 08/30/2014 06:45 PM, Matthias Schiffer wrote: >> On 08/30/2014 06:42 PM, Matthias Schiffer wrote: >>> Hi, I've noticed that the code produced by Barrier Breaker's >>> toolchain sometimes has significantly worse performance that that >>> built by Attitude Adjustment. >>> >>> I can see this extremely with the VPN tool "fastd" developed and >>> maintained by me: On the same Barrier Breaker system, a binary >>> built by the default Barrier Breaker toolchain (GCC 4.8-linaro) >>> gets about 35% less throughput than one built with Attitude >>> Adjustment (GCC 4.6-linaro). With the 4.6-linaro toolchain of >>> Barrier Breaker, I still get 20% worse performance than with the >>> 4.6-linaro of Attitude Adjustment. >>> >>> Do you have any suggestions what I can do to solve or analyze the >>> issue? Any compiler flags I should try fiddling with? Optimizing >>> with -Os vs. -O3 doesn't seem to make a difference. >>> >>> Thanks, Matthias >>> > >> I forgot to tell that this is on ar71xx. > > This could be a problem caused by mips16. We use that in BB to create > smaller binaries. but Jonas saw a performance problem in some > applications, mostly stuff doing crypto (big integer calculations). > > Can you try to build the BB toolchain without the mips16 feature in > target/linux/ar71xx/Makefile and try your application again. There's no need to disable it for the target, since it can be disabled for individual packages. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] gigabit router !
Am 2014-08-30 17:17, schrieb Soren Harward: On Fri, Aug 29, 2014 at 3:26 PM, Daniel Petre wrote: is there any OpenWrt compatible gigabit router that can do more than 400 Mbit/s WAN to LAN except linksys wrt1900ac ? Mikrotik and Ubiquiti gigabit routers will easily do 400Mb from LAN to WAN, and can get 700-800Mb depending on your routing and firewall rules. I don't have a benchmark, but the Mikrotik RB 493G has quite a fast MIPS32-CPU@680MHz (800 MHz max.) and 256 MByte RAM to handle it's nine 1000Base-T-ports. -- Best regards, Renne ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Toolchain issue: Significant decrease in performance of binaries produced by Barrier Breaker relative to Attitude Adjustment
On Sat, 2014-08-30 at 20:10 +0200, Felix Fietkau wrote: > > This could be a problem caused by mips16. We use that in BB to create > > smaller binaries. but Jonas saw a performance problem in some > > applications, mostly stuff doing crypto (big integer calculations). > > Can you try to build the BB toolchain without the mips16 feature in > > target/linux/ar71xx/Makefile and try your application again. > There's no need to disable it for the target, since it can be disabled > for individual packages. So should all packages that contain performance critical code have that flag? 35% performance penalty is too high for such systems. regards, Nikos ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Toolchain issue: Significant decrease in performance of binaries produced by Barrier Breaker relative to Attitude Adjustment
On 2014-08-30 21:27, Nikos Mavrogiannopoulos wrote: > On Sat, 2014-08-30 at 20:10 +0200, Felix Fietkau wrote: > >> > This could be a problem caused by mips16. We use that in BB to create >> > smaller binaries. but Jonas saw a performance problem in some >> > applications, mostly stuff doing crypto (big integer calculations). >> > Can you try to build the BB toolchain without the mips16 feature in >> > target/linux/ar71xx/Makefile and try your application again. >> There's no need to disable it for the target, since it can be disabled >> for individual packages. > > So should all packages that contain performance critical code have that > flag? 35% performance penalty is too high for such systems. Some kinds of code may be more affected than others. For crypto code we should definitely disable mips16, as it seems to be most affected. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] nettle mips16 patch [was: Significant decrease in performance of binaries produced by Barrier Breaker relative to Attitude Adjustment]
On Sat, 2014-08-30 at 21:33 +0200, Felix Fietkau wrote: > On 2014-08-30 21:27, Nikos Mavrogiannopoulos wrote: > > On Sat, 2014-08-30 at 20:10 +0200, Felix Fietkau wrote: > > > >> > This could be a problem caused by mips16. We use that in BB to create > >> > smaller binaries. but Jonas saw a performance problem in some > >> > applications, mostly stuff doing crypto (big integer calculations). > >> > Can you try to build the BB toolchain without the mips16 feature in > >> > target/linux/ar71xx/Makefile and try your application again. > >> There's no need to disable it for the target, since it can be disabled > >> for individual packages. > > > > So should all packages that contain performance critical code have that > > flag? 35% performance penalty is too high for such systems. > Some kinds of code may be more affected than others. For crypto code we > should definitely disable mips16, as it seems to be most affected. Then I guess, that patch should be applied on nettle. regards, Nikos >From a75b56c15bd28e41daec6867fe652a3c61a65edc Mon Sep 17 00:00:00 2001 From: Nikos Mavrogiannopoulos Date: Sat, 30 Aug 2014 22:09:27 +0200 Subject: [PATCH] nettle: set PKG_USE_MIPS16 to zer Signed-off-by: Nikos Mavrogiannopoulos --- package/libs/nettle/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/package/libs/nettle/Makefile b/package/libs/nettle/Makefile index 4b0ce0b..c655b72 100644 --- a/package/libs/nettle/Makefile +++ b/package/libs/nettle/Makefile @@ -10,6 +10,7 @@ include $(TOPDIR)/rules.mk PKG_NAME:=nettle PKG_VERSION:=2.7.1 PKG_RELEASE:=1 +PKG_USE_MIPS16:=0 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz PKG_SOURCE_URL:=@GNU/nettle -- 2.0.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Toolchain issue: Significant decrease in performance of binaries produced by Barrier Breaker relative to Attitude Adjustment
Well done guys. These type of findings that makes significant different on embedded systems. Fernando On 30/08/2014 20:33, Felix Fietkau wrote: On 2014-08-30 21:27, Nikos Mavrogiannopoulos wrote: On Sat, 2014-08-30 at 20:10 +0200, Felix Fietkau wrote: This could be a problem caused by mips16. We use that in BB to create smaller binaries. but Jonas saw a performance problem in some applications, mostly stuff doing crypto (big integer calculations). Can you try to build the BB toolchain without the mips16 feature in target/linux/ar71xx/Makefile and try your application again. There's no need to disable it for the target, since it can be disabled for individual packages. So should all packages that contain performance critical code have that flag? 35% performance penalty is too high for such systems. Some kinds of code may be more affected than others. For crypto code we should definitely disable mips16, as it seems to be most affected. - Felix ___ 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] gigabit router !
I'm running OpenWRT on this one: http://www.amazon.com/TP-LINK-Archer-C7-Wireless-1350Mbps/dp/B00BUSDVBQ/ref=sr_1_1?ie=UTF8&qid=undefined&sr=8-1&keywords=tp-link+ac I haven't done any throughput tests to generate empirical data, but it 'feels' like it's operating at full speed. -- Brent On Sat, Aug 30, 2014 at 12:36 PM, Rene Bartsch wrote: > Am 2014-08-30 17:17, schrieb Soren Harward: > >> On Fri, Aug 29, 2014 at 3:26 PM, Daniel Petre >> wrote: >>> >>> is there any OpenWrt compatible gigabit router that can do more than 400 >>> Mbit/s WAN to LAN except linksys wrt1900ac ? >> >> >> Mikrotik and Ubiquiti gigabit routers will easily do 400Mb from LAN to >> WAN, and can get 700-800Mb depending on your routing and firewall >> rules. > > > I don't have a benchmark, but the Mikrotik RB 493G has quite a fast > MIPS32-CPU@680MHz (800 MHz max.) and 256 MByte RAM to handle it's nine > 1000Base-T-ports. > > -- > Best regards, > > Renne > > ___ > 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
