Re: [OpenWrt-Devel] System halted on bcm4708 series board when booting openwrt trunk (kernel 3.14)
On 10 March 2015 at 04:43, Tymon banglang.hu...@foxmail.com wrote: my cpu is BCM958522ER which is the same series with 4708 as well, 32MB ###boot log: (I updated the xxx-squashfs.trx to the flash) Hit any key to stop autoboot: 0 Checking TRX Image at addr 1e20 ... Uncompressing ... Primary TRX image OK kernel args : console=ttyS0,115200 ubi.mtd=5 root=ubi0:rootfs ro rootflags=sync rootfstype=ubifs user_debug=31 Booting from Primary Partition kernel_args console=ttyS0,115200 ubi.mtd=5 root=ubi0:rootfs ro rootflags=sync rootfstype=ubifs user_debug=31 Start addr 8000 machid 127f Parmameter addr 0010 ... Starting kernel ... Uncompressing Linux... XZ-compressed data is corrupt -- System halted I want to know why this error arise, any hints will be appreciated. My guess is that it's some problem caused by this board using U-Boot. It's the first time I hear about someone trying Broadcom ARM, U-Boot an OpenWrt. I guess U-Boot doesn't like our kernel. Our config uses CONFIG_KERNEL_XZ=y, but we also seem to be using lzma, see target/linux/bcm53xx/image/Makefile. You may want to check how original firmware (SDK, whatever) builds prepares the kernel. -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/6] bcm53xx: changes for R8000 so far
On Tue, Mar 10, 2015 at 4:30 AM, Ian Kent ra...@themaw.net wrote: [OpenWrt-Devel] [PATCH 0/6] bcm53xx: changes for R8000 so far Ah, this is supposed to be the V2. Please version your patchsets when resubmitting, i.e. this would be then [PATCH V2], and add a changelog to the individual patches (under the tear line, so it won't land in the actual commit message when accepted). Jonas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Why OpenWrt sucks?
On 10/03/2015 12:39, elektra wrote: Hi folks – OpenWrt is f***ing awesome. Many kudos for this excellent work. My 0.2 BTC, Elektra Hi Elektra, agreed, but we need more cats and unicorns John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] reply： System halted on bcm4708 series board when booting openwrt trunk(kernel 3.14)
On 10/03/15 06:34, Tymon wrote: On 10 March 2015 at 04:43, Tymon banglang.hu...@foxmail.com wrote: my cpu is BCM958522ER which is the same series with 4708 as well, 32MB ###boot log: (I updated the xxx-squashfs.trx to the flash) Hit any key to stop autoboot: 0 Checking TRX Image at addr 1e20 ... Uncompressing ... Primary TRX image OK kernel args : console=ttyS0,115200 ubi.mtd=5 root=ubi0:rootfs ro rootflags=sync rootfstype=ubifs user_debug=31 Booting from Primary Partition kernel_args console=ttyS0,115200 ubi.mtd=5 root=ubi0:rootfs ro rootflags=sync rootfstype=ubifs user_debug=31 Start addr 8000 machid 127f Parmameter addr 0010 ... Starting kernel ... Uncompressing Linux... XZ-compressed data is corrupt -- System halted I want to know why this error arise, any hints will be appreciated. but the XZ-compressed data is corrupt is the message of openwrt-trunk kernel that under linux-3.14.xx/lib/compress_unxz.c +371 Did uboot load all of the image into memory? Where did it load the image? Where will the kernel decompress to? Is there room for it to be decompressed? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/6] bcm53xx: changes for R8000 so far
On Tue, 2015-03-10 at 12:55 +0100, Rafał Miłecki wrote: On 10 March 2015 at 12:29, Jonas Gorski j...@openwrt.org wrote: On Tue, Mar 10, 2015 at 4:30 AM, Ian Kent ra...@themaw.net wrote: [OpenWrt-Devel] [PATCH 0/6] bcm53xx: changes for R8000 so far Ah, this is supposed to be the V2. Please version your patchsets when resubmitting, i.e. this would be then [PATCH V2], and add a changelog to the individual patches (under the tear line, so it won't land in the actual commit message when accepted). Right. Something like git format-patch --subject-prefix=PATCH V2 Right, as I say I prefer StGIT, so that's probably stg mail -v v2, I haven't actually used that option before. No need to do it this time, I'll recognize V2 on my own. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/6] Series short description
On Tue, Mar 10, 2015 at 4:25 AM, Ian Kent ra...@themaw.net wrote: The following series implements... If you don't have anything nice to say, ... ;) (i.e. you should drop the cover letter if it does not contain anything useful). Jonas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Why OpenWrt sucks?
On Tue, Mar 10, 2015 at 3:21 AM, Michael Richardson m...@sandelman.ca wrote: Alpha Sparc alphasp...@gmail.com wrote: I believe it is due to the hardware NAT not supported. So, really, nothing to do with wifi drivers at all. You don't need (hardware) NAT if you run IPv6... hardware NAT is usually a bit of a misnomer, most implementations generally support forwarding in hardware, and often also support various de-/encapsulations (PPPoE, IPIP, etc), which also improves performance for IPv6 routing quite a bit. Jonas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/6] Series short description
On Tue, 2015-03-10 at 12:17 +0100, Jonas Gorski wrote: On Tue, Mar 10, 2015 at 4:25 AM, Ian Kent ra...@themaw.net wrote: The following series implements... If you don't have anything nice to say, ... ;) (i.e. you should drop the cover letter if it does not contain anything useful). Apologies, that was a misfire when I noticed one of the patches needed another change, sorry for the noise. Ian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/3][RESEND] b53: implement ARL Table read/write operations
On Mon, Feb 23, 2015 at 4:55 PM, Alexandru Ardelean ardeleana...@gmail.com wrote: From: Alexandru Ardelean ardeleana...@gmail.com Read/Write operations for the ARL table. To use it: swconfig dev switch0 set arl rd XX:XX:XX:XX:XX:XX vid swconfig dev switch0 get arl Output should be: ARL Operation: Read MAC: XX:XX:XX:XX:XX:XX VLAN ID: Valid: 1 Age: 1 Static: 0 Port(s): 001 Reading/Writing the ARL table is a bit complex of an operation, so string parsing is used. The idea is that this uses swconfig 'set' prepare a r/w operation and swconfig 'get' to execute an operation. Not the most elegant approach, but it works fairly well for a debugging operation using b53 hardware. There are 3 op codes: rd, wr and cl. 'cl' clears any previous rd/wr. This parsing is stupid simple, so any spaces, cases and quotes matter. If a operation failed, the output will be 'failed' and the kernel log can be consulted. The kernel log can also be consulted for various messages that may have been printed during a r/w operation. For 'rd' and 'wr' ops - if VLAN not enabled, only the MAC address is required - if VLAN is enabled, both MAC and VLAN ID are required Commands: - swconfig dev switch0 set arl cl - clear any prev op; no 'get' call required - swconfig dev switch0 set arl rd MAC VID - the call 'get', if output is 'failed' check kernel log - swconfig dev switch0 set arl rd MAC VID \ [static 0/1] [age 0/1] [valid 0/1] [ports NNN] The write operation takes parameters, static, age and valid, which are bits that can be set/modified in the ARL table. The ports must field is dependant on the type of MAC. - for unicat MACs, ports is a port number - for multicast MACs, ports is a bitmask for ports on which to forward This is the same meaning when reading MAC/VID entries. ARL table access is something very common in switch chips, I think it would make more sense to come up with an API for swconfig for the switches to implement that instead of cooking up our own language for each switch driver. So generally I am thinking of something like swconfig dev switch0 arl find mac [vid vid] swconfig dev switch0 arl delete mac [vid vid] swconfig dev switch0 arl add mac [vid vid] [ports ports] [static 0|1] swconfig dev switch0 arl add_port mac [vid vid] port port - this might be useful for igmpproxy co, to update multicast forwarding tables in the switch itself. swconfig dev switch0 arl del_port mac [vid vid] port port Jonas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/6] bcm53xx: changes for R8000 so far
On 10 March 2015 at 12:29, Jonas Gorski j...@openwrt.org wrote: On Tue, Mar 10, 2015 at 4:30 AM, Ian Kent ra...@themaw.net wrote: [OpenWrt-Devel] [PATCH 0/6] bcm53xx: changes for R8000 so far Ah, this is supposed to be the V2. Please version your patchsets when resubmitting, i.e. this would be then [PATCH V2], and add a changelog to the individual patches (under the tear line, so it won't land in the actual commit message when accepted). Right. Something like git format-patch --subject-prefix=PATCH V2 No need to do it this time, I'll recognize V2 on my own. -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 5/6] bcm53xx: deal with R8000 mac address settings
On Tue, Mar 10, 2015 at 4:30 AM, Ian Kent ra...@themaw.net wrote:
After a vendor firmware install the values seen in nvram for et0macaddr
and et1macaddr are that of nvram macaddr and nvram macaddr+1.
So set them that way here too.
Signed-off-by: Ian Kent ra...@themaw.net
---
...53xx-deal-with-R8000-mac-address-settings.patch | 83
...53xx-deal-with-R8000-mac-address-settings.patch | 83
2 files changed, 166 insertions(+)
create mode 100644
target/linux/bcm53xx/patches-3.14/114-bcm53xx-deal-with-R8000-mac-address-settings.patch
create mode 100644
target/linux/bcm53xx/patches-3.18/114-bcm53xx-deal-with-R8000-mac-address-settings.patch
diff --git
a/target/linux/bcm53xx/patches-3.14/114-bcm53xx-deal-with-R8000-mac-address-settings.patch
b/target/linux/bcm53xx/patches-3.14/114-bcm53xx-deal-with-R8000-mac-address-settings.patch
new file mode 100644
index 000..a476405
--- /dev/null
+++
b/target/linux/bcm53xx/patches-3.14/114-bcm53xx-deal-with-R8000-mac-address-settings.patch
@@ -0,0 +1,83 @@
+bcm53xx: deal with R8000 mac address settings
+
+The R8000 ends up with et0macaddr and et1macaddr nvram values being all
+zeros with the et*mdcport and et*phyaddr set to the expected values.
+
+The values seen in the nvram after a vendor firmware install are
+et0macaddr and et2macaddr set to the value of macaddr and et1macaddr
+set to macaddr+1.
+
+But after an nvram erase only et2macaddr has a value, so if et0macaddr
+is all zeros use et2macaddr to set et0macaddr and et1macaddr.
+
+Signed-off-by: Ian Kent ra...@themaw.net
+--- a/drivers/misc/bcm47xx-sprom.c
b/drivers/misc/bcm47xx-sprom.c
+@@ -734,6 +734,24 @@ static void bcm47xx_sprom_fill_path_r11(
+ }
+ }
+
++static bool bcm47xx_is_zero_mac(u8 *mac)
++{
++ bool res = 1;
++ int i;
++
++ if (!mac)
++ goto out;
++
++ for (i = 5; i = 0; i--) {
++ if (mac[i]) {
++ res = 0;
++ break;
++ }
++ }
++out:
++ return res;
++}
++
+ static bool bcm47xx_is_valid_mac(u8 *mac)
+ {
+ return mac !(mac[0] == 0x00 mac[1] == 0x90 mac[2] == 0x4c);
+@@ -780,6 +798,42 @@ static void bcm47xx_sprom_fill_ethernet(
+ nvram_read_macaddr(fill, il0macaddr, sprom-il0mac);
+
+ /*
++ * The R8000 ends up with et0macaddr and et1macaddr nvram values
++ * being all zeros with the et*mdcport and et*phyaddr set to the
++ * expected values. The values seen in the nvram after a vendor
++ * firmware install are et0macaddr set to the value of macaddr
++ * and et1macaddr set to macaddr+1. But after an nvram erase only
++ * et2macaddr has a value, so if et0macaddr is all zeros use
++ * et2macaddr to set et0macaddr and et1macaddr.
++ *
++ * Note: il0macaddr is also the same as macaddr following a vendor
++ * install and the key doesn't exist at all after an nvram erase,
++ * so sprom-il0mac may need to cwbe calculated as well.
++ */
++ if (bcm47xx_is_zero_mac(sprom-et0mac)) {
sprom-et0mac is u16 aligned, so you can replace this with is_zero_ether_addr().
++ struct bcm47xx_sprom_fill fill_no_prefix;
++ u8 mac[6];
and if you make mac aligned to u16, then you can drop the
reimplementation completely.
++
++ memcpy(fill_no_prefix, fill, sizeof(fill_no_prefix));
++ fill_no_prefix.prefix = NULL;
++
++ nvram_read_macaddr(fill_no_prefix, et2macaddr, mac);
++
++ if (bcm47xx_is_valid_mac(mac) !bcm47xx_is_zero_mac(mac)) {
and use it here, too.
++ int err;
++
++ ether_addr_copy(sprom-et0mac, mac);
And this will produce alignment issues anyway if mac isn't aligned to u16.
++
++ err = bcm47xx_increase_mac_addr(mac, 1);
++ if (!err) {
++ ether_addr_copy(sprom-et1mac, mac);
++ /* don't change mac_addr_used so below
++ * will behave as expected, if needed */
++ }
++ }
++ }
++
++ /*
+* The address prefix 00:90:4C is used by Broadcom in their initial
+* configuration. When a mac address with the prefix 00:90:4C is used
+* all devices from the same series are sharing the same mac address.
Jonas
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Why OpenWrt sucks?
Hi folks – OpenWrt is f***ing awesome. Many kudos for this excellent work. My 0.2 BTC, Elektra -- Viral meme of radical freedom The fact that you talk in your head doesn't mean that you think. The worst way to lose control over yourself is by trying to control yourself. Most people experience themselves as a voice in their head, telling them who they are, what they think and what they have to do. http://en.wikipedia.org/wiki/Meme ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/3] b53: create slave devices for ports
On Sat, Feb 28, 2015 at 9:22 AM, Rafał Miłecki zaj...@gmail.com wrote: On 26 February 2015 at 19:24, Florian Fainelli f.faine...@gmail.com wrote: On 25/02/15 07:24, Alexandru Ardelean wrote: Feature implemented and tested on BCM53128. Slave devices logic copied from the Linux kernel from Marvell's DSA driver ( linux/net/dsa/ ). Also the logic for the Broadcom tag processing has been copied from there. There are different efforts here going on, and I would like to at least 3 different people (you, Rafal and myself) can converge to an identical solution that fits everybody here. I agree. I think we should focus on getting this cleared and accepted upstream. I don't think I want to keep adding features like port interfaces to swconfig. I agree with this, as it also has the potential of breaking switches because of different header formats used. Jonas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] UCI overlay proposal
David, I do not disagree, and in fact I was not proposing a new configuration format. What I tried to point out was a) maintaining a 'meta-configuration' for some config overlay very quickly becomes very challenging and resource consuming b) if the format has to be changed, in OpenWRT JSON should be the obvious choice from a pragmatic point: most of the configuration today already is converted to JSON at runtime to be passed to the various ubus services. As for the inherent problem of standardizing a continuously changing configuration, that's what I described as the 'heaviest part'. Considering that there are snmp MIBs released decades ago and (with gradual extensions) still used today, difficult but doable. Anyway, uci is not bad as is generally and does not need a replacement. We have our JSON config overlay and it is doing ok. Alas, it would be a waste of resources if multiple parties were cooking their proprietary overlay system when everybody is trying to reach similar goals. On 03/07/2015 12:00 AM, David Lang wrote: One other thought. If there is a desire to change the format, let's pick a format that's already in use for configuring system rather than inventing yet another one. We should survey the tools that are being written for managing software defined datacenters (openstack and similar) and see if we can use one of those config languages (either as-is or with an automated conversion back and forth) David Lang On Fri, 6 Mar 2015, David Lang wrote: changing the format doesn't solve the problem, it just causes churn in all the software. The problem is the lack of standardization and the fact that the way things are configured changes over time. Not everything is configured in UCI (and this will always be the case because it's not worth trying to change every piece of software available) When you try to design a standardized config space that will work in the future for equipment and software that nobody has imagined yet, you are either going to go crazy-complicated to try and cover everything and have people going cross-eyed trying to understand the spec, or you are going to lock things down to be so ridged that new things will be working around your config spec. The best that you can do is to setup a framework to keep the configs from stepping on each other and try to converge similar software to use the same terms in the config where it makes sense (remember, the newcomer may have a better way of looking at the problem, so trying to force it to define it's config the way the legacy things did it can cause big problems) I'm all for tools to convert the format to whatever you want to use, and (as I posted earlier), to have tools to assemble/generate the configs, but requiring changes to every piece of software to just change the format requires more than every langauage can understand JSON David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/3][RESEND] b53: implement ARL Table read/write operations
On Mon, Feb 23, 2015 at 4:55 PM, Alexandru Ardelean ardeleana...@gmail.com wrote: From: Alexandru Ardelean ardeleana...@gmail.com Read/Write operations for the ARL table. To use it: swconfig dev switch0 set arl rd XX:XX:XX:XX:XX:XX vid swconfig dev switch0 get arl Output should be: ARL Operation: Read MAC: XX:XX:XX:XX:XX:XX VLAN ID: Valid: 1 Age: 1 Static: 0 Port(s): 001 Reading/Writing the ARL table is a bit complex of an operation, so string parsing is used. The idea is that this uses swconfig 'set' prepare a r/w operation and swconfig 'get' to execute an operation. Not the most elegant approach, but it works fairly well for a debugging operation using b53 hardware. There are 3 op codes: rd, wr and cl. 'cl' clears any previous rd/wr. This parsing is stupid simple, so any spaces, cases and quotes matter. If a operation failed, the output will be 'failed' and the kernel log can be consulted. The kernel log can also be consulted for various messages that may have been printed during a r/w operation. For 'rd' and 'wr' ops - if VLAN not enabled, only the MAC address is required - if VLAN is enabled, both MAC and VLAN ID are required Commands: - swconfig dev switch0 set arl cl - clear any prev op; no 'get' call required - swconfig dev switch0 set arl rd MAC VID - the call 'get', if output is 'failed' check kernel log - swconfig dev switch0 set arl rd MAC VID \ [static 0/1] [age 0/1] [valid 0/1] [ports NNN] The write operation takes parameters, static, age and valid, which are bits that can be set/modified in the ARL table. The ports must field is dependant on the type of MAC. - for unicat MACs, ports is a port number - for multicast MACs, ports is a bitmask for ports on which to forward This is the same meaning when reading MAC/VID entries. There seem to be four ARL register table layouts: (Very) old FE switch chips (5325, 5365): 2 ARL table entries at 0x10 and 0x18 format (64 bit wide); [63] valid, [62]: static, [61] age, [60:59]: priority, [60:48]: port id, [47:0] mac. where port id is either a numeric id in case of single cast, and a bitmask for multicast addresses. Note there is no VID field. BCM63XX: 2 ARL table entries at 0x10 and 0x20 (64 + 16 bit wide), format 0x?0: (64 bit) [60:48]: vid [47:0] mac. 0x?8 (16 bit): [15]: valid [14]: static, [13] age [12:10]: priority. [8:0] port id / forward map. where port id is either a numeric id in case of single cast, and a bitmask for multicast addresses. Note there is no VID field. BCM539x: 4 ARL table entries at 0x10/0x20/0x30/0x40, format: 0x?0: (64 bit) [60:48]: vid [47:0] mac. 0x?8 (32 bit): [16]: valid [15]: static, [14] age [12:10]: priority. [8:0] port id / forward map. where port id is either a numeric id in case of single cast, and a bitmask for multicast addresses. Note there is no VID field. BCM531xx: 4 ARL table entries at 0x10/0x20/0x30/0x40, format: 0x?0: (64 bit) [60:48]: vid [47:0] mac. 0x?8 (32 bit): [16]: valid [15]: static, [14] age [13:11]: priority. [8:0] port id / forward map. At least for BCM53101 the portid /forward map is always a bitmap, but I'm not sure about BCM53115/53118/53125/53125. Generally it would be nice to also have the option to just search for a MAC to find out the ports/vid(s) with the ARL sarch register. But more to this in a second email. Jonas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/3] b53: add b53_mac_array_to_u64() utility function
On Mon, Mar 2, 2015 at 10:44 AM, Alexandru Ardelean
ardeleana...@gmail.com wrote:
So, on a powerpc system this works.
static inline u64 b53_mac_array_to_u64(const u8 *u8_arr) {
u64 mac = 0;
u8 *cmac = (u8 *)mac;
memcpy(cmac[2], u8_arr, 6);
return mac;
}
I've done this approach initially, but there were some concerns afterwards
regarding endianness.
On my x86_64 system it looks ok, but I'm hoping you'd validate that this is
endian-correct and would work on little endian targets.
And then I'll move this in the port mirroring patch.
Please don't top post.
Hm, looking a the original patch, did you test this in little endian?
the shift looks wrong for there.
Same for the memcpy, you need to copy to cmac[0] in case of little
endian. Maybe it would be easier to just make the source mac u16
aligned, and then use ether_addr_copy().
Jonas
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 5/6] bcm53xx: deal with R8000 mac address settings
On Tue, 2015-03-10 at 12:26 +0100, Jonas Gorski wrote:
On Tue, Mar 10, 2015 at 4:30 AM, Ian Kent ra...@themaw.net wrote:
After a vendor firmware install the values seen in nvram for et0macaddr
and et1macaddr are that of nvram macaddr and nvram macaddr+1.
So set them that way here too.
Signed-off-by: Ian Kent ra...@themaw.net
---
...53xx-deal-with-R8000-mac-address-settings.patch | 83
...53xx-deal-with-R8000-mac-address-settings.patch | 83
2 files changed, 166 insertions(+)
create mode 100644
target/linux/bcm53xx/patches-3.14/114-bcm53xx-deal-with-R8000-mac-address-settings.patch
create mode 100644
target/linux/bcm53xx/patches-3.18/114-bcm53xx-deal-with-R8000-mac-address-settings.patch
diff --git
a/target/linux/bcm53xx/patches-3.14/114-bcm53xx-deal-with-R8000-mac-address-settings.patch
b/target/linux/bcm53xx/patches-3.14/114-bcm53xx-deal-with-R8000-mac-address-settings.patch
new file mode 100644
index 000..a476405
--- /dev/null
+++
b/target/linux/bcm53xx/patches-3.14/114-bcm53xx-deal-with-R8000-mac-address-settings.patch
@@ -0,0 +1,83 @@
+bcm53xx: deal with R8000 mac address settings
+
+The R8000 ends up with et0macaddr and et1macaddr nvram values being all
+zeros with the et*mdcport and et*phyaddr set to the expected values.
+
+The values seen in the nvram after a vendor firmware install are
+et0macaddr and et2macaddr set to the value of macaddr and et1macaddr
+set to macaddr+1.
+
+But after an nvram erase only et2macaddr has a value, so if et0macaddr
+is all zeros use et2macaddr to set et0macaddr and et1macaddr.
+
+Signed-off-by: Ian Kent ra...@themaw.net
+--- a/drivers/misc/bcm47xx-sprom.c
b/drivers/misc/bcm47xx-sprom.c
+@@ -734,6 +734,24 @@ static void bcm47xx_sprom_fill_path_r11(
+ }
+ }
+
++static bool bcm47xx_is_zero_mac(u8 *mac)
++{
++ bool res = 1;
++ int i;
++
++ if (!mac)
++ goto out;
++
++ for (i = 5; i = 0; i--) {
++ if (mac[i]) {
++ res = 0;
++ break;
++ }
++ }
++out:
++ return res;
++}
++
+ static bool bcm47xx_is_valid_mac(u8 *mac)
+ {
+ return mac !(mac[0] == 0x00 mac[1] == 0x90 mac[2] == 0x4c);
+@@ -780,6 +798,42 @@ static void bcm47xx_sprom_fill_ethernet(
+ nvram_read_macaddr(fill, il0macaddr, sprom-il0mac);
+
+ /*
++ * The R8000 ends up with et0macaddr and et1macaddr nvram values
++ * being all zeros with the et*mdcport and et*phyaddr set to the
++ * expected values. The values seen in the nvram after a vendor
++ * firmware install are et0macaddr set to the value of macaddr
++ * and et1macaddr set to macaddr+1. But after an nvram erase only
++ * et2macaddr has a value, so if et0macaddr is all zeros use
++ * et2macaddr to set et0macaddr and et1macaddr.
++ *
++ * Note: il0macaddr is also the same as macaddr following a vendor
++ * install and the key doesn't exist at all after an nvram erase,
++ * so sprom-il0mac may need to cwbe calculated as well.
++ */
++ if (bcm47xx_is_zero_mac(sprom-et0mac)) {
sprom-et0mac is u16 aligned, so you can replace this with
is_zero_ether_addr().
++ struct bcm47xx_sprom_fill fill_no_prefix;
++ u8 mac[6];
and if you make mac aligned to u16, then you can drop the
reimplementation completely.
++
++ memcpy(fill_no_prefix, fill, sizeof(fill_no_prefix));
++ fill_no_prefix.prefix = NULL;
++
++ nvram_read_macaddr(fill_no_prefix, et2macaddr, mac);
++
++ if (bcm47xx_is_valid_mac(mac) !bcm47xx_is_zero_mac(mac))
{
and use it here, too.
++ int err;
++
++ ether_addr_copy(sprom-et0mac, mac);
And this will produce alignment issues anyway if mac isn't aligned to u16.
OK, thanks for the comments Jonas, will fix.
++
++ err = bcm47xx_increase_mac_addr(mac, 1);
++ if (!err) {
++ ether_addr_copy(sprom-et1mac, mac);
++ /* don't change mac_addr_used so below
++ * will behave as expected, if needed */
++ }
++ }
++ }
++
++ /*
+* The address prefix 00:90:4C is used by Broadcom in their initial
+* configuration. When a mac address with the prefix 00:90:4C is
used
+* all devices from the same series are sharing the same mac
address.
Jonas
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Why OpenWrt sucks?
This is a long way of saying, that if performance sucks on OpenWrt you should blame Atheros and Broadcom for not giving you (OpenWrt community) high quality open source drivers! First thanks to Alex, Charlie, Kathy and Fernando for pointing out that Atheros works together with Linux and OpenWrt developers and that they are very valued member of the community. I agree with you 100%, we should value all members that contribute to supporting open source. From my own hands-on experience with Ubiquiti, Mikrotik, TPLink and other devices that are based on Atheros is that they usually have better performance with stock firmware. Also killer feature for some wifi applications is TDMA protocol, which Ubiquiti, Mikrotik and other device manufacturers support but OpenWrt doesn't support (but this is completely different topic). I knew that Atheros contributed to open source drivers, but there are lots of reviews and benchmarks that show how much performance difference there is between some (not all) devices when running OpenWrt. Our brains are wired for comparison, so they automatically attribute labels like bad, worse, slower, not as good as original when using OpenWrt - I have seen this too many times on forums to give you few specific links to discussions, just dive into forums and you will see this for yourselves. I understand some reasons for part of performance hit and I can live with that. But I also know that performance could be improved because companies that produce open source drivers don't have best possible OpenWrt performance as their top priority. Top managers in most companies don't believe that having best possible performance in OpenWrt (and allocating enough engineer hours for that task) will make them more money. Simple as that. In contrast to this - other companies like Linksys, Mikrotik, Ubiquiti, TPLink and others that have wifi products definitely give top priority to how much performance they can sqeeze out of their devices, and allocate enough engineer hours to make their performance as fast as possible. Unfortunately they value their closed source driver. Can anyone explain to me how NDAs come into this? Because I remember one discussions with Mikrotik developer who said that they can't release their Atheros driver that they developed as open source because they signed NDA with Atheros? Is Atheros giving some secret and proprietary information to companies that sign NDA with them? If this is true then we will never have as fast performance as companies that sign NDAs. v. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ramips: Fix failsafe switch workaround for RT5350 introduced in r42179.
On 08/03/2015 02:44, Vittorio G (VittGam) wrote:
This patch fixes the failsafe switch workaround to avoid soft-bricking
routers where the only exposed Ethernet port is not 0 (it is 4 for the
HT-TM02 for instance).
This is a follow-up of http://patchwork.ozlabs.org/patch/424017/ (sorry for
the delay).
Signed-off-by: Vittorio Gambaletta open...@vittgam.net
diff --git
a/target/linux/ramips/base-files/lib/preinit/07_set_preinit_iface_ramips
b/target/linux/ramips/base-files/lib/preinit/07_set_preinit_iface_ramips
index cae6396..efdc5fd 100644
--- a/target/linux/ramips/base-files/lib/preinit/07_set_preinit_iface_ramips
+++ b/target/linux/ramips/base-files/lib/preinit/07_set_preinit_iface_ramips
@@ -20,7 +20,7 @@ ramips_set_preinit_iface() {
# disabled:
#
https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg19870.html
swconfig dev rt305x set enable_vlan 1
- swconfig dev rt305x vlan 1 set ports 0 6
+ swconfig dev rt305x vlan 1 set ports 0 1 2 3 4 5 6
swconfig dev rt305x port 6 set untag 0
swconfig dev rt305x set apply 1
vconfig add eth0 1
hi
can you send a version that has the pattern shown below please
and 0 1 2 3 4 5 6 is wrong, exclude the wan port from the list please.
John
board=$(ramips_board_name)
board_config_update
ports=0 6
case $board in
my_board_name)
ports=0 1 2 3 4 5 6
;;
esac
swconfig dev rt305x set enable_vlan 1
swconfig dev rt305x vlan 1 set ports $ports
swconfig dev rt305x port 6 set untag 0
swconfig dev rt305x set apply 1
vconfig add eth0 1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ar71xx: fix switched WLAN LEDs on TP-LINK Archer C5/C7
ath10k is loaded before ath9k, so the 5GHz adapter becomes phy0. Signed-off-by: Matthias Schiffer mschif...@universe-factory.net --- target/linux/ar71xx/base-files/etc/uci-defaults/01_leds | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds index a83a4fc..d4cc617 100644 --- a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds @@ -358,8 +358,6 @@ tl-wdr4300) ucidef_set_led_wlan wlan2g WLAN2G tp-link:blue:wlan2g phy0tpt ;; -archer-c5|\ -archer-c7|\ tl-wdr4900-v2) ucidef_set_led_usbdev usb1 USB1 tp-link:green:usb1 1-1 ucidef_set_led_usbdev usb2 USB2 tp-link:green:usb2 2-1 @@ -367,6 +365,14 @@ tl-wdr4900-v2) ucidef_set_led_wlan wlan5g WLAN5G tp-link:blue:wlan5g phy1tpt ;; +archer-c5|\ +archer-c7) + ucidef_set_led_usbdev usb1 USB1 tp-link:green:usb1 1-1 + ucidef_set_led_usbdev usb2 USB2 tp-link:green:usb2 2-1 + ucidef_set_led_wlan wlan2g WLAN2G tp-link:blue:wlan2g phy1tpt + ucidef_set_led_wlan wlan5g WLAN5G tp-link:blue:wlan5g phy0tpt + ;; + tl-wr741nd) ucidef_set_led_netdev wan WAN tp-link:green:wan eth1 ucidef_set_led_switch lan1 LAN1 tp-link:green:lan1 switch0 0x02 -- 2.3.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Why OpenWrt sucks?
On 10 March 2015 at 02:52, Michael Richardson m...@sandelman.ca wrote: valent.turko...@gmail.com valent.turko...@gmail.com wrote: Why it OpenWrt slower than stock firmware? I can help by shining a bit of light onto this subject. I'm developing custom firwmares based on I'm curious about this claim to begin with. Of the people who say this, how many of them actually know how to measure such a thing? Not many, but there are enough skilled people on OpenWrt forums. Skill is not biggest filter but willingness to write a forum post. I know quite a few people who are skilled enough to do the tests, but none of them would write it up as a forum post and share this info with others. Why? They probably don't care enough and about OpenWrt forum community. Here is one example of good test, it is for TPLink Archer C7 (Atheros) which with stock firmware get's much better results than with OpenWrt - https://forum.openwrt.org/viewtopic.php?id=53703 so judge for yourself if tests are done correctly. Maybe write up a wiki page for instructions how to properly compare OpenWrt and stock firmware? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/3][RESEND] b53: implement ARL Table read/write operations
On Tue, Mar 10, 2015 at 2:22 PM, Jonas Gorski j...@openwrt.org wrote: On Mon, Feb 23, 2015 at 4:55 PM, Alexandru Ardelean ardeleana...@gmail.com wrote: From: Alexandru Ardelean ardeleana...@gmail.com Read/Write operations for the ARL table. To use it: swconfig dev switch0 set arl rd XX:XX:XX:XX:XX:XX vid swconfig dev switch0 get arl Output should be: ARL Operation: Read MAC: XX:XX:XX:XX:XX:XX VLAN ID: Valid: 1 Age: 1 Static: 0 Port(s): 001 Reading/Writing the ARL table is a bit complex of an operation, so string parsing is used. The idea is that this uses swconfig 'set' prepare a r/w operation and swconfig 'get' to execute an operation. Not the most elegant approach, but it works fairly well for a debugging operation using b53 hardware. There are 3 op codes: rd, wr and cl. 'cl' clears any previous rd/wr. This parsing is stupid simple, so any spaces, cases and quotes matter. If a operation failed, the output will be 'failed' and the kernel log can be consulted. The kernel log can also be consulted for various messages that may have been printed during a r/w operation. For 'rd' and 'wr' ops - if VLAN not enabled, only the MAC address is required - if VLAN is enabled, both MAC and VLAN ID are required Commands: - swconfig dev switch0 set arl cl - clear any prev op; no 'get' call required - swconfig dev switch0 set arl rd MAC VID - the call 'get', if output is 'failed' check kernel log - swconfig dev switch0 set arl rd MAC VID \ [static 0/1] [age 0/1] [valid 0/1] [ports NNN] The write operation takes parameters, static, age and valid, which are bits that can be set/modified in the ARL table. The ports must field is dependant on the type of MAC. - for unicat MACs, ports is a port number - for multicast MACs, ports is a bitmask for ports on which to forward This is the same meaning when reading MAC/VID entries. ARL table access is something very common in switch chips, I think it would make more sense to come up with an API for swconfig for the switches to implement that instead of cooking up our own language for each switch driver. So generally I am thinking of something like swconfig dev switch0 arl find mac [vid vid] swconfig dev switch0 arl delete mac [vid vid] swconfig dev switch0 arl add mac [vid vid] [ports ports] [static 0|1] swconfig dev switch0 arl add_port mac [vid vid] port port - this might be useful for igmpproxy co, to update multicast forwarding tables in the switch itself. swconfig dev switch0 arl del_port mac [vid vid] port port Jonas That's actually a pretty good idea. Will consider it when re-submitting. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH][RFT] mpc52xx: switch kernel to 3.18
On 1 March 2015 at 00:05, Rafał Miłecki zaj...@gmail.com wrote: Signed-off-by: Rafał Miłecki zaj...@gmail.com --- Gabor: I can see you were bumping mpc52xx kernel in the past. Could you try 3.18? Ping? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [RFC] glibc 2.21 for OpenWrt
Hi all, Not content with adding support for uClibc snapshots, I've also tackled glibc 2.21, as eglibc is no longer an actively maintained project. Here's the branch I've been working on (which isn't tidied up for merge btw): https://github.com/jdub/openwrt/commits/glibc There is one OpenWrt-wide issue that will need to be addressed for glibc 2.21 compatibility: The widespread use of _BSD_SOURCE, which was deprecated in glibc 2.20. It's a simple fix though: Use _DEFAULT_SOURCE instead. Plus, my initial inspection suggests _BSD_SOURCE mostly occurs in OpenWrt-controlled code, such as procd, etc., which makes life simpler. Thanks, Jeff ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [RFC] mac80211: update to wireless-testing 2015-03-09
I have been working on an update to mac80211 for about a month now. I announced it on the developer forums, but it turns out this is the place I should have been talking about it. The initial work I did was to update mac80211 to wireless-testing master-2015-02-09, but since then I have updated to master-2015-03-09. All of the work I have done can be found on github: https://github.com/bryanforbes/openwrt/tree/bryan-2015-03-09 The 7 latest commits in that branch are the sum of the work I’ve done. In brief: * 2e65c87: generic: export get_net_ns_by_fd for use by newer compat-wireless Adds get_net_ns_by_fd to the symbol export table so net/wireless/nl80211.c can use it * e476096: iw: update to 3.17 As it says, update iw to 3.17 * c15b7a5: mac80211: update to wireless-testing 2015-03-09 This is the major work. I created a backport release from wireless-testing 2015-03-09 (for now, the tarball lives on my server), refreshed and deleted patches, and created a patch to revert all cryptoapi ports from net/mac80211. * 1ef4f62: iw: sync nl80211.h nl80211.h in wireless-testing changed quite a bit and iw has a copy from an earlier release; this syncs the two * 6baeebe: iwinfo: sync nl80211.h Same as 1ef4f62, but for iwinfo * 5b207be: hostapd: sync nl80211.h and refresh patches Same as 1ef4f62, but for hostapd. This also refreshes some fuzzy patches. * 2e8adba: mac80211: Use newer firmware for ath10k This grabs a newer firmware from the ath10k-firmware repo. The STA firmware and board.bin stayed the same, but this updates the Makefile to get 10.2.4/firmware-4.bin_10.2.4.45. I built a custom firmware incorporating these changes yesterday and have been running it on an Archer C7 v2 for about half a day. Previous wireless-testing snapshots (master-2015-02-09 and master-2015-03-05-2) were also quite stable. I don’t have any other hardware to test this on, so I can only confirm the stability of the ath9k and ath10k drivers. There are a few things I’d like to ask about in addition to asking for comment on the update: * When I first started this update, I removed the patch which reverted the AES-CCM port in mac80211 and attempted to use the kernel’s cryptoapi modules (along with creating a kmod-crypto-ccm package). After briefly talking with Felix last week(?) on IRC, he let me know that I would need to revert all of the cryptoapi ports done in wireless-testing. Once I did that (100-revert-cryptoapi-ports.patch, which contains a comment detailing the commits reverted), the wireless drivers began to work. My question is two-fold: ** Why is it required to remove the cryptoapi ports to get the wireless drivers working on OpenWRT? ** Does this mean that users of OpenWRT won’t be able to configure and use the ciphers ported? (GCMP, GCMP-256, CCMP-256, BIP-CMAC-256, BIP-GMAC-128, and BIP-GMAC-256) * I updated the ath10k-firmware used from 10.2/firmware-3.bin_10.2-00082-4-2 to 10.2.4/firmware-4.bin_10.2.4.45. I believe I did this correctly (it loads fine in my Archer C7 v2), but will this work for all ath10k hardware? I know the ath10k driver will try different versions of firmware until one works (firmware-4.bin, firmware-3.bin, etc.), but I didn’t think that OpenWRT would want to distribute several firmware files only to have one ever used. There aren’t release notes in the ath10k-firmware repository, so I’m unsure if firmware-4.bin will work on older hardware. Please advise. Thanks in advance for taking the time to review. Hopefully I’ve done this right. If not, let me know and I’ll take steps to do whatever is necessary to get this into OpenWRT. -- Bryan Forbes http://www.reigndropsfall.net GPG Fingerprint 3D7D B728 713A BB7B B8B1 5B61 3888 17E0 70CA 0F3D signature.asc Description: Message signed with OpenPGP using GPGMail ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] x86: use PARTUUID instead explicitly specifying the device by default
This changes the x86 image generation to match x86_64, using the PARTUUID for
the rootfs instead of explicitly configuring the device.
This unbreaks KVM with VirtIO, which uses /dev/vda2 instead of /dev/sda2.
Tested in QEMU/KVM with VirtIO, VirtualBox and VMware.
Signed-off-by: Matthias Schiffer mschif...@universe-factory.net
---
config/Config-images.in | 2 --
target/linux/x86/image/Makefile | 4 +++-
target/linux/x86/image/gen_image_generic.sh | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/config/Config-images.in b/config/Config-images.in
index 5c2e79e..a420c39 100644
--- a/config/Config-images.in
+++ b/config/Config-images.in
@@ -267,8 +267,6 @@ menu Target Images
config TARGET_ROOTFS_PARTNAME
string Root partition on target device
depends on OLPC_BOOTSCRIPT_IMAGES || GRUB_IMAGES
- default /dev/xvda2 if TARGET_x86_xen_domu
- default /dev/sda2 if TARGET_x86 ! TARGET_x86_xen_domu
help
Override the root partition on the final device. If left
empty,
it will be mounted by PARTUUID which makes the kernel find the
diff --git a/target/linux/x86/image/Makefile b/target/linux/x86/image/Makefile
index 5983718..a0045a7 100644
--- a/target/linux/x86/image/Makefile
+++ b/target/linux/x86/image/Makefile
@@ -40,7 +40,9 @@ ifneq ($(GRUB_TERMINALS),)
GRUB_TERMINAL_CONFIG := terminal_input $(GRUB_TERMINALS); terminal_output
$(GRUB_TERMINALS)
endif
+SIGNATURE:=$(shell dd if=/dev/urandom bs=4 count=1 2/dev/null | hexdump -v -e
'%02x')
ROOTPART:=$(call qstrip,$(CONFIG_TARGET_ROOTFS_PARTNAME))
+ROOTPART:=$(if $(ROOTPART),$(ROOTPART),PARTUUID=$(SIGNATURE)-02)
GRUB_TIMEOUT:=$(call qstrip,$(CONFIG_GRUB_TIMEOUT))
@@ -82,7 +84,7 @@ ifneq ($(CONFIG_GRUB_IMAGES),)
-e 's#@CMDLINE@#$(strip $(call Image/cmdline/$(1)) $(BOOTOPTS)
$(GRUB_CONSOLE_CMDLINE))#g' \
-e 's#@TIMEOUT@#$(GRUB_TIMEOUT)#g' \
./grub.cfg $(KDIR)/root.grub/boot/grub/grub.cfg
- PADDING=$(CONFIG_TARGET_IMAGES_PAD) PATH=$(TARGET_PATH)
./gen_image_generic.sh \
+ PADDING=$(CONFIG_TARGET_IMAGES_PAD) SIGNATURE=$(SIGNATURE)
PATH=$(TARGET_PATH) ./gen_image_generic.sh \
$(BIN_DIR)/$(IMG_PREFIX)-combined-$(1).img \
$(CONFIG_TARGET_KERNEL_PARTSIZE) $(KDIR)/root.grub \
$(CONFIG_TARGET_ROOTFS_PARTSIZE) $(KDIR)/root.$(1) \
diff --git a/target/linux/x86/image/gen_image_generic.sh
b/target/linux/x86/image/gen_image_generic.sh
index 9d11efb..3fb31f6 100755
--- a/target/linux/x86/image/gen_image_generic.sh
+++ b/target/linux/x86/image/gen_image_generic.sh
@@ -20,7 +20,7 @@ sect=63
cyl=$(( ($KERNELSIZE + $ROOTFSSIZE) * 1024 * 1024 / ($head * $sect * 512)))
# create partition table
-set `ptgen -o $OUTPUT -h $head -s $sect -p ${KERNELSIZE}m -p ${ROOTFSSIZE}m
${ALIGN:+-l $ALIGN}`
+set `ptgen -o $OUTPUT -h $head -s $sect -p ${KERNELSIZE}m -p ${ROOTFSSIZE}m
${ALIGN:+-l $ALIGN} ${SIGNATURE:+-S 0x$SIGNATURE}`
KERNELOFFSET=$(($1 / 512))
KERNELSIZE=$(($2 / 512))
--
2.3.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/3] [rpcd] file: show data ubus parameter only when used
The ubus calls for file read, list and stat do not use data parameter, so lets
remove them to avoid confusion.
Signed-off-by: Luka Perkov l...@openwrt.org
---
file.c | 47 ---
1 file changed, 28 insertions(+), 19 deletions(-)
diff --git a/file.c b/file.c
index e4c957e..fdc6396 100644
--- a/file.c
+++ b/file.c
@@ -69,14 +69,23 @@ struct rpc_file_exec_context {
static struct blob_buf buf;
enum {
- RPC_F_PATH,
- RPC_F_DATA,
- __RPC_F_MAX,
+ RPC_F_R_PATH,
+ __RPC_F_R_MAX,
};
-static const struct blobmsg_policy rpc_file_policy[__RPC_F_MAX] = {
- [RPC_F_PATH] = { .name = path, .type = BLOBMSG_TYPE_STRING },
- [RPC_F_DATA] = { .name = data, .type = BLOBMSG_TYPE_STRING },
+static const struct blobmsg_policy rpc_file_r_policy[__RPC_F_R_MAX] = {
+ [RPC_F_R_PATH] = { .name = path, .type = BLOBMSG_TYPE_STRING },
+};
+
+enum {
+ RPC_F_RW_PATH,
+ RPC_F_RW_DATA,
+ __RPC_F_RW_MAX,
+};
+
+static const struct blobmsg_policy rpc_file_rw_policy[__RPC_F_RW_MAX] = {
+ [RPC_F_RW_PATH] = { .name = path, .type = BLOBMSG_TYPE_STRING },
+ [RPC_F_RW_DATA] = { .name = data, .type = BLOBMSG_TYPE_STRING },
};
enum {
@@ -129,17 +138,17 @@ rpc_errno_status(void)
static struct blob_attr **
rpc_check_path(struct blob_attr *msg, char **path, struct stat *s)
{
- static struct blob_attr *tb[__RPC_F_MAX];
+ static struct blob_attr *tb[__RPC_F_R_MAX];
- blobmsg_parse(rpc_file_policy, __RPC_F_MAX, tb, blob_data(msg),
blob_len(msg));
+ blobmsg_parse(rpc_file_r_policy, __RPC_F_R_MAX, tb, blob_data(msg),
blob_len(msg));
- if (!tb[RPC_F_PATH])
+ if (!tb[RPC_F_R_PATH])
{
errno = EINVAL;
return NULL;
}
- *path = blobmsg_data(tb[RPC_F_PATH]);
+ *path = blobmsg_data(tb[RPC_F_R_PATH]);
if (stat(*path, s))
return NULL;
@@ -203,18 +212,18 @@ rpc_file_write(struct ubus_context *ctx, struct
ubus_object *obj,
struct blob_attr *msg)
{
int fd;
- struct blob_attr *tb[__RPC_F_MAX];
+ struct blob_attr *tb[__RPC_F_RW_MAX];
- blobmsg_parse(rpc_file_policy, __RPC_F_MAX, tb,
+ blobmsg_parse(rpc_file_rw_policy, __RPC_F_RW_MAX, tb,
blob_data(msg), blob_len(msg));
- if (!tb[RPC_F_PATH] || !tb[RPC_F_DATA])
+ if (!tb[RPC_F_RW_PATH] || !tb[RPC_F_RW_DATA])
return UBUS_STATUS_INVALID_ARGUMENT;
- if ((fd = open(blobmsg_data(tb[RPC_F_PATH]), O_CREAT | O_TRUNC |
O_WRONLY)) 0)
+ if ((fd = open(blobmsg_data(tb[RPC_F_RW_PATH]), O_CREAT | O_TRUNC |
O_WRONLY)) 0)
return rpc_errno_status();
- if (write(fd, blobmsg_data(tb[RPC_F_DATA]),
blobmsg_data_len(tb[RPC_F_DATA])) 0)
+ if (write(fd, blobmsg_data(tb[RPC_F_RW_DATA]),
blobmsg_data_len(tb[RPC_F_RW_DATA])) 0)
return rpc_errno_status();
if (fsync(fd) 0)
@@ -592,10 +601,10 @@ static int
rpc_file_api_init(const struct rpc_daemon_ops *o, struct ubus_context *ctx)
{
static const struct ubus_method file_methods[] = {
- UBUS_METHOD(read,rpc_file_read, rpc_file_policy),
- UBUS_METHOD(write, rpc_file_write, rpc_file_policy),
- UBUS_METHOD(list,rpc_file_list, rpc_file_policy),
- UBUS_METHOD(stat,rpc_file_stat, rpc_file_policy),
+ UBUS_METHOD(read,rpc_file_read, rpc_file_r_policy),
+ UBUS_METHOD(write, rpc_file_write, rpc_file_rw_policy),
+ UBUS_METHOD(list,rpc_file_list, rpc_file_r_policy),
+ UBUS_METHOD(stat,rpc_file_stat, rpc_file_r_policy),
UBUS_METHOD(exec,rpc_file_exec, rpc_exec_policy),
};
--
2.3.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/3] [rpcd] file: use blob_buf_free()
Signed-off-by: Luka Perkov l...@openwrt.org --- file.c | 4 1 file changed, 4 insertions(+) diff --git a/file.c b/file.c index fdc6396..9a3dfd8 100644 --- a/file.c +++ b/file.c @@ -199,6 +199,7 @@ rpc_file_read(struct ubus_context *ctx, struct ubus_object *obj, blobmsg_add_string_buffer(buf); ubus_send_reply(ctx, req, buf.head); + blob_buf_free(buf); rv = UBUS_STATUS_OK; out: @@ -268,6 +269,7 @@ rpc_file_list(struct ubus_context *ctx, struct ubus_object *obj, blobmsg_close_array(buf, c); ubus_send_reply(ctx, req, buf.head); + blob_buf_free(buf); return 0; } @@ -307,6 +309,7 @@ rpc_file_stat(struct ubus_context *ctx, struct ubus_object *obj, blobmsg_add_u32(buf, gid, s.st_gid); ubus_send_reply(ctx, req, buf.head); + blob_buf_free(buf); return 0; } @@ -393,6 +396,7 @@ rpc_file_exec_reply(struct rpc_file_exec_context *c, int rv) rpc_ustream_to_blobmsg(c-epipe.stream, stderr); ubus_send_reply(c-context, c-request, buf.head); + blob_buf_free(buf); } ubus_complete_deferred_request(c-context, c-request, rv); -- 2.3.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Why OpenWrt sucks?
Hi Valent, first of all, I strongly disagree with people claiming that OpenWrt sucks because it doesn't. For me it rather looks like a well-maintained, rapidly improving project with a great number of actively supported hardware and quite a few people contributing to the project regularly. I can see dozens of patches published every day not only by the core devs but by many contributors which is a great thing and indicates that many people are trying to make OpenWrt *even *better. I must mention you had a point that made me smile - it's about being a miracle that openwrt works as good as it does. This reminded me to the DNS system. As we all know, it was never developed with a concept of creating a complex network service to be used in a worldwide network but more like as a simple phonebook for companies, schools and other small, autonomous institutions to avoid the need to remember IP addresses. Now, DNS is used worldwide by thousands of entities and is probably one of the oldest protocols still actively used on the internet and it still works pretty good despite its age. Miracles do happen sometimes and that's what makes our lives brighter. :) Anyway, as far as I can see, more and more manufacturers (including wireless chip vendors) realize the benefits of open source and release their driver codes to the open source community. I clearly remember seeing some driver sources posted on this list directly by Marvell and I'm pretty sure that many other vendors will start doing so in the future. I think the reason why most vendors still haven't published their drivers is more like legal issues rather than technical or political ones. They have to meet regulatory requirements and respect the copyright of other people's work. Even if they would feel inclined to release their driver, they can't do so because of licensing issues. For people complaining about OpenWrt, I would simply tell them that first of all, it's provided for free for everyone in the world so stop complaining. Also, being an open source project, it's always open for contributions. Everyone has the possibility to share ideas or implement features making OpenWrt a more stable, more robust and more versatile piece of software. My fifty cents was to create a port of Seafile for OpenWrt - I'm using it myself at home and I'm very happy to see it running on my router with a USB HDD attached rather than running an additional home server 24/7 consuming more power and taking up more room in my flat. At the same time, I'm happy to provide the same ability to other people because that's how it's meant to be. Do you think OpenWrt sucks? Then stop complaining and do something to make it better. It's that simple. Cheers, Gergely On 9 March 2015 at 21:02, valent.turko...@gmail.com valent.turko...@gmail.com wrote: Hi all, I see this or similar question of forums all the time and I have answered it few times. I suggest we open a wiki page and contribute an answer. Here is how I usually reply to similar questions, please give your comments in your replies: Why it OpenWrt slower than stock firmware? I can help by shining a bit of light onto this subject. I'm developing custom firwmares based on OpenWrt but I'm not OpenWrt developer, still as I have few years of experience with OpenWrt I can explain why sometimes performance sucks or there are some issues and bugs. OpenWrt has three main parts; linux kernel, software packages and wireless drivers. OpenWrt developers work on all of them. Consider the amount of code this is, and consider that all work is done by a handful of OpenWrt developers. If you work in software industry you know many people big companies hire to work on much smaller projects. So be thankful it works as good as it does, it is actually a miracle that it works as good as it does Main issue is that wifi chip manufacturers don't offer open source wifi drivers. If Atheros and Broadcom understood Open source as Intel does then you would get absolutely top speed and reliability from OpenWrt wifi drivers. You don't get top notch performance with OpenWrt because Atheros and Broadcom are choosing not release quality open source drivers. Linux, BSDx and OpenWrt developers can only use other means to get wifi devices to work, usually reverse engineering, and without support from wifi chip companies it is not easy to support all features, get awesome performance and stability. This is a long way of saying, that if performance sucks on OpenWrt you should blame Atheros and Broadcom for not giving you (OpenWrt community) high quality open source drivers! ___ 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] ramips: Fix failsafe switch workaround for RT5350 introduced in r42179.
Il 10.03.2015 20:42 John Crispin ha scritto: we can hook this up with the board detect code. i'll put it on my todo list. might take a bit till i find the time That would be great! By the way, we should test if recent revisions fix the checksum issue so that we can completely remove this hacky workaround. On my RT5350-based HT-TM02, disabling VLAN and using eth0 works as of r43771, while it didn't work on r42649. (That's why I proposed http://patchwork.ozlabs.org/patch/424017/ at first.) But I don't have hardware based on other affected SoCs (rt3x5x, mt7628) to test. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ramips: Fix failsafe switch workaround for RT5350 introduced in r42179.
Il 10.03.2015 14:18 John Crispin ha scritto: hi can you send a version that has the pattern shown below please and 0 1 2 3 4 5 6 is wrong, exclude the wan port from the list please. John The problem is that it's not easy to determine what number the LAN or WAN port(s) is/are. On many routers a LAN port can be 0, but on the HT-TM02 there is only one port and it is 4. So the current 0 6 is effectively soft-bricking the HT-TM02 if failsafe is needed and one doesn't have a serial adapter... That's why I proposed to just enable all ports for failsafe. board=$(ramips_board_name) board_config_update ports=0 6 case $board in my_board_name) ports=0 1 2 3 4 5 6 ;; esac swconfig dev rt305x set enable_vlan 1 swconfig dev rt305x vlan 1 set ports $ports swconfig dev rt305x port 6 set untag 0 swconfig dev rt305x set apply 1 vconfig add eth0 1 This needs to be better addressed somehow, without replicating the port layout here for every router that does not have port 0 exposed at all. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Why OpenWrt sucks?
On Tue, 10 Mar 2015, valent.turko...@gmail.com wrote: Can anyone explain to me how NDAs come into this? Because I remember one discussions with Mikrotik developer who said that they can't release their Atheros driver that they developed as open source because they signed NDA with Atheros? Is Atheros giving some secret and proprietary information to companies that sign NDA with them? If this is true then we will never have as fast performance as companies that sign NDAs. Depending on the wording of the NDA, it may be (and frequently has been) possible to write open drivers after signing the NDA. It does limit a bit what you can explain in the comments in the drivers. In some cases (I believe a minority) the NDA prevents you from releasing the driver because the fact that it can get the hardware to do things is deemed 'secret' by the manufacturer. There are a lot of things in Linux that have been developed by developers who have signed NDAs to get access to the detailed specs and access to developers. David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] reply?? System halted on bcm4708 series board when booting openwrt trunk(kernel 3.14)
On 10 March 2015 at 04:43, Tymon banglang.hu...@foxmail.com wrote: my cpu is BCM958522ER which is the same series with 4708 as well, 32MB ###boot log: (I updated the xxx-squashfs.trx to the flash) Hit any key to stop autoboot: 0 Checking TRX Image at addr 1e20 ... Uncompressing ... Primary TRX image OK kernel args : console=ttyS0,115200 ubi.mtd=5 root=ubi0:rootfs ro rootflags=sync rootfstype=ubifs user_debug=31 Booting from Primary Partition kernel_args console=ttyS0,115200 ubi.mtd=5 root=ubi0:rootfs ro rootflags=sync rootfstype=ubifs user_debug=31 Start addr 8000 machid 127f Parmameter addr 0010 ... Starting kernel ... Uncompressing Linux... XZ-compressed data is corrupt -- System halted I want to know why this error arise, any hints will be appreciated. but the XZ-compressed data is corrupt is the message of openwrt-trunk kernel that under linux-3.14.xx/lib/compress_unxz.c +371___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Why OpenWrt sucks?
Hi Gergely, I'm just curious to know what makes you be pretty sure that many vendors will start doing this in the future and overcome the possible legal or political issues they may have to do that ? Marvel was one of the worst cases I've ever seen here and I have no much idea what made them to release it (a miracle maybe?). Unless you were referring to in the future as next century I don't see that happening that soon. Other than that I fully agree OpenWrt is great, well developed and maintained. Best, On 10/03/2015 17:26, Gergely Kiss wrote: Hi Valent, first of all, I strongly disagree with people claiming that OpenWrt sucks because it doesn't. For me it rather looks like a well-maintained, rapidly improving project with a great number of actively supported hardware and quite a few people contributing to the project regularly. I can see dozens of patches published every day not only by the core devs but by many contributors which is a great thing and indicates that many people are trying to make OpenWrt *even *better. I must mention you had a point that made me smile - it's about being a miracle that openwrt works as good as it does. This reminded me to the DNS system. As we all know, it was never developed with a concept of creating a complex network service to be used in a worldwide network but more like as a simple phonebook for companies, schools and other small, autonomous institutions to avoid the need to remember IP addresses. Now, DNS is used worldwide by thousands of entities and is probably one of the oldest protocols still actively used on the internet and it still works pretty good despite its age. Miracles do happen sometimes and that's what makes our lives brighter. :) Anyway, as far as I can see, more and more manufacturers (including wireless chip vendors) realize the benefits of open source and release their driver codes to the open source community. I clearly remember seeing some driver sources posted on this list directly by Marvell and I'm pretty sure that many other vendors will start doing so in the future. I think the reason why most vendors still haven't published their drivers is more like legal issues rather than technical or political ones. They have to meet regulatory requirements and respect the copyright of other people's work. Even if they would feel inclined to release their driver, they can't do so because of licensing issues. For people complaining about OpenWrt, I would simply tell them that first of all, it's provided for free for everyone in the world so stop complaining. Also, being an open source project, it's always open for contributions. Everyone has the possibility to share ideas or implement features making OpenWrt a more stable, more robust and more versatile piece of software. My fifty cents was to create a port of Seafile for OpenWrt - I'm using it myself at home and I'm very happy to see it running on my router with a USB HDD attached rather than running an additional home server 24/7 consuming more power and taking up more room in my flat. At the same time, I'm happy to provide the same ability to other people because that's how it's meant to be. Do you think OpenWrt sucks? Then stop complaining and do something to make it better. It's that simple. Cheers, Gergely On 9 March 2015 at 21:02, valent.turko...@gmail.com mailto:valent.turko...@gmail.com valent.turko...@gmail.com mailto:valent.turko...@gmail.com wrote: Hi all, I see this or similar question of forums all the time and I have answered it few times. I suggest we open a wiki page and contribute an answer. Here is how I usually reply to similar questions, please give your comments in your replies: Why it OpenWrt slower than stock firmware? I can help by shining a bit of light onto this subject. I'm developing custom firwmares based on OpenWrt but I'm not OpenWrt developer, still as I have few years of experience with OpenWrt I can explain why sometimes performance sucks or there are some issues and bugs. OpenWrt has three main parts; linux kernel, software packages and wireless drivers. OpenWrt developers work on all of them. Consider the amount of code this is, and consider that all work is done by a handful of OpenWrt developers. If you work in software industry you know many people big companies hire to work on much smaller projects. So be thankful it works as good as it does, it is actually a miracle that it works as good as it does Main issue is that wifi chip manufacturers don't offer open source wifi drivers. If Atheros and Broadcom understood Open source as Intel does then you would get absolutely top speed and reliability from OpenWrt wifi drivers. You don't get top notch performance with OpenWrt because Atheros and Broadcom are choosing not release quality open source drivers. Linux, BSDx and OpenWrt developers can only
Re: [OpenWrt-Devel] [RFC] mac80211: update to wireless-testing 2015-03-09
Hi Bryan, On Tue, Mar 10, 2015 at 12:15:31PM -0500, Bryan Forbes wrote: I have been working on an update to mac80211 for about a month now. I announced it on the developer forums, but it turns out this is the place I should have been talking about it. The initial work I did was to update mac80211 to wireless-testing master-2015-02-09, but since then I have updated to master-2015-03-09. All of the work I have done can be found on github: https://github.com/bryanforbes/openwrt/tree/bryan-2015-03-09 Nice work! Highly appreciated! I reckon hostapd should be bumped as well, but that can also be after the compat-wireless bump... I already did that locally, but didn't yes finally decide on how to package 802.11s and SAE support, i.e. have wpad-mesh and wpa_supplicant-mesh with dependency on libopenssl and including 802.11 and SAE support, but being otherwise identical to their -mini versions. And include SAE support in -full only if OpenSSL is the selected SSL provider as the build fails with internal crypto. See http://patchwork.ozlabs.org/patch/435311/ http://patchwork.ozlabs.org/patch/435312/ A good way would also be to bump hostapd to the current release and package the mesh and SAE stuff afterwards... Cheers Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Why OpenWrt sucks?
On 2015-03-10 20:22, Zefir Kurtisi wrote: On 03/09/2015 11:28 PM, David Lang wrote: On Mon, 9 Mar 2015, José Vázquez wrote: OpenWRT is a linux distro oriented to networking so the kernel and drivers are important, but you must not forget that the init process (procd and related after AA) is one of the cores of this distro and makes it work. The most relevant packages are oriented to networking, but with the feeds you can make anything that you want, making it very versatile. Also we must take in mind that OpenWRT works with GPL drivers and code (only few are proprietary); I think that one of the main advantages of use them is that anybody can contribute, and IMHO, are easy to maintain. One of the performance penalties come with the network drivers: while proprietary drivers are tightly coupled with the hardware, the drivers developed by OpenWRT guys and collaborators should not be so complicated because when the kernel version is changed they can generate a lot of problems and headaches, while more generic drivers do not take advantage of all the hardware features, overloading the cpu with tasks that in stock firmwares are managed by specific subsystems that are faster for those specific tasks. there is no reason why the open drivers need to be slower than the proprietary ones. History has shown that with sufficient information, the open drivers end up being as fast, or faster than the proprietary ones. But it does take time and cooperation with the manufacturer to do this with the latest hardware. At least for ath9k I can confirm that - if there is a performance disadvantage to the closed source reference driver at all - it is not because it is closed or keeps information secret. In fact, beside some very specific functions not useful for the common user, all relevant information from the reference driver already found its way into ath9k. With that, if there is a performance gap, it is because of the difference in architecture. Compared to the mac80211-ath9k combo, QCA's reference drivers are almost monolithic (ok, there is a mac and a hal, but with as much cross-layer optimizations as possible) and that is where you gain some speed percentage. Even the QCA reference driver has a separation between protocol stack and the hardware driver. Aside from the fact that its protocol stack is only used by its own driver, it is not significantly more monolithic in design. This gives at least two sources for optimization for the reference driver: 1) save inter-layer processing overhead (passing commands from hostapd directly to HW is cheaper than passing it through 4 layers), and 2) vastly reduce locking when you are in full control of concurrency. The overhead of commands issued by hostapd is pretty much irrelevant. All that matters for driver performance is the actual data path (network stack, mac80211 tx/rx, driver tx/rx). Also, I've not seen any indication in my tests that locking is a measurable cause of performance issues. When it comes to performance issues, guesswork is meaningless, measurements (e.g. profiling results) matter! - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Why OpenWrt sucks?
On Wed, 11 Mar 2015, Felix Fietkau wrote: On 2015-03-10 20:22, Zefir Kurtisi wrote: On 03/09/2015 11:28 PM, David Lang wrote: On Mon, 9 Mar 2015, José Vázquez wrote: This gives at least two sources for optimization for the reference driver: 1) save inter-layer processing overhead (passing commands from hostapd directly to HW is cheaper than passing it through 4 layers), and 2) vastly reduce locking when you are in full control of concurrency. The overhead of commands issued by hostapd is pretty much irrelevant. All that matters for driver performance is the actual data path (network stack, mac80211 tx/rx, driver tx/rx). Also, I've not seen any indication in my tests that locking is a measurable cause of performance issues. When it comes to performance issues, guesswork is meaningless, measurements (e.g. profiling results) matter! netperf-wrapper (https://github.com/tohojo/netperf-wrapper) defines a number of tests that we have found extremely useful in measuring bufferbloat (bad latency increases while large transfers are taking place), These tests show upload/download speeds as well as latency measurements. David Lang___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Why OpenWrt sucks?
On 03/09/2015 11:28 PM, David Lang wrote: On Mon, 9 Mar 2015, José Vázquez wrote: OpenWRT is a linux distro oriented to networking so the kernel and drivers are important, but you must not forget that the init process (procd and related after AA) is one of the cores of this distro and makes it work. The most relevant packages are oriented to networking, but with the feeds you can make anything that you want, making it very versatile. Also we must take in mind that OpenWRT works with GPL drivers and code (only few are proprietary); I think that one of the main advantages of use them is that anybody can contribute, and IMHO, are easy to maintain. One of the performance penalties come with the network drivers: while proprietary drivers are tightly coupled with the hardware, the drivers developed by OpenWRT guys and collaborators should not be so complicated because when the kernel version is changed they can generate a lot of problems and headaches, while more generic drivers do not take advantage of all the hardware features, overloading the cpu with tasks that in stock firmwares are managed by specific subsystems that are faster for those specific tasks. there is no reason why the open drivers need to be slower than the proprietary ones. History has shown that with sufficient information, the open drivers end up being as fast, or faster than the proprietary ones. But it does take time and cooperation with the manufacturer to do this with the latest hardware. At least for ath9k I can confirm that - if there is a performance disadvantage to the closed source reference driver at all - it is not because it is closed or keeps information secret. In fact, beside some very specific functions not useful for the common user, all relevant information from the reference driver already found its way into ath9k. With that, if there is a performance gap, it is because of the difference in architecture. Compared to the mac80211-ath9k combo, QCA's reference drivers are almost monolithic (ok, there is a mac and a hal, but with as much cross-layer optimizations as possible) and that is where you gain some speed percentage. This gives at least two sources for optimization for the reference driver: 1) save inter-layer processing overhead (passing commands from hostapd directly to HW is cheaper than passing it through 4 layers), and 2) vastly reduce locking when you are in full control of concurrency. Depending on the chip architecture used, the second factor is good for up to 10% of performance gap - which still is a low price for having a generalized multi-layer architecture with maximum flexibility over a highly optimized specialist. Open drivers can be modified along with the kernel to take advantage of the newest features in the kernel. Proprietary drivers are either written for one specific kernel, or with a shim layer that limits how well the driver can work with future kernels. David Lang ___ 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] Why OpenWrt sucks?
Hi Fernando, I cannot predict nor foresee what HW vendors will do in the future but it looks to me there's a trend like that. For example, there is some collaboration [1] between NVIDIA and the developers of the open source nouveau driver and also, Intel seems to release some of its codes as open source [2][3], too. Legal issues still hold vendors back from releasing their driver codes but at least, there is some level of collaboration now between vendors and open source developers which is a great step forwards compared to the times when reverse engineering was the only possible way to create drivers for open source OSes. Regards, Gergely 1: http://arstechnica.com/information-technology/2013/09/nvidia-seeks-peace-with-linux-pledges-help-on-open-source-driver/ 2: https://downloadcenter.intel.com/download/13815/Intel-Graphics-Drivers-for-Linux- 3: https://01.org/ On 10 March 2015 at 22:33, Fernando Frediani fhfredi...@gmail.com wrote: Hi Gergely, I'm just curious to know what makes you be pretty sure that many vendors will start doing this in the future and overcome the possible legal or political issues they may have to do that ? Marvel was one of the worst cases I've ever seen here and I have no much idea what made them to release it (a miracle maybe?). Unless you were referring to in the future as next century I don't see that happening that soon. Other than that I fully agree OpenWrt is great, well developed and maintained. Best, On 10/03/2015 17:26, Gergely Kiss wrote: Hi Valent, first of all, I strongly disagree with people claiming that OpenWrt sucks because it doesn't. For me it rather looks like a well-maintained, rapidly improving project with a great number of actively supported hardware and quite a few people contributing to the project regularly. I can see dozens of patches published every day not only by the core devs but by many contributors which is a great thing and indicates that many people are trying to make OpenWrt *even *better. I must mention you had a point that made me smile - it's about being a miracle that openwrt works as good as it does. This reminded me to the DNS system. As we all know, it was never developed with a concept of creating a complex network service to be used in a worldwide network but more like as a simple phonebook for companies, schools and other small, autonomous institutions to avoid the need to remember IP addresses. Now, DNS is used worldwide by thousands of entities and is probably one of the oldest protocols still actively used on the internet and it still works pretty good despite its age. Miracles do happen sometimes and that's what makes our lives brighter. :) Anyway, as far as I can see, more and more manufacturers (including wireless chip vendors) realize the benefits of open source and release their driver codes to the open source community. I clearly remember seeing some driver sources posted on this list directly by Marvell and I'm pretty sure that many other vendors will start doing so in the future. I think the reason why most vendors still haven't published their drivers is more like legal issues rather than technical or political ones. They have to meet regulatory requirements and respect the copyright of other people's work. Even if they would feel inclined to release their driver, they can't do so because of licensing issues. For people complaining about OpenWrt, I would simply tell them that first of all, it's provided for free for everyone in the world so stop complaining. Also, being an open source project, it's always open for contributions. Everyone has the possibility to share ideas or implement features making OpenWrt a more stable, more robust and more versatile piece of software. My fifty cents was to create a port of Seafile for OpenWrt - I'm using it myself at home and I'm very happy to see it running on my router with a USB HDD attached rather than running an additional home server 24/7 consuming more power and taking up more room in my flat. At the same time, I'm happy to provide the same ability to other people because that's how it's meant to be. Do you think OpenWrt sucks? Then stop complaining and do something to make it better. It's that simple. Cheers, Gergely On 9 March 2015 at 21:02, valent.turko...@gmail.com valent.turko...@gmail.com wrote: Hi all, I see this or similar question of forums all the time and I have answered it few times. I suggest we open a wiki page and contribute an answer. Here is how I usually reply to similar questions, please give your comments in your replies: Why it OpenWrt slower than stock firmware? I can help by shining a bit of light onto this subject. I'm developing custom firwmares based on OpenWrt but I'm not OpenWrt developer, still as I have few years of experience with OpenWrt I can explain why sometimes performance sucks or there are some issues and bugs. OpenWrt has three main
[OpenWrt-Devel] [PATCH] Fix 3.18.8 breakage of UBI devices with EOF marker (e.g. WNDR4300)
This commit re-adds a patch from 3.14 that is required for UBI block
devices with an EOF marker to be successfully mounted.
Signed-off-by: Oliver Smith oli...@8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa
---
.../490-mtd-ubi-add-EOF-marker-support.patch | 51 ++
1 file changed, 51 insertions(+)
create mode 100644
target/linux/generic/patches-3.18/490-mtd-ubi-add-EOF-marker-support.patch
diff --git
a/target/linux/generic/patches-3.18/490-mtd-ubi-add-EOF-marker-support.patch
b/target/linux/generic/patches-3.18/490-mtd-ubi-add-EOF-marker-support.patch
new file mode 100644
index 000..cd02c13
--- /dev/null
+++ b/target/linux/generic/patches-3.18/490-mtd-ubi-add-EOF-marker-support.patch
@@ -0,0 +1,51 @@
+--- a/drivers/mtd/ubi/attach.c
b/drivers/mtd/ubi/attach.c
+@@ -800,6 +800,13 @@ out_unlock:
+ return err;
+ }
+
++static bool ec_hdr_has_eof(struct ubi_ec_hdr *ech)
++{
++ return ech-padding1[0] == 'E'
++ ech-padding1[1] == 'O'
++ ech-padding1[2] == 'F';
++}
++
+ /**
+ * scan_peb - scan and process UBI headers of a PEB.
+ * @ubi: UBI device description object
+@@ -830,9 +837,21 @@ static int scan_peb(struct ubi_device *u
+ return 0;
+ }
+
+- err = ubi_io_read_ec_hdr(ubi, pnum, ech, 0);
+- if (err 0)
+- return err;
++ if (!ai-eof_found) {
++ err = ubi_io_read_ec_hdr(ubi, pnum, ech, 0);
++ if (err 0)
++ return err;
++
++ if (ec_hdr_has_eof(ech)) {
++ ubi_msg(EOF marker found, PEBs from %d will be erased,
++ pnum);
++ ai-eof_found = true;
++ }
++ }
++
++ if (ai-eof_found)
++ err = UBI_IO_FF_BITFLIPS;
++
+ switch (err) {
+ case 0:
+ break;
+--- a/drivers/mtd/ubi/ubi.h
b/drivers/mtd/ubi/ubi.h
+@@ -701,6 +701,7 @@ struct ubi_attach_info {
+ int mean_ec;
+ uint64_t ec_sum;
+ int ec_count;
++ bool eof_found;
+ struct kmem_cache *aeb_slab_cache;
+ };
+
--
2.2.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
