[OpenWrt-Devel] Linux IP Virtual Server for OpenWrt trunk or github?

[Mauro Mozzarelli]

All,

I have been having conversations with John on whether to include ipvs and 
ipvsadm in
trunk or github. Initially I did not know of github and thanks to John's 
patience now I
have a better understanding of the differences between the two.

IP Virtual server is provided by kernel modules that have been available  since 
kernel
release 2.4. For some reasons these were always omitted by OpenWrt

IP Virtual server is part of kernel netfilter and lives together with IP NAT and
netfilter modules.

IP Netfilter has a userland tool to configure the kernel tables: iptables. 
Similarly IP
Virtual server has a tool named ipvsadm to configure the ip vs kernel tables.

ipvsadm is fundamental to ip vs. It stands to ip vs kernel modules like 
iptables stands
to ip netfilter modules. ipvsadm has been adopted by the linux kernel project 
and it is
available here: https://www.kernel.org/pub/linux/utils/kernel/ipvsadm/

OpenWrt:
The ip_vs kernel configuration is achieved by activating the relative ip_vs 
modules build
with a simple modification of OpenWrt's netfilter.mk

Logically ipvsadm belongs to the same OpenWrt folder where iptables is.

That is the reason I created the package there (package/network/utils/ipvsadm) 
in the
first place.

Now that I understand more about github packages, I am convinced that ipvsadm 
does not
belong there as it isn't yet another userland tool. It is a tool which is 
strictly
linked to kernel capabilities and it is essential to IP VS kernel modules.

For this reason I believe it should be included in the core trunk OpenWrt.

I would be grateful if you could take the time to review the ipvs and ipvsadm 
patches
and consider them to be included in OpenWrt.

I believe it would add great value to OpenWrt.

Before building the modules for OpenWrt, back in January I contacted Sebastian 
Gotschall
of DD-WRT who kindly included the IP Virtual server modules and ipvsadm in only 
two
weeks. IP Virtual Server load balancer has now become part of the core DD-WRT 
firmware.
I hope sincerely that it will be soon included in OpenWrt too.

Best regards,
Mauro
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Request for Feedback - prplwrt Software Support Program - initial draft

[Saverio Proto]

> I don't have a number off hand, that's still being decided. My feeling has
> been that's it'd be in the tens of thousands USD total. I'll try to get more
> of finalized amount as soon as possible.

Hello Eric,

considering that a Senior Engineer in the SF Bay Area has an average
income of 120.000 USD per year... a contribution on terms of tens of
thousands dollars does not cover even the work of one person for one
year. Should we for this little money involve an american foundation
in the decisional processes ?

My feeling is that prpl is an American foundation that is throwing
penauts to a successfull open source project to have development at
low cost.
A company that hires a team of developer for a Carrier Grade OpenWrt
spends more than 100.000 USD per year in development cost.

You are right, there is a conflict between the community and prpl, so
you have to convince us better :)

Best regards

Saverio
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ar71xx: Arduino Yun board 'WLAN RST' button support

[Hirokazu MORIKAWA]

RESEND: This patch is a support for Arduino Yun board "WLAN RST" button.
# sorry 


Signed-off-by: Hirokazu MORIKAWA 
---
 .../ar71xx/files/arch/mips/ath79/mach-arduino-yun.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-arduino-yun.c 
b/target/linux/ar71xx/files/arch/mips/ath79/mach-arduino-yun.c
index d55d542..5873248 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-arduino-yun.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-arduino-yun.c
@@ -60,6 +60,17 @@ static struct gpio_led ds_leds_gpio[] __initdata = {
},
 };
 
+static struct gpio_keys_button ds_gpio_keys[] __initdata = {
+   {
+   .desc   = "configuration button",
+   .type   = EV_KEY,
+   .code   = KEY_WPS_BUTTON,
+   .debounce_interval = DS_KEYS_DEBOUNCE_INTERVAL,
+   .gpio   = DS_GPIO_CONF_BTN,
+   .active_low = 1,
+   },
+};
+
 static void __init ds_common_setup(void)
 {
static u8 mac[6];
@@ -97,8 +108,18 @@ static void __init ds_setup(void)
 
ath79_register_leds_gpio(-1, ARRAY_SIZE(ds_leds_gpio),
 ds_leds_gpio);
+   ath79_register_gpio_keys_polled(-1, DS_KEYS_POLL_INTERVAL,
+   ARRAY_SIZE(ds_gpio_keys),
+   ds_gpio_keys);
ath79_register_usb();
 
+   /* use the swtich_led directly form sysfs */
+   ath79_gpio_function_disable(AR933X_GPIO_FUNC_ETH_SWITCH_LED0_EN |
+   
AR933X_GPIO_FUNC_ETH_SWITCH_LED1_EN |
+   
AR933X_GPIO_FUNC_ETH_SWITCH_LED2_EN |
+   
AR933X_GPIO_FUNC_ETH_SWITCH_LED3_EN |
+   
AR933X_GPIO_FUNC_ETH_SWITCH_LED4_EN);
+
//Disable the Function for some pins to have GPIO functionality active
// GPIO6-7-8 and GPIO11
ath79_gpio_function_setup(AR933X_GPIO_FUNC_JTAG_DISABLE | 
AR933X_GPIO_FUNC_I2S_MCK_EN, 0);
-- 
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH RFC] brcm47xx: image: create common TRX images using new building system

[Rafał Miłecki]

Apart from using our new building system there are 2 more changes:

1) Limit amount of images
So far we were generating all common images (standard one and two with
no loader) for every SUBTARGET. This is not needed, as e.g. the only
device requiring gzipped kernel is legacy Huawei E970.

2) Change output names
The new image building system requires specifying device name. This
forced picking some and resulted in:
openwrt-brcm47xx-$(SUBTARGET)-squashfs.trx
openwrt-brcm47xx-$(SUBTARGET)-squashfs-gz.trx
openwrt-brcm47xx-$(SUBTARGET)-squashfs-noloader-nodictionary.trx
becoming:
openwrt-brcm47xx-$(SUBTARGET)-common-squashfs.trx
openwrt-brcm47xx-$(SUBTARGET)-common-noloader-gz-squashfs.trx
openwrt-brcm47xx-$(SUBTARGET)-common-noloader-nodictionarylzma-squashfs.trx
---
I hope this change will make creating releases much easier. So far we
got some problems to get final TRX images matching device images.

I'm a bit unsure about adding this extra "-common" to output names. I'm
afraid ppl may got used to the old simple names. On the other handle our
new images building system doesn't allow keeping old names.
Maybe we could add support for some extra callback like Image/Finish and
rename them there?
---
 target/linux/brcm47xx/image/Makefile | 34 +++---
 1 file changed, 19 insertions(+), 15 deletions(-)

diff --git a/target/linux/brcm47xx/image/Makefile 
b/target/linux/brcm47xx/image/Makefile
index bbdb36b..e452136 100644
--- a/target/linux/brcm47xx/image/Makefile
+++ b/target/linux/brcm47xx/image/Makefile
@@ -141,6 +141,19 @@ define Device/Default
IMAGE/trx := trx-with-loader
 endef
 
+define Device/common
+endef
+
+define Device/common-noloader-gz
+   KERNEL_NAME = vmlinux.gz
+   IMAGE/trx := trx-without-loader
+endef
+
+define Device/common-noloader-nodictionarylzma
+   KERNEL_NAME = vmlinux-nodictionary.lzma
+   IMAGE/trx := trx-without-loader
+endef
+
 define Device/asus
IMAGES := trx
IMAGE/trx := trx-with-loader | asus-trx
@@ -209,6 +222,8 @@ ifeq ($(SUBTARGET),generic)
   # BCMA SoC with SSB WiFi
   $(eval $(call LinksysDevice,wrt610n-v2,610N,2.0.0))
   $(eval $(call LinksysDevice,e3000-v1,61XN,1.0.3))
+
+  TARGET_DEVICES += common
 endif
 
 #
@@ -300,6 +315,8 @@ ifeq ($(SUBTARGET),legacy)
   $(eval $(call NetgearDevice,wgr614-v8,U12H072T00_NETGEAR,2))
   $(eval $(call NetgearDevice,wndr3300-v1,U12H093T00_NETGEAR,2))
   $(eval $(call NetgearDevice,wnr834b-v2,U12H081T00_NETGEAR,2))
+
+  TARGET_DEVICES += common common-noloader-gz
 endif
 
 #
@@ -359,6 +376,8 @@ ifeq ($(SUBTARGET),mips74k)
 #  $(eval $(call NetgearDevice,wnr3500u,U12H136T00_NETGEAR,2))
   $(eval $(call NetgearDevice,wnr3500-v2,U12H127T00_NETGEAR,2))
 #  $(eval $(call NetgearDevice,wnr3500-v2-vc,U12H127T70_NETGEAR,2))
+
+  TARGET_DEVICES += common common-noloader-nodictionarylzma
 endif
 
 #
@@ -379,21 +398,6 @@ endef
 
 # $(1): filesystem type.
 define Image/Build
-   $(STAGING_DIR_HOST)/bin/trx \
-   -m 33554432 \
-   -o $(BIN_DIR)/$(IMG_PREFIX)-$(1).trx \
-   -f $(KDIR)/loader.gz -f $(KDIR)/vmlinux.lzma \
-   $(call trxalign/$(1),$(1))
-   $(STAGING_DIR_HOST)/bin/trx \
-   -m 33554432 \
-   -o $(BIN_DIR)/$(IMG_PREFIX)-$(1)-noloader-nodictionary.trx \
-   -f $(KDIR)/vmlinux-nodictionary.lzma \
-   $(call trxalign/$(1),$(1))
-   $(STAGING_DIR_HOST)/bin/trx \
-   -m 33554432 \
-   -o $(BIN_DIR)/$(IMG_PREFIX)-$(1)-gz.trx \
-   -f $(KDIR)/vmlinux.gz \
-   $(call trxalign/$(1),$(1))
 ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),)
$(call Image/Build/Initramfs)
 endif
-- 
1.8.4.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] tools/cmake: fix compile on Alpine Linux

[John Crispin]

On 08/03/2016 07:52, John Crispin wrote:
> 
> 
> On 07/03/2016 22:08, Dirk Neukirchen wrote:
>> internal jsoncpp include order leads to multiple build
>> errors on Alpine Linux which uses musl libc
>>
>> use include order from upstream jsoncpp
>>
>> first error was:
>> In file included from /usr/include/c++/5.3.0/stdexcept:38:0,
>>  from 
>> /home//openwrt/build_dir/host/cmake-3.4.3/Utilities/cmjsoncpp/include/json/assertions.h:16,
>>  from 
>> /home//openwrt/build_dir/host/cmake-3.4.3/Utilities/cmjsoncpp/src/lib_json/json_reader.cpp:7:
>> /usr/include/c++/5.3.0/exception:35:9: error: '#pragma' is not allowed here
>>  #pragma GCC visibility push(default)
>>
> 
> Hi,
> 
> all musl patches need to be submitted to the musl mailing list first.
> maybe you have done so already. if not it would be great if you could do so.
> 
>   John
> 

brainfart, this is not a musl patch but a cmake patch. i'll pick this
one up on the next merge round.

John

>> Signed-off-by: Dirk Neukirchen 
>> ---
>>  tools/cmake/patches/120-alpine_musl-compat.patch | 17 +
>>  1 file changed, 17 insertions(+)
>>  create mode 100644 tools/cmake/patches/120-alpine_musl-compat.patch
>>
>> diff --git a/tools/cmake/patches/120-alpine_musl-compat.patch 
>> b/tools/cmake/patches/120-alpine_musl-compat.patch
>> new file mode 100644
>> index 000..ae93201
>> --- /dev/null
>> +++ b/tools/cmake/patches/120-alpine_musl-compat.patch
>> @@ -0,0 +1,17 @@
>> +--- a/Utilities/cmjsoncpp/include/json/assertions.h
>>  b/Utilities/cmjsoncpp/include/json/assertions.h
>> +@@ -6,12 +6,12 @@
>> + #ifndef CPPTL_JSON_ASSERTIONS_H_INCLUDED
>> + #define CPPTL_JSON_ASSERTIONS_H_INCLUDED
>> + 
>> ++#include 
>> ++
>> + #if !defined(JSON_IS_AMALGAMATION)
>> + #include "config.h"
>> + #endif // if !defined(JSON_IS_AMALGAMATION)
>> + 
>> +-#include 
>> +-
>> + #if JSON_USE_EXCEPTION
>> + #include 
>> + #define JSON_ASSERT(condition) 
>> \
>>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] odhcp6c : Silence mtu write error warnings

[Hans Dedecker]

Silence warning "daemon.notice netifd: wan6 (1139): sh: write error: Invalid 
argument"
when an invalid MTU is received via RA as kernel refuses to accept IPv6 mtu 
values
which are smaller than 1280 and bigger than the device mtu.

Signed-off-by: Hans Dedecker 
---
 package/network/ipv6/odhcp6c/files/dhcpv6.script | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/network/ipv6/odhcp6c/files/dhcpv6.script 
b/package/network/ipv6/odhcp6c/files/dhcpv6.script
index c307d09..46980cb 100755
--- a/package/network/ipv6/odhcp6c/files/dhcpv6.script
+++ b/package/network/ipv6/odhcp6c/files/dhcpv6.script
@@ -185,7 +185,7 @@ setup_interface () {
# Apply IPv6 / ND configuration
HOPLIMIT=$(cat /proc/sys/net/ipv6/conf/$device/hop_limit)
[ -n "$RA_HOPLIMIT" -a -n "$HOPLIMIT" ] && [ "$RA_HOPLIMIT" -gt 
"$HOPLIMIT" ] && echo "$RA_HOPLIMIT" > /proc/sys/net/ipv6/conf/$device/hop_limit
-   [ -n "$RA_MTU" ] && [ "$RA_MTU" -gt 0 ] && echo "$RA_MTU" > 
/proc/sys/net/ipv6/conf/$device/mtu
+   [ -n "$RA_MTU" ] && [ "$RA_MTU" -ge 1280 ] && echo "$RA_MTU" > 
/proc/sys/net/ipv6/conf/$device/mtu 2>/dev/null
[ -n "$RA_REACHABLE" ] && [ "$RA_REACHABLE" -gt 0 ] && echo 
"$RA_REACHABLE" > /proc/sys/net/ipv6/neigh/$device/base_reachable_time_ms
[ -n "$RA_RETRANSMIT" ] && [ "$RA_RETRANSMIT" -gt 0 ] && echo 
"$RA_RETRANSMIT" > /proc/sys/net/ipv6/neigh/$device/retrans_time_ms
 
-- 
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 0/7] kirkwood 4.4

[Martin Mueller]

On Mon, Mar 07, 2016 at 09:02:49PM +0100, Alexander Couzens wrote:
> Based on previous patch series ubi for dockstar.
> 
> To install the new ubi style on goflexnet:
> - update bootloader (use the same bootloader as of goflexhome)
> The goflexnet has a not as old SoC like the dockstar,
> which means a recovery of a broken bootloader is easy using
> uart recovery via kwboot

[...]

Thanks, tested on my gloflexHome and works.

bye
  MM
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?


signature.asc
Description: Digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Linux IP Virtual Server for OpenWrt trunk or github?

[Felix Fietkau]

On 2016-03-09 09:24, Mauro Mozzarelli wrote:
> All,
> 
> I have been having conversations with John on whether to include ipvs and 
> ipvsadm in
> trunk or github. Initially I did not know of github and thanks to John's 
> patience now I
> have a better understanding of the differences between the two.
> 
> IP Virtual server is provided by kernel modules that have been available  
> since kernel
> release 2.4. For some reasons these were always omitted by OpenWrt
> 
> IP Virtual server is part of kernel netfilter and lives together with IP NAT 
> and
> netfilter modules.
> 
> IP Netfilter has a userland tool to configure the kernel tables: iptables. 
> Similarly IP
> Virtual server has a tool named ipvsadm to configure the ip vs kernel tables.
> 
> ipvsadm is fundamental to ip vs. It stands to ip vs kernel modules like 
> iptables stands
> to ip netfilter modules. ipvsadm has been adopted by the linux kernel project 
> and it is
> available here: https://www.kernel.org/pub/linux/utils/kernel/ipvsadm/
> 
> OpenWrt:
> The ip_vs kernel configuration is achieved by activating the relative ip_vs 
> modules build
> with a simple modification of OpenWrt's netfilter.mk
> 
> Logically ipvsadm belongs to the same OpenWrt folder where iptables is.

> That is the reason I created the package there 
> (package/network/utils/ipvsadm) in the
> first place.
> 
> Now that I understand more about github packages, I am convinced that ipvsadm 
> does not
> belong there as it isn't yet another userland tool. It is a tool which is 
> strictly
> linked to kernel capabilities and it is essential to IP VS kernel modules.
> 
> For this reason I believe it should be included in the core trunk OpenWrt.
Not all packages on github are plain userland tools, there are kernel
modules there and there are also packages without which the
corresponding kernel functionality is useless (e.g. ipsec).

The split of trunk vs packages is about who maintains the package, and
in some cases also about the relative importance of the package as well.
Packages in trunk are usually maintained by core developers, whereas
packages on github are more of a community project.

In OpenWrt, ipvs is a relatively exotic use case, so I believe that
asking you to submit it to github instead of trunk is reasonable.
The exception of course is the kernel module part, since it's just a
small piece of metadata.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] procd: support pidfile writing.

[Karl Palsson]

From: Karl Palsson 

procd from revision b12bb150ed38a4409bef5127c77b060ee616b860 supports
writing a pidfile.  This adds support for setting that parameter with
standard init script hooks:

   procd_set_param pidfile /var/run/someprocess.pid

Signed-off-by: Karl Palsson 
---
 package/system/procd/files/procd.sh | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/package/system/procd/files/procd.sh 
b/package/system/procd/files/procd.sh
index 78b0162..6519561 100644
--- a/package/system/procd/files/procd.sh
+++ b/package/system/procd/files/procd.sh
@@ -19,6 +19,7 @@
 # netdev: bound network device (detects ifindex changes)
 # limits: resource limits (passed to the process)
 # user info: array with 1 values $username
+# pidfile: file name to write pid into
 #
 #   No space separation is done for arrays/tables - use one function argument 
per command line argument
 #
@@ -195,7 +196,7 @@ _procd_set_param() {
nice)
json_add_int "$type" "$1"
;;
-   user|seccomp|capabilities)
+   pidfile|user|seccomp|capabilities)
json_add_string "$type" "$1"
;;
stdout|stderr|no_new_privs)
-- 
2.4.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] new build of cc

[tapper]

Hi any news on the new update to cc pleas. I am wating on the ath10k 
firmware update for the c7v2 I no you cant give a ETA... thanks

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Request for Feedback - prplwrt Software Support Program - initial draft

[Kathy Giori]

On Wed, Mar 9, 2016 at 9:58 AM, Saverio Proto  wrote:
>> I don't have a number off hand, that's still being decided. My feeling has
>> been that's it'd be in the tens of thousands USD total. I'll try to get more
>> of finalized amount as soon as possible.
>
> Hello Eric,
>
> considering that a Senior Engineer in the SF Bay Area has an average
> income of 120.000 USD per year... a contribution on terms of tens of
> thousands dollars does not cover even the work of one person for one
> year. Should we for this little money involve an american foundation
> in the decisional processes ?
>
> My feeling is that prpl is an American foundation that is throwing
> penauts to a successfull open source project to have development at
> low cost.
> A company that hires a team of developer for a Carrier Grade OpenWrt
> spends more than 100.000 USD per year in development cost.
>
> You are right, there is a conflict between the community and prpl, so
> you have to convince us better :)
>
> Best regards
>
> Saverio

Saverio and all,

Let me offer a few thoughts, since I've been involved in prpl since
the beginning, and you can either praise (preferred) or blame me for
initiating the prplwrt PEG. :)

My initial goal was simple -- improved industry-community
collaboration. But my secondary goal, assuming trust relationships
would be established, had also been the idea of funding OpenWrt
developers via prpl. Why not industry direct? Partly not to skew the
project toward one specific vendor, but also because industry-direct
funding to individual developers, or even professional services
companies out of country of the funder, can be problematic
(logistically/legally). I lived through some painful attempts.

It is wasteful to see industry re-invent the wheel in
custom/proprietary or even open source ways, when there are FOSS
solutions to a problem. Sometimes industry isn't aware (shame for not
looking harder), but often they worry about lack of "control". If prpl
could establish the means to collaborate effectively, then we can
discourage industry from either being completely redundant, or from
forking FOSS projects such as OpenWrt (and direct kernel hacks) into
hard-to-maintain dead ends.

Regarding PSSP:

1. Frequency. The PSSP funding cycle as proposed is twice per year,
and that timeline includes the process of bringing forward ideas,
prioritizing them, and then selecting as many implementers as the
cycle of that budget allows. "Big" ideas therefore will need to be
broken down into pieces. For example, with a goal of auto-update, it
may start with a proposed framework or pre-requisite security feature.
An idea for cycle 1 could even be a "study" of various autoupdate
frameworks and options -- a thorough due diligence analysis, having a
reviewed document as the deliverable.

2. Non-exclusivity. There is nothing stopping a prpl member or
non-member business from funding any of the proposed project ideas
outside of prpl. Going back to the "relationship" and collaboration
goal, prpl organizes weekly calls, participates in related industry
meetings, and sponsors face-to-face (plus streamed) OpenWrt Summits.
These are useful to expose industry and community developers to each
other so that they can better collaborate, openly and/or under
contract.

3. Positive feedback. If early funding cycle projects are a big
success, highly valued by prpl members (and the community), then I
would expect that subsequent funding rounds may increase in scope and
budget.

4. Themes. Eric mentioned "carrier grade" features. For example
(courtesy of an HGI member):
a. Network interface diffs between carrier gateways and retail
routers. Multiple WAN, VLANS, hybrid streams, ...
b. End-to-end QoS/QoE. IPTV reliability, network discovery, spectrum
management for LAN/WLAN optimization, inter AP comms, ...
c. Telephony support. VoIP, DECT/Cat-iq, FXS/FXO, ...
d. Network acceleration offload. Common framework for hw and/or sw
based packet processing and acceleration in order to achieve line rate
throughout.
e. Remote mgmt and firmware or software upgrades. Securely. Include
framework for smart gateway -- downloading 3rd party apps.
f. Secure firmware. (Need key management analysis - who holds what
keys?) Carriers want to protect certain resources such as networking
and root gateway management while allowing openness to 3rd party
software and services. Want to convince vendors to enable flexibility
for technologists, tinkerers, and innovators to unlock hardware for
innovation and research, to include full networking stack.
g. Power saving. Newer SoCs have more power control knobs -- invoke a
framework to take advantage of reduced power modes.
h. Automated testing. Already have a start at github.com/qca/boardfarm.
i. Deployment support. Dependency on remote management, but to include
confidence that major kernel upgrades can occur over time, for
increased performance and decreased security risks.
j. App environment. For installing 3rd party software and serv

Re: [OpenWrt-Devel] [RFC 2/3] kernel: owl-loader for delayed Atheros ath9k fixup

[Christian Lamparter]

On Wednesday, March 09, 2016 07:59:28 AM Martin Blumenstingl wrote:
> On Wed, Mar 9, 2016 at 12:14 AM, Christian Lamparter
>  wrote:
> > Some devices (like the Cisco Meraki Z1 Cloud Managed Teleworker Gateway)
> > need to be able to initialize the PCIe wifi device. Normally, this is done
> > during the early stages of booting linux, because the necessary init code
> > is read from the memory mapped SPI and passed to pci_enable_ath9k_fixup.
> > However,this isn't possible for devices which have the init code for the
> > Atheros chip stored on NAND. Hence, this module can be used to initialze
> > the chip when the user-space is ready to extract the init code.
> I assume that you are speaking of UBI when you said "NAND".
> This case is tricky indeed, because the UBI initialization starts as
> late_initcall. Additionally there is some event-handling inside
> UBI/ubifs which makes it hard to read from an ubi volume from another
> kernel driver.
Yes, handling UBI is the tricky part. We depend on user-space's 
10-ath9k-eeprom script to extract the caldata partition. But this
is what all other ar71xx generic (c-55) and NAND devices do as well.

> Mathias and I have already experimented with reading calibration data
> from an UBI volume (we started with MAC addresses, but it will be the
> same for the ath9k caldata).
> It sounds easy at first sight, but it turns out to be tricky.
>
> I would like to find a generic solution for this (which does not
> depend on the ar71xx target) because we probably need the same code
> for the lantiq target as well.
Except for the call to "pci_enable_ath9k_fixup" [0] (which supplies
the caldata to the ath9k pci fixup routine). The owl-loader should be
platform-independent. it registers a pci driver for the dodgy pci-ids
and does little else than downloading the caldata and remove the old
device and force a pci rescan.

I've looked into lantiq (and BCM63XX) target a bit.

BCM63XX has already a function called pci_enable_ath9k_fixup, but uses
a slightly different signature. Instead of a pointer to the caldata is
supplies an offset And BCM63XX also uses it for fixing rt2x00 device
as well.

lantiq on the other hand has copied the func from ar71xx and adapted 
and renamed it, but kept the signature:
ltq_pci_ath_fixup(unsigned slot, u16 *cal_data)
it's in arch/mips/lantiq/xway/pci-ath-fixup.c.


So far, these are all for MIPS, or does anyone know of a different 
architecture or device that need a pci_fixup? I'm not sure how to
handle the rt2x00 though. Because otherwise we could just have
something like register_pci_fixup(slot, cal_data) for now.

Regards,
Christian

[0] 

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 0/2] brcm2708: Add WiFi support for Raspberry Pi 3

[Álvaro Fernández Rojas]

These patches add support for WiFi on the Raspberry Pi 3.

Log: 
https://gist.github.com/Noltari/92f51259c9d18506192b#file-brcm2710_rpi3_wifi-log

Considerations:
1) No firmware files provided until licenses are clarified:
https://github.com/raspberrypi/linux/issues/1325
For now the user has to manually download brcmfmac43430-sdio.bin and
brcmfmac43430-sdio.txt files to /lib/firmware/brcm.
2) Power managment isn't properly working, so it needs to be disabled.

Álvaro Fernández Rojas (2):
  brcm2708: update patches to latest version
  brcmfmac: Add Raspberry Pi 3 support

 package/kernel/mac80211/Makefile   |   1 +
 .../345-brcmfmac-Disable-power-management.patch|  27 
 .../brcm2708/bcm2710/profiles/RaspberryPi3.mk  |   1 +
 target/linux/brcm2708/modules.mk   |   7 +-
 ...port-for-the-CONFIG_CMDLINE_EXTEND-option.patch |   0
 ...171-BCM270X_DT-Add-pi3-disable-bt-overlay.patch |  96 
 ...BCM270X_DT-Add-pi3-miniuart-bt-DT-overlay.patch | 117 ++
 ...-Pi3-DT-Add-dtparams-for-the-SD-interface.patch |  25 +++
 .../0174-vchiq_arm-Tweak-the-logging-output.patch  |  75 +
 ...bcm2835-sdhost-Only-claim-one-DMA-channel.patch | 160 +++
 ...76-bcm2835-mmc-Only-claim-one-DMA-channel.patch | 170 +
 .../0177-config-rebuild-with-savedefconfig.patch   |  28 
 .../0178-config-Add-module-for-mcp3422-ADC.patch   |  30 
 ...-Pi3-DT-Add-pull-ups-on-the-UART-RX-lines.patch |  40 +
 .../patches-4.4/1000-mfd-rpisense-disable.patch|  10 ++
 .../1001-smsc95xx-disable-hw-csum.patch|  11 ++
 16 files changed, 792 insertions(+), 6 deletions(-)
 create mode 100644 
package/kernel/mac80211/patches/345-brcmfmac-Disable-power-management.patch
 mode change 100755 => 100644 
target/linux/brcm2708/patches-4.4/0051-fdt-Add-support-for-the-CONFIG_CMDLINE_EXTEND-option.patch
 create mode 100644 
target/linux/brcm2708/patches-4.4/0171-BCM270X_DT-Add-pi3-disable-bt-overlay.patch
 create mode 100644 
target/linux/brcm2708/patches-4.4/0172-BCM270X_DT-Add-pi3-miniuart-bt-DT-overlay.patch
 create mode 100644 
target/linux/brcm2708/patches-4.4/0173-Pi3-DT-Add-dtparams-for-the-SD-interface.patch
 create mode 100644 
target/linux/brcm2708/patches-4.4/0174-vchiq_arm-Tweak-the-logging-output.patch
 create mode 100644 
target/linux/brcm2708/patches-4.4/0175-bcm2835-sdhost-Only-claim-one-DMA-channel.patch
 create mode 100644 
target/linux/brcm2708/patches-4.4/0176-bcm2835-mmc-Only-claim-one-DMA-channel.patch
 create mode 100644 
target/linux/brcm2708/patches-4.4/0177-config-rebuild-with-savedefconfig.patch
 create mode 100644 
target/linux/brcm2708/patches-4.4/0178-config-Add-module-for-mcp3422-ADC.patch
 create mode 100644 
target/linux/brcm2708/patches-4.4/0179-Pi3-DT-Add-pull-ups-on-the-UART-RX-lines.patch
 create mode 100644 
target/linux/brcm2708/patches-4.4/1000-mfd-rpisense-disable.patch
 create mode 100644 
target/linux/brcm2708/patches-4.4/1001-smsc95xx-disable-hw-csum.patch

-- 
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 1/2] brcm2708: update patches to latest version

[Álvaro Fernández Rojas]

As usual these patches were extracted from the raspberry repo:
https://github.com/raspberrypi/linux/commits/rpi-4.4.y

- Disable unused MFD RPISENSE driver.
- Disable ethernet HW checksums in order to avoid kernel exceptions.

Signed-off-by: Álvaro Fernández Rojas 
---
 target/linux/brcm2708/modules.mk   |   7 +-
 ...port-for-the-CONFIG_CMDLINE_EXTEND-option.patch |   0
 ...171-BCM270X_DT-Add-pi3-disable-bt-overlay.patch |  96 
 ...BCM270X_DT-Add-pi3-miniuart-bt-DT-overlay.patch | 117 ++
 ...-Pi3-DT-Add-dtparams-for-the-SD-interface.patch |  25 +++
 .../0174-vchiq_arm-Tweak-the-logging-output.patch  |  75 +
 ...bcm2835-sdhost-Only-claim-one-DMA-channel.patch | 160 +++
 ...76-bcm2835-mmc-Only-claim-one-DMA-channel.patch | 170 +
 .../0177-config-rebuild-with-savedefconfig.patch   |  28 
 .../0178-config-Add-module-for-mcp3422-ADC.patch   |  30 
 ...-Pi3-DT-Add-pull-ups-on-the-UART-RX-lines.patch |  40 +
 .../patches-4.4/1000-mfd-rpisense-disable.patch|  10 ++
 .../1001-smsc95xx-disable-hw-csum.patch|  11 ++
 13 files changed, 763 insertions(+), 6 deletions(-)
 mode change 100755 => 100644 
target/linux/brcm2708/patches-4.4/0051-fdt-Add-support-for-the-CONFIG_CMDLINE_EXTEND-option.patch
 create mode 100644 
target/linux/brcm2708/patches-4.4/0171-BCM270X_DT-Add-pi3-disable-bt-overlay.patch
 create mode 100644 
target/linux/brcm2708/patches-4.4/0172-BCM270X_DT-Add-pi3-miniuart-bt-DT-overlay.patch
 create mode 100644 
target/linux/brcm2708/patches-4.4/0173-Pi3-DT-Add-dtparams-for-the-SD-interface.patch
 create mode 100644 
target/linux/brcm2708/patches-4.4/0174-vchiq_arm-Tweak-the-logging-output.patch
 create mode 100644 
target/linux/brcm2708/patches-4.4/0175-bcm2835-sdhost-Only-claim-one-DMA-channel.patch
 create mode 100644 
target/linux/brcm2708/patches-4.4/0176-bcm2835-mmc-Only-claim-one-DMA-channel.patch
 create mode 100644 
target/linux/brcm2708/patches-4.4/0177-config-rebuild-with-savedefconfig.patch
 create mode 100644 
target/linux/brcm2708/patches-4.4/0178-config-Add-module-for-mcp3422-ADC.patch
 create mode 100644 
target/linux/brcm2708/patches-4.4/0179-Pi3-DT-Add-pull-ups-on-the-UART-RX-lines.patch
 create mode 100644 
target/linux/brcm2708/patches-4.4/1000-mfd-rpisense-disable.patch
 create mode 100644 
target/linux/brcm2708/patches-4.4/1001-smsc95xx-disable-hw-csum.patch

diff --git a/target/linux/brcm2708/modules.mk b/target/linux/brcm2708/modules.mk
index 2802c1d..04e6aa9 100644
--- a/target/linux/brcm2708/modules.mk
+++ b/target/linux/brcm2708/modules.mk
@@ -274,7 +274,6 @@ define KernelPackage/spi-bcm2835
   SUBMENU:=$(SPI_MENU)
   TITLE:=BCM2835 SPI controller driver
   KCONFIG:=\
-CONFIG_BCM2708_SPIDEV=n \
 CONFIG_SPI=y \
 CONFIG_SPI_BCM2835 \
 CONFIG_SPI_MASTER=y
@@ -293,7 +292,6 @@ define KernelPackage/spi-bcm2835-aux
   SUBMENU:=$(SPI_MENU)
   TITLE:=BCM2835 Aux SPI controller driver
   KCONFIG:=\
-CONFIG_BCM2708_SPIDEV=n \
 CONFIG_SPI=y \
 CONFIG_SPI_BCM2835AUX \
 CONFIG_SPI_MASTER=y
@@ -331,8 +329,7 @@ define KernelPackage/i2c-bcm2708
   $(call i2c_defaults,$(I2C_BCM2708_MODULES),59)
   TITLE:=Broadcom BCM2708 I2C master controller driver
   KCONFIG+= \
-   CONFIG_I2C_BCM2708_BAUDRATE=10 \
-   CONFIG_MFD_RPISENSE_CORE=n
+   CONFIG_I2C_BCM2708_BAUDRATE=10
   DEPENDS:=@TARGET_brcm2708 +kmod-i2c-core
 endef
 
@@ -348,8 +345,6 @@ I2C_BCM2835_MODULES:=\
 define KernelPackage/i2c-bcm2835
   $(call i2c_defaults,$(I2C_BCM2835_MODULES),59)
   TITLE:=Broadcom BCM2835 I2C master controller driver
-  KCONFIG+= \
-   CONFIG_MFD_RPISENSE_CORE=n
   DEPENDS:=@TARGET_brcm2708 +kmod-i2c-core
 endef
 
diff --git 
a/target/linux/brcm2708/patches-4.4/0051-fdt-Add-support-for-the-CONFIG_CMDLINE_EXTEND-option.patch
 
b/target/linux/brcm2708/patches-4.4/0051-fdt-Add-support-for-the-CONFIG_CMDLINE_EXTEND-option.patch
old mode 100755
new mode 100644
diff --git 
a/target/linux/brcm2708/patches-4.4/0171-BCM270X_DT-Add-pi3-disable-bt-overlay.patch
 
b/target/linux/brcm2708/patches-4.4/0171-BCM270X_DT-Add-pi3-disable-bt-overlay.patch
new file mode 100644
index 000..d00439e
--- /dev/null
+++ 
b/target/linux/brcm2708/patches-4.4/0171-BCM270X_DT-Add-pi3-disable-bt-overlay.patch
@@ -0,0 +1,96 @@
+From 42a9bb566fe376a1add4b3780c1b830f64500faa Mon Sep 17 00:00:00 2001
+From: Phil Elwell 
+Date: Wed, 2 Mar 2016 10:59:05 +
+Subject: [PATCH 171/180] BCM270X_DT: Add pi3-disable-bt overlay
+
+Disable Bluetooth and restore UART0/ttyAMA0 over GPIOs 14 & 15. To disable
+the systemd service that initialises the modem so it doesn't use the UART:
+
+   sudo systemctl disable hciuart
+
+Signed-off-by: Phil Elwell 
+---
+ arch/arm/boot/dts/overlays/Makefile|  1 +
+ arch/arm/boot/dts/overlays/README  |  8 
+ .../boot/dts/overlays/pi3-disable-bt-overlay.dts   | 48 ++
+ 3 files changed, 57 insertions(+)
+ 

[OpenWrt-Devel] [PATCH 2/2] brcmfmac: Add Raspberry Pi 3 support

[Álvaro Fernández Rojas]

- Enable SDIO support on brcmfmac.
- Disable power managment for brcm2708 target.

Signed-off-by: Álvaro Fernández Rojas 
---
 package/kernel/mac80211/Makefile   |  1 +
 .../345-brcmfmac-Disable-power-management.patch| 27 ++
 .../brcm2708/bcm2710/profiles/RaspberryPi3.mk  |  1 +
 3 files changed, 29 insertions(+)
 create mode 100644 
package/kernel/mac80211/patches/345-brcmfmac-Disable-power-management.patch

diff --git a/package/kernel/mac80211/Makefile b/package/kernel/mac80211/Makefile
index e65cf2a..13a07ae 100644
--- a/package/kernel/mac80211/Makefile
+++ b/package/kernel/mac80211/Makefile
@@ -673,6 +673,7 @@ define KernelPackage/brcmfmac/config
 
config BRCMFMAC_SDIO
bool "Enable SDIO bus interface support"
+   default y if TARGET_brcm2708
default n
help
  Enable support for cards attached to an SDIO bus.
diff --git 
a/package/kernel/mac80211/patches/345-brcmfmac-Disable-power-management.patch 
b/package/kernel/mac80211/patches/345-brcmfmac-Disable-power-management.patch
new file mode 100644
index 000..091f175
--- /dev/null
+++ 
b/package/kernel/mac80211/patches/345-brcmfmac-Disable-power-management.patch
@@ -0,0 +1,27 @@
+From 66ae1b1750720a33e29792a177b1e696f4f005fb Mon Sep 17 00:00:00 2001
+From: Phil Elwell 
+Date: Wed, 9 Mar 2016 17:25:59 +
+Subject: [PATCH] brcmfmac: Disable power management
+
+Disable wireless power saving in the brcmfmac WLAN driver. This is a
+temporary measure until the connectivity loss resulting from power
+saving is resolved.
+
+Signed-off-by: Phil Elwell 
+---
+ drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
 b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+@@ -2623,6 +2623,10 @@ brcmf_cfg80211_set_power_mgmt(struct wip
+* preference in cfg struct to apply this to
+* FW later while initializing the dongle
+*/
++#ifdef defined(CONFIG_BCM2708) || defined(CONFIG_BCM2709)
++  pr_info("power management disabled\n");
++  enabled = false;
++#endif
+   cfg->pwr_save = enabled;
+   if (!check_vif_up(ifp->vif)) {
+ 
diff --git a/target/linux/brcm2708/bcm2710/profiles/RaspberryPi3.mk 
b/target/linux/brcm2708/bcm2710/profiles/RaspberryPi3.mk
index 251a8b5..a20e225 100644
--- a/target/linux/brcm2708/bcm2710/profiles/RaspberryPi3.mk
+++ b/target/linux/brcm2708/bcm2710/profiles/RaspberryPi3.mk
@@ -7,6 +7,7 @@
 
 define Profile/RaspberryPi_3
   NAME:=Raspberry Pi 3 Model B
+  PACKAGES:=kmod-brcmfmac wpad-mini
 endef
 define Profile/RaspberryPi_3/Description
   Raspberry Pi 3 Model B
-- 
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Linux IP Virtual Server for OpenWrt trunk or github?

[Mauro Mozzarelli]

Hi Felix,

Thank you for your feedback.

What you are saying does make sense to me, but it makes sense also to keep ipvs
together with iptables as they are both part of netfilter, which is my 
preference.

I would like to hear some other opinions.

Mauro

On Wed, March 9, 2016 12:00, Felix Fietkau wrote:

>> For this reason I believe it should be included in the core trunk OpenWrt.
> Not all packages on github are plain userland tools, there are kernel
> modules there and there are also packages without which the
> corresponding kernel functionality is useless (e.g. ipsec).
>
> The split of trunk vs packages is about who maintains the package, and
> in some cases also about the relative importance of the package as well.
> Packages in trunk are usually maintained by core developers, whereas
> packages on github are more of a community project.
>
> In OpenWrt, ipvs is a relatively exotic use case, so I believe that
> asking you to submit it to github instead of trunk is reasonable.
> The exception of course is the kernel module part, since it's just a
> small piece of metadata.
>
> - Felix
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/2] brcmfmac: Add Raspberry Pi 3 support

[Rafał Miłecki]

On 9 March 2016 at 20:32, Álvaro Fernández Rojas  wrote:
> diff --git 
> a/package/kernel/mac80211/patches/345-brcmfmac-Disable-power-management.patch 
> b/package/kernel/mac80211/patches/345-brcmfmac-Disable-power-management.patch
> new file mode 100644
> index 000..091f175
> --- /dev/null
> +++ 
> b/package/kernel/mac80211/patches/345-brcmfmac-Disable-power-management.patch
> @@ -0,0 +1,27 @@
> +From 66ae1b1750720a33e29792a177b1e696f4f005fb Mon Sep 17 00:00:00 2001
> +From: Phil Elwell 
> +Date: Wed, 9 Mar 2016 17:25:59 +
> +Subject: [PATCH] brcmfmac: Disable power management
> +
> +Disable wireless power saving in the brcmfmac WLAN driver. This is a
> +temporary measure until the connectivity loss resulting from power
> +saving is resolved.
> +
> +Signed-off-by: Phil Elwell 

I can't find this patch sent for upstream inclusion. Can you point me to it?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/2] brcmfmac: Add Raspberry Pi 3 support

[Álvaro Fernández Rojas]

It's a temporary hack until power management issues are solved:
https://github.com/raspberrypi/linux/commit/66ae1b1750720a33e29792a177b1e696f4f005fb
I don't think it was submitted upstream.

El 09/03/2016 a las 21:07, Rafał Miłecki escribió:

On 9 March 2016 at 20:32, Álvaro Fernández Rojas  wrote:

diff --git 
a/package/kernel/mac80211/patches/345-brcmfmac-Disable-power-management.patch 
b/package/kernel/mac80211/patches/345-brcmfmac-Disable-power-management.patch
new file mode 100644
index 000..091f175
--- /dev/null
+++ 
b/package/kernel/mac80211/patches/345-brcmfmac-Disable-power-management.patch
@@ -0,0 +1,27 @@
+From 66ae1b1750720a33e29792a177b1e696f4f005fb Mon Sep 17 00:00:00 2001
+From: Phil Elwell 
+Date: Wed, 9 Mar 2016 17:25:59 +
+Subject: [PATCH] brcmfmac: Disable power management
+
+Disable wireless power saving in the brcmfmac WLAN driver. This is a
+temporary measure until the connectivity loss resulting from power
+saving is resolved.
+
+Signed-off-by: Phil Elwell 

I can't find this patch sent for upstream inclusion. Can you point me to it?

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] oxnas: clean-up NAND driver to fix probing issue

[Daniel Golle]

A re-write of the driver based on xway_nand.c and constants as
well as the cmd_ctrl() function from the original oxnas_nand.c
resulted in a extremely similar looking file (see diffsize),
and fixes the issue of NAND not being detected on newer kernels.

Signed-off-by: Daniel Golle 
---
 target/linux/oxnas/files/drivers/mtd/nand/oxnas_nand.c | 18 +-
 1 file changed, 5 insertions(+), 13 deletions(-)

diff --git a/target/linux/oxnas/files/drivers/mtd/nand/oxnas_nand.c 
b/target/linux/oxnas/files/drivers/mtd/nand/oxnas_nand.c
index 055051d..c96d66b 100644
--- a/target/linux/oxnas/files/drivers/mtd/nand/oxnas_nand.c
+++ b/target/linux/oxnas/files/drivers/mtd/nand/oxnas_nand.c
@@ -2,15 +2,18 @@
  *  This program is free software; you can redistribute it and/or modify it
  *  under the terms of the GNU General Public License version 2 as published
  *  by the Free Software Foundation.
+ *
+ *  based on xway_nand.c
+ *  Copyright © 2012 John Crispin 
+ *  and oxnas_nand.c "NAND glue for Oxnas platforms"
+ *  written by Ma Haijun 
  */
 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 
 /* nand commands */
 #define NAND_CMD_ALE   BIT(18)
@@ -85,14 +88,3 @@ static int __init oxnas_register_nand(void)
 }
 
 subsys_initcall(oxnas_register_nand);
-
-static const struct of_device_id oxnas_nand_ids[] = {
-   { .compatible = "plxtech,nand-nas782x"},
-   { /* sentinel */ }
-};
-MODULE_DEVICE_TABLE(of, oxnas_nand_ids);
-
-MODULE_LICENSE("GPL");
-MODULE_AUTHOR("Ma Haijun");
-MODULE_DESCRIPTION("NAND glue for Oxnas platforms");
-MODULE_ALIAS("platform:oxnas_nand");
-- 
2.7.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/2] brcmfmac: Add Raspberry Pi 3 support

[Rafał Miłecki]

On 9 March 2016 at 21:24, Álvaro Fernández Rojas  wrote:
> It's a temporary hack until power management issues are solved:
> https://github.com/raspberrypi/linux/commit/66ae1b1750720a33e29792a177b1e696f4f005fb
> I don't think it was submitted upstream.

Please add it using other prefix than 3xx which we use for backported
patches. Preferably use some number to match other brcmfmac patches.

And don't top post! ;)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Request for Feedback - prplwrt Software Support Program - initial draft

[Felix Fietkau]

On 2016-03-09 17:46, Kathy Giori wrote:
> Saverio and all,
> 
> Let me offer a few thoughts, since I've been involved in prpl since
> the beginning, and you can either praise (preferred) or blame me for
> initiating the prplwrt PEG. :)
> 
> My initial goal was simple -- improved industry-community
> collaboration. But my secondary goal, assuming trust relationships
> would be established, had also been the idea of funding OpenWrt
> developers via prpl. Why not industry direct? Partly not to skew the
> project toward one specific vendor, but also because industry-direct
> funding to individual developers, or even professional services
> companies out of country of the funder, can be problematic
> (logistically/legally). I lived through some painful attempts.
I do agree that keeping things neutral and not skewing a project towards
one particular vendor is important. However, there's one critical aspect
that in my opinion is still very dysfunctional with prpl trying to act
as a middle man here: communication.

Some of us (especially John) have repeatedly attempted to get some
information on what the bigger OpenWrt users among the corporate prpl
members actually need. What are their issues with OpenWrt, what are
their requirements for useful features, etc. Maybe some information on
how they're actually using OpenWrt. In some ways that can be even more
important than having a neutral channel for funding.

To this day I don't know if there is some strategic communication going
on about this inside prpl that is just not communicated to us, or if the
prpl members simply don't bother to talk about this stuff and only drop
off some buzzword lists of high level things they wish for, without
actually bothering to go into specific details.
I've heard rumors leaning towards one or the other side, but I don't
know much about what's actually going on behind the scenes.

> It is wasteful to see industry re-invent the wheel in
> custom/proprietary or even open source ways, when there are FOSS
> solutions to a problem. Sometimes industry isn't aware (shame for not
> looking harder), but often they worry about lack of "control". If prpl
> could establish the means to collaborate effectively, then we can
> discourage industry from either being completely redundant, or from
> forking FOSS projects such as OpenWrt (and direct kernel hacks) into
> hard-to-maintain dead ends.
I think for prpl to be able to help here, a lot more transparency in
communication is needed. I did not find the kind of strategic discussion
required for that kind of collaboration in the prpl sync calls I
attended either. From my superficial review of the meeting notes, it
seems that this is just not the place for it.

> And finally, I'm hoping that prpl will help raise OpenWrt developer
> voices, to bring your valuable insight to be heard by industry.
> Especially important is the need for upstream Linux kernel development
> (all BSP and kernel driver support). Also important is "giving back",
> making submissions directly to OpenWrt trunk (or a staging branch if
> not ready for trunk). In other words, in addition to upstreaming,
> silicon vendor SDK support on top of OpenWrt should be
> pushed/integrated with OpenWrt as much as possible.
I think plenty of OpenWrt developers already frequently raise their
voices. What's needed is for the industry to not just listen, but also
to communicate back. For that to be effective, we need to be sure that
any useful feedback isn't being drowned out by a miscalibrated filter ;)

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] mm-macros: update to 0.9.10

[Hannu Nyman]

Bump mm-macros to 0.9.10

Signed-off-by: Hannu Nyman 
---
Release notes:
https://github.com/GNOME/mm-common/blob/master/NEWS

 tools/mm-macros/Makefile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/mm-macros/Makefile b/tools/mm-macros/Makefile
index cd675dc..3c457ef 100644
--- a/tools/mm-macros/Makefile
+++ b/tools/mm-macros/Makefile
@@ -1,5 +1,5 @@
 #
-# Copyright (C) 2010-2015 OpenWrt.org
+# Copyright (C) 2010-2016 OpenWrt.org
 #
 # This is free software, licensed under the GNU General Public License v2.
 # See /LICENSE for more information.
@@ -8,11 +8,11 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=mm-macros
-PKG_VERSION:=0.9.9
+PKG_VERSION:=0.9.10
 
 PKG_SOURCE_URL:=@GNOME/mm-common/0.9
 PKG_SOURCE:=mm-common-$(PKG_VERSION).tar.xz
-PKG_MD5SUM:=c9d8c016a99b639d66115cbe1d892402
+PKG_MD5SUM:=49dc47af8c89ce5b3c768306b9a0f922
 
 HOST_BUILD_DIR:=$(BUILD_DIR_HOST)/mm-common-$(PKG_VERSION)
 
-- 
2.5.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] pkg-config: Update to 0.29.1

[Hannu Nyman]

* Bump pkg-config version to 0.29.1
* Use https for the source download (http gets directed there)

Signed-off-by: Hannu Nyman 
---

Release notes:
https://lists.freedesktop.org/archives/pkg-config/2016-March/001043.html

 - Fixed a regression from 0.29 with unquoting values queried with
   --variable. In some cases, this would cause shell special characters
   to be escaped in ways they weren't before. Instead, the unquoting only
   occurs if the value appears to be quoted. (#93284)
 - Add support for building pkg-config with Microsoft Visual Studio.
   Thanks to Chun-wei Fan for the fix. (#92489)
 - Allow overriding pkg-config variables with environment variables. By
   setting an environment variable of the form
   PKG_CONFIG_$PACKAGE_$VARIABLE, a pkg-config variable can be set
   globally without always having to pass --define-variable. Thanks to
   Alex Larsson for the fix. (#90917)
 - Honor -Wl,-framework in addition to -framework so that multiple
   frameworks are handled on OSX. (#1278)
 - Fix the OSX build using --with-internal-glib. Thanks to Rudá Moura for
   the initial fix and Adam Mercer for testing the final patch. (#92902)


 tools/pkg-config/Makefile | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/pkg-config/Makefile b/tools/pkg-config/Makefile
index 40e6e08..c649b24 100644
--- a/tools/pkg-config/Makefile
+++ b/tools/pkg-config/Makefile
@@ -1,5 +1,5 @@
 # 
-# Copyright (C) 2006-2015 OpenWrt.org
+# Copyright (C) 2006-2016 OpenWrt.org
 #
 # This is free software, licensed under the GNU General Public License v2.
 # See /LICENSE for more information.
@@ -7,11 +7,11 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=pkg-config
-PKG_VERSION:=0.29
+PKG_VERSION:=0.29.1
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
-PKG_SOURCE_URL:=http://pkgconfig.freedesktop.org/releases/
-PKG_MD5SUM:=77f27dce7ef88d0634d0d6f90e03a77f
+PKG_SOURCE_URL:=https://pkgconfig.freedesktop.org/releases/
+PKG_MD5SUM:=f739a28cae4e0ca291f82d1d41ef107d
 
 HOST_BUILD_PARALLEL:=1
 
-- 
2.5.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 2/2] package/devel/gdb: Update to 7.11

[Hannu Nyman]

Update gdb to version 7.11

Signed-off-by: Hannu Nyman 
---

Release notes:
https://lists.gnu.org/archive/html/info-gnu/2016-02/msg00010.html

GDB 7.11 brings new features and improvements, including:

* Per-inferior thread numbers (thread numbers are now per inferior instead
  of being global).

* GDB now allows users to specify breakpoint locations using a more
  explicit syntax (named "explicit location").  This feature is also
  available in GDB/MI.

* New convenience variables ($_gthread, $_inferior)

* When hitting a breakpoint or receiving a signal while debugging a
  multi-threaded program, the debugger now shows which thread triggered
  the event.

* Record btrace now supports non-stop mode.

* Various improvements on AArch64 GNU/Linux
  ** Multi-architecture debugging support
  ** displaced stepping
  ** tracepoint support added in GDBserver

* kernel-based threads support on FreeBSD.

* Support for reading/writing memory and extracting values on architectures
  whose memory is addressable in units of any integral multiple of 8 bits.

* In Ada, the overloads selection menu provides the parameter types and
  return types for the matching overloaded subprograms.

* Various remote protocol improvements, including several new packets
  which can be used to support features such as follow-exec-mode, exec
  catchpoints, syscall catchpoints, etc.

* Some minor improvements in the Python API for extending GDB.

* Support for various ROM monitors has been removed:
  target dbug   dBUG ROM monitor for Motorola ColdFire
  target picobugMotorola picobug monitor
  target dink32 DINK32 ROM monitor for PowerPC
  target m32r   Renesas M32R/D ROM monitor
  target mon2000mon2000 ROM monitor
  target ppcbug PPCBUG ROM monitor for PowerPC



 package/devel/gdb/Makefile   | 4 ++--
 package/devel/gdb/patches/100-musl_fix.patch | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/package/devel/gdb/Makefile b/package/devel/gdb/Makefile
index 91f6bfe..f6d5fec 100644
--- a/package/devel/gdb/Makefile
+++ b/package/devel/gdb/Makefile
@@ -8,12 +8,12 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=gdb
-PKG_VERSION:=7.10.1
+PKG_VERSION:=7.11
 PKG_RELEASE:=1
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
 PKG_SOURCE_URL:=@GNU/gdb
-PKG_MD5SUM:=39e654460c9cdd80200a29ac020cfe11
+PKG_MD5SUM:=b5c784685e1cde65ba135feea86b6d75
 
 PKG_BUILD_PARALLEL:=1
 PKG_INSTALL:=1
diff --git a/package/devel/gdb/patches/100-musl_fix.patch 
b/package/devel/gdb/patches/100-musl_fix.patch
index afe9dc7..09146c5 100644
--- a/package/devel/gdb/patches/100-musl_fix.patch
+++ b/package/devel/gdb/patches/100-musl_fix.patch
@@ -8,7 +8,7 @@
  #include "defs.h"
  #include "inferior.h"
  #include "infrun.h"
-@@ -73,6 +74,10 @@
+@@ -71,6 +72,10 @@
  #define SPUFS_MAGIC 0x23c9b64e
  #endif
  
-- 
2.5.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 1/2] toolchain/gdb: Update to 7.11

[Hannu Nyman]

Update gdb to version 7.11

Signed-off-by: Hannu Nyman 
---

Release notes:
https://lists.gnu.org/archive/html/info-gnu/2016-02/msg00010.html

GDB 7.11 brings new features and improvements, including:

* Per-inferior thread numbers (thread numbers are now per inferior instead
  of being global).

* GDB now allows users to specify breakpoint locations using a more
  explicit syntax (named "explicit location").  This feature is also
  available in GDB/MI.

* New convenience variables ($_gthread, $_inferior)

* When hitting a breakpoint or receiving a signal while debugging a
  multi-threaded program, the debugger now shows which thread triggered
  the event.

* Record btrace now supports non-stop mode.

* Various improvements on AArch64 GNU/Linux
  ** Multi-architecture debugging support
  ** displaced stepping
  ** tracepoint support added in GDBserver

* kernel-based threads support on FreeBSD.

* Support for reading/writing memory and extracting values on architectures
  whose memory is addressable in units of any integral multiple of 8 bits.

* In Ada, the overloads selection menu provides the parameter types and
  return types for the matching overloaded subprograms.

* Various remote protocol improvements, including several new packets
  which can be used to support features such as follow-exec-mode, exec
  catchpoints, syscall catchpoints, etc.

* Some minor improvements in the Python API for extending GDB.

* Support for various ROM monitors has been removed:
  target dbug   dBUG ROM monitor for Motorola ColdFire
  target picobugMotorola picobug monitor
  target dink32 DINK32 ROM monitor for PowerPC
  target m32r   Renesas M32R/D ROM monitor
  target mon2000mon2000 ROM monitor
  target ppcbug PPCBUG ROM monitor for PowerPC


 toolchain/gdb/Makefile |  4 +--
 .../gdb/patches/7.10.1/100-no_extern_inline.patch  | 32 --
 .../gdb/patches/7.10.1/110-no_testsuite.patch  | 21 --
 .../7.10.1/120-fix-compile-flag-mismatch.patch | 11 
 .../gdb/patches/7.11/100-no_extern_inline.patch| 32 ++
 toolchain/gdb/patches/7.11/110-no_testsuite.patch  | 21 ++
 .../7.11/120-fix-compile-flag-mismatch.patch   | 11 
 7 files changed, 66 insertions(+), 66 deletions(-)
 delete mode 100644 toolchain/gdb/patches/7.10.1/100-no_extern_inline.patch
 delete mode 100644 toolchain/gdb/patches/7.10.1/110-no_testsuite.patch
 delete mode 100644 
toolchain/gdb/patches/7.10.1/120-fix-compile-flag-mismatch.patch
 create mode 100644 toolchain/gdb/patches/7.11/100-no_extern_inline.patch
 create mode 100644 toolchain/gdb/patches/7.11/110-no_testsuite.patch
 create mode 100644 
toolchain/gdb/patches/7.11/120-fix-compile-flag-mismatch.patch

diff --git a/toolchain/gdb/Makefile b/toolchain/gdb/Makefile
index 19f4931..0e1b0a2 100644
--- a/toolchain/gdb/Makefile
+++ b/toolchain/gdb/Makefile
@@ -16,11 +16,11 @@ 
PKG_SOURCE_URL:=https://github.com/foss-for-synopsys-dwc-arc-processors/binutils
 PKG_MD5SUM:=d318829bfd2ed62714817f0d25706825
 GDB_DIR:=binutils-$(PKG_NAME)-$(PKG_VERSION)
 else
-PKG_VERSION:=7.10.1
+PKG_VERSION:=7.11
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
 PKG_SOURCE_URL:=@GNU/gdb
-PKG_MD5SUM:=39e654460c9cdd80200a29ac020cfe11
+PKG_MD5SUM:=b5c784685e1cde65ba135feea86b6d75
 GDB_DIR:=$(PKG_NAME)-$(PKG_VERSION)
 endif
 
diff --git a/toolchain/gdb/patches/7.10.1/100-no_extern_inline.patch 
b/toolchain/gdb/patches/7.10.1/100-no_extern_inline.patch
deleted file mode 100644
index 8c18c6e..000
--- a/toolchain/gdb/patches/7.10.1/100-no_extern_inline.patch
+++ /dev/null
@@ -1,32 +0,0 @@
 a/sim/common/sim-arange.c
-+++ b/sim/common/sim-arange.c
-@@ -280,11 +280,7 @@ sim_addr_range_delete (ADDR_RANGE *ar, a
-   build_search_tree (ar);
- }
- 
--#endif /* DEFINE_NON_INLINE_P */
--
--#if DEFINE_INLINE_P
--
--SIM_ARANGE_INLINE int
-+int
- sim_addr_range_hit_p (ADDR_RANGE *ar, address_word addr)
- {
-   ADDR_RANGE_TREE *t = ar->range_tree;
-@@ -301,4 +297,4 @@ sim_addr_range_hit_p (ADDR_RANGE *ar, ad
-   return 0;
- }
- 
--#endif /* DEFINE_INLINE_P */
-+#endif /* DEFINE_NON_INLINE_P */
 a/sim/common/sim-arange.h
-+++ b/sim/common/sim-arange.h
-@@ -73,7 +73,7 @@ extern void sim_addr_range_delete (ADDR_
- 
- /* Return non-zero if ADDR is in range AR, traversing the entire tree.
-If no range is specified, that is defined to mean "everything".  */
--SIM_ARANGE_INLINE int
-+extern int
- sim_addr_range_hit_p (ADDR_RANGE * /*ar*/, address_word /*addr*/);
- #define ADDR_RANGE_HIT_P(ar, addr) \
-   ((ar)->range_tree == NULL || sim_addr_range_hit_p ((ar), (addr)))
diff --git a/toolchain/gdb/patches/7.10.1/110-no_testsuite.patch 
b/toolchain/gdb/patches/7.10.1/110-no_testsuite.patch
deleted file mode 100644
index 1b284ea..000
--- a/toolchain/gdb/patches/7.10.1/110-no_testsuite.patch
+++ /dev/null
@@ -1,21 +0,0 @@
 a/gdb/configure
-+++ b/gdb/configure
-@@ -870,8 +870,

[OpenWrt-Devel] [PATCH 1/2] toolchain/gdb: Update to 7.11

[Hannu Nyman]

Update gdb to version 7.11

Signed-off-by: Hannu Nyman 
---

Release notes:
https://lists.gnu.org/archive/html/info-gnu/2016-02/msg00010.html

GDB 7.11 brings new features and improvements, including:

* Per-inferior thread numbers (thread numbers are now per inferior instead
  of being global).

* GDB now allows users to specify breakpoint locations using a more
  explicit syntax (named "explicit location").  This feature is also
  available in GDB/MI.

* New convenience variables ($_gthread, $_inferior)

* When hitting a breakpoint or receiving a signal while debugging a
  multi-threaded program, the debugger now shows which thread triggered
  the event.

* Record btrace now supports non-stop mode.

* Various improvements on AArch64 GNU/Linux
  ** Multi-architecture debugging support
  ** displaced stepping
  ** tracepoint support added in GDBserver

* kernel-based threads support on FreeBSD.

* Support for reading/writing memory and extracting values on architectures
  whose memory is addressable in units of any integral multiple of 8 bits.

* In Ada, the overloads selection menu provides the parameter types and
  return types for the matching overloaded subprograms.

* Various remote protocol improvements, including several new packets
  which can be used to support features such as follow-exec-mode, exec
  catchpoints, syscall catchpoints, etc.

* Some minor improvements in the Python API for extending GDB.

* Support for various ROM monitors has been removed:
  target dbug   dBUG ROM monitor for Motorola ColdFire
  target picobugMotorola picobug monitor
  target dink32 DINK32 ROM monitor for PowerPC
  target m32r   Renesas M32R/D ROM monitor
  target mon2000mon2000 ROM monitor
  target ppcbug PPCBUG ROM monitor for PowerPC


 toolchain/gdb/Makefile |  4 +--
 .../gdb/patches/7.10.1/100-no_extern_inline.patch  | 32 --
 .../gdb/patches/7.10.1/110-no_testsuite.patch  | 21 --
 .../7.10.1/120-fix-compile-flag-mismatch.patch | 11 
 .../gdb/patches/7.11/100-no_extern_inline.patch| 32 ++
 toolchain/gdb/patches/7.11/110-no_testsuite.patch  | 21 ++
 .../7.11/120-fix-compile-flag-mismatch.patch   | 11 
 7 files changed, 66 insertions(+), 66 deletions(-)
 delete mode 100644 toolchain/gdb/patches/7.10.1/100-no_extern_inline.patch
 delete mode 100644 toolchain/gdb/patches/7.10.1/110-no_testsuite.patch
 delete mode 100644 
toolchain/gdb/patches/7.10.1/120-fix-compile-flag-mismatch.patch
 create mode 100644 toolchain/gdb/patches/7.11/100-no_extern_inline.patch
 create mode 100644 toolchain/gdb/patches/7.11/110-no_testsuite.patch
 create mode 100644 
toolchain/gdb/patches/7.11/120-fix-compile-flag-mismatch.patch

diff --git a/toolchain/gdb/Makefile b/toolchain/gdb/Makefile
index 19f4931..0e1b0a2 100644
--- a/toolchain/gdb/Makefile
+++ b/toolchain/gdb/Makefile
@@ -16,11 +16,11 @@ 
PKG_SOURCE_URL:=https://github.com/foss-for-synopsys-dwc-arc-processors/binutils
 PKG_MD5SUM:=d318829bfd2ed62714817f0d25706825
 GDB_DIR:=binutils-$(PKG_NAME)-$(PKG_VERSION)
 else
-PKG_VERSION:=7.10.1
+PKG_VERSION:=7.11
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
 PKG_SOURCE_URL:=@GNU/gdb
-PKG_MD5SUM:=39e654460c9cdd80200a29ac020cfe11
+PKG_MD5SUM:=b5c784685e1cde65ba135feea86b6d75
 GDB_DIR:=$(PKG_NAME)-$(PKG_VERSION)
 endif
 
diff --git a/toolchain/gdb/patches/7.10.1/100-no_extern_inline.patch 
b/toolchain/gdb/patches/7.10.1/100-no_extern_inline.patch
deleted file mode 100644
index 8c18c6e..000
--- a/toolchain/gdb/patches/7.10.1/100-no_extern_inline.patch
+++ /dev/null
@@ -1,32 +0,0 @@
 a/sim/common/sim-arange.c
-+++ b/sim/common/sim-arange.c
-@@ -280,11 +280,7 @@ sim_addr_range_delete (ADDR_RANGE *ar, a
-   build_search_tree (ar);
- }
- 
--#endif /* DEFINE_NON_INLINE_P */
--
--#if DEFINE_INLINE_P
--
--SIM_ARANGE_INLINE int
-+int
- sim_addr_range_hit_p (ADDR_RANGE *ar, address_word addr)
- {
-   ADDR_RANGE_TREE *t = ar->range_tree;
-@@ -301,4 +297,4 @@ sim_addr_range_hit_p (ADDR_RANGE *ar, ad
-   return 0;
- }
- 
--#endif /* DEFINE_INLINE_P */
-+#endif /* DEFINE_NON_INLINE_P */
 a/sim/common/sim-arange.h
-+++ b/sim/common/sim-arange.h
-@@ -73,7 +73,7 @@ extern void sim_addr_range_delete (ADDR_
- 
- /* Return non-zero if ADDR is in range AR, traversing the entire tree.
-If no range is specified, that is defined to mean "everything".  */
--SIM_ARANGE_INLINE int
-+extern int
- sim_addr_range_hit_p (ADDR_RANGE * /*ar*/, address_word /*addr*/);
- #define ADDR_RANGE_HIT_P(ar, addr) \
-   ((ar)->range_tree == NULL || sim_addr_range_hit_p ((ar), (addr)))
diff --git a/toolchain/gdb/patches/7.10.1/110-no_testsuite.patch 
b/toolchain/gdb/patches/7.10.1/110-no_testsuite.patch
deleted file mode 100644
index 1b284ea..000
--- a/toolchain/gdb/patches/7.10.1/110-no_testsuite.patch
+++ /dev/null
@@ -1,21 +0,0 @@
 a/gdb/configure
-+++ b/gdb/configure
-@@ -870,8 +870,

Re: [OpenWrt-Devel] [RFC 2/3] kernel: owl-loader for delayed Atheros ath9k fixup

[Martin Blumenstingl]

On Wed, Mar 9, 2016 at 6:30 PM, Christian Lamparter
 wrote:
> lantiq on the other hand has copied the func from ar71xx and adapted
> and renamed it, but kept the signature:
> ltq_pci_ath_fixup(unsigned slot, u16 *cal_data)
> it's in arch/mips/lantiq/xway/pci-ath-fixup.c.
Maybe we could also move pci-ath-fixup.c to a separate package (or
even the same as owl-loader)?

Seems like there are only two differences between the lantiq and the
ar71xx code:
1. pci_write_config_dword(dev, PCI_BASE_ADDRESS_0, base); vs per-SoC
value in ar71xx
2. swab32(val) when writing the caldata


Martin
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Request for Feedback - prplwrt Software Support Program - initial draft

[xxiao8]

I would expect prpl had lots of discussion with Openwrt core developers 
already before this. It appears that did not happen.


Intel funded the core developers for Yocto(x86), Linaro gets money from 
ARM(arm), now it seems prpl is trying to better some ecosystem for mips 
via Openwrt.


IMHO, prpl either does something major(full and open community 
involvement, much more financial sponsorship,etc), or sponsor a few 
sub-projects initially to earn a name for itself before anything major.


Openwrt in the IoT days in my opinion should be put under Linux Foundation.

xxiao

On 03/09/2016 03:11 PM, openwrt-devel-requ...@lists.openwrt.org wrote:

Re: [OpenWrt-Devel] Request for Feedback - prplwrt Software
Support Program - initial draft
Message-ID:<56e09167.3000...@openwrt.org>
Content-Type: text/plain; charset=utf-8

On 2016-03-09 17:46, Kathy Giori wrote:

>Saverio and all,
>
>Let me offer a few thoughts, since I've been involved in prpl since
>the beginning, and you can either praise (preferred) or blame me for
>initiating the prplwrt PEG. :)
>
>My initial goal was simple -- improved industry-community
>collaboration. But my secondary goal, assuming trust relationships
>would be established, had also been the idea of funding OpenWrt
>developers via prpl. Why not industry direct? Partly not to skew the
>project toward one specific vendor, but also because industry-direct
>funding to individual developers, or even professional services
>companies out of country of the funder, can be problematic
>(logistically/legally). I lived through some painful attempts.

I do agree that keeping things neutral and not skewing a project towards
one particular vendor is important. However, there's one critical aspect
that in my opinion is still very dysfunctional with prpl trying to act
as a middle man here: communication.

Some of us (especially John) have repeatedly attempted to get some
information on what the bigger OpenWrt users among the corporate prpl
members actually need. What are their issues with OpenWrt, what are
their requirements for useful features, etc. Maybe some information on
how they're actually using OpenWrt. In some ways that can be even more
important than having a neutral channel for funding.

To this day I don't know if there is some strategic communication going
on about this inside prpl that is just not communicated to us, or if the
prpl members simply don't bother to talk about this stuff and only drop
off some buzzword lists of high level things they wish for, without
actually bothering to go into specific details.
I've heard rumors leaning towards one or the other side, but I don't
know much about what's actually going on behind the scenes.


>It is wasteful to see industry re-invent the wheel in
>custom/proprietary or even open source ways, when there are FOSS
>solutions to a problem. Sometimes industry isn't aware (shame for not
>looking harder), but often they worry about lack of "control". If prpl
>could establish the means to collaborate effectively, then we can
>discourage industry from either being completely redundant, or from
>forking FOSS projects such as OpenWrt (and direct kernel hacks) into
>hard-to-maintain dead ends.

I think for prpl to be able to help here, a lot more transparency in
communication is needed. I did not find the kind of strategic discussion
required for that kind of collaboration in the prpl sync calls I
attended either. From my superficial review of the meeting notes, it
seems that this is just not the place for it.


>And finally, I'm hoping that prpl will help raise OpenWrt developer
>voices, to bring your valuable insight to be heard by industry.
>Especially important is the need for upstream Linux kernel development
>(all BSP and kernel driver support). Also important is "giving back",
>making submissions directly to OpenWrt trunk (or a staging branch if
>not ready for trunk). In other words, in addition to upstreaming,
>silicon vendor SDK support on top of OpenWrt should be
>pushed/integrated with OpenWrt as much as possible.

I think plenty of OpenWrt developers already frequently raise their
voices. What's needed is for the industry to not just listen, but also
to communicate back. For that to be effective, we need to be sure that
any useful feedback isn't being drowned out by a miscalibrated filter ;)

- Felix

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ar71xx: Add support for the OMYlink OMY-X1

[L. D. Pinney]

https://wiki.openwrt.org/toh/omylink/omy-x1

http://www.omylink.com/

Signed-off-by: L. D. Pinney 
---

 target/linux/ar71xx/base-files/etc/board.d/01_leds|   5 +++
 target/linux/ar71xx/base-files/etc/board.d/02_network |   1 +
 target/linux/ar71xx/base-files/etc/diag.sh|   3 ++
 target/linux/ar71xx/base-files/lib/ar71xx.sh  |   3 ++
 target/linux/ar71xx/base-files/lib/upgrade/platform.sh|   1 +
 target/linux/ar71xx/config-4.1|   1 +
 target/linux/ar71xx/config-4.4|   1 +
 target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt |   9 ++
 target/linux/ar71xx/files/arch/mips/ath79/Makefile|   1 +
 target/linux/ar71xx/files/arch/mips/ath79/mach-omy-x1.c   | 110 
++
 target/linux/ar71xx/files/arch/mips/ath79/machtypes.h |   1 +
 target/linux/ar71xx/generic/profiles/omy.mk   |  16 ++
 target/linux/ar71xx/image/Makefile|   8 +
 tools/firmware-utils/src/mktplinkfw.c |   6 
 14 files changed, 166 insertions(+)

diff --git a/target/linux/ar71xx/base-files/etc/board.d/01_leds 
b/target/linux/ar71xx/base-files/etc/board.d/01_leds
index 6cec5df..355c391 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/01_leds
+++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds
@@ -394,6 +394,11 @@ om5p-an)
ucidef_set_led_netdev "port2" "port2" "om5p:blue:lan" "eth1"
;;
 
+omy-x1)
+   ucidef_set_led_default "power" "POWER" "omy:green:power" "1"
+   ucidef_set_led_default "wan" "WAN" "omy:green:wan" "eth0"
+   ;;
+
 qihoo-c301)
ucidef_set_led_wlan "wlan2g" "WLAN2G" "qihoo:red:status" "phy1tpt"
;;
diff --git a/target/linux/ar71xx/base-files/etc/board.d/02_network 
b/target/linux/ar71xx/base-files/etc/board.d/02_network
index 799d98e..56ea451 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/02_network
+++ b/target/linux/ar71xx/base-files/etc/board.d/02_network
@@ -384,6 +384,7 @@ gl-ar150 |\
 gl-domino |\
 gl-inet |\
 jwap003 |\
+omy-x1 |\
 pb42 |\
 pb44 |\
 routerstation|\
diff --git a/target/linux/ar71xx/base-files/etc/diag.sh 
b/target/linux/ar71xx/base-files/etc/diag.sh
index db69757..9167808 100644
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -214,6 +214,9 @@ get_status_led() {
om5p-an)
status_led="om5p:blue:power"
;;
+   omy-x1)
+   status_led="omy:green:power"
+   ;;
onion-omega)
status_led="onion:amber:system"
;;
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh 
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index 804f622..8e9d1ea 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -120,6 +120,9 @@ tplink_board_detect() {
"12"*)
model="MERCURY MAC1200R"
;;
+   "066602"*)
+   model="OMYlink OMY-X1"
+   ;;
"3C0001"*)
model="OOLITE"
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh 
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index 8a70502..c8687c9 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -333,6 +333,7 @@ platform_check_image() {
gl-inet | \
mc-mac1200r | \
minibox-v1 |\
+   omy-x1 |\
onion-omega | \
oolite | \
smart-300 | \
diff --git a/target/linux/ar71xx/config-4.1 b/target/linux/ar71xx/config-4.1
index 0ccb278..a682c11 100644
--- a/target/linux/ar71xx/config-4.1
+++ b/target/linux/ar71xx/config-4.1
@@ -108,6 +108,7 @@ CONFIG_ATH79_MACH_NBG460N=y
 CONFIG_ATH79_MACH_NBG6716=y
 CONFIG_ATH79_MACH_OM2P=y
 CONFIG_ATH79_MACH_OM5P=y
+CONFIG_ATH79_MACH_OMY_X1=y
 CONFIG_ATH79_MACH_ONION_OMEGA=y
 CONFIG_ATH79_MACH_PB42=y
 CONFIG_ATH79_MACH_PB44=y
diff --git a/target/linux/ar71xx/config-4.4 b/target/linux/ar71xx/config-4.4
index bef1863..73d552d 100644
--- a/target/linux/ar71xx/config-4.4
+++ b/target/linux/ar71xx/config-4.4
@@ -111,6 +111,7 @@ CONFIG_ATH79_MACH_NBG460N=y
 CONFIG_ATH79_MACH_NBG6716=y
 CONFIG_ATH79_MACH_OM2P=y
 CONFIG_ATH79_MACH_OM5P=y
+CONFIG_ATH79_MACH_OMY_X1=y
 CONFIG_ATH79_MACH_ONION_OMEGA=y
 CONFIG_ATH79_MACH_PB42=y
 CONFIG_ATH79_MACH_PB44=y
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt 
b/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
index 3d6dc4d..12f8c55 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
+++ b/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
@@ -843,6 +843,15 @@ config ATH79_MACH_OM5P
select ATH79_DEV_M25P80
select ATH79_DEV_WMAC
 
+config ATH79_MACH_OMY_X1
+   bool "OMYlink OMY X1 support"
+  

[OpenWrt-Devel] [PATCH 1/3] ramips: Add support for GL-MT300A

[alzhao]

This patches adds support for GL-MT300A.
GL-MT300A is powered by MT7620A. It has 16MB flash, 128MB RAM,
Two LANs, USB, UART and MMC daughter board.
---
 target/linux/ramips/base-files/etc/board.d/01_leds |   3 +
 .../linux/ramips/base-files/etc/board.d/02_network |   1 +
 target/linux/ramips/base-files/lib/ramips.sh   |   3 +
 .../ramips/base-files/lib/upgrade/platform.sh  |   1 +
 target/linux/ramips/dts/GL-MT300A.dts  | 164 +
 target/linux/ramips/image/Makefile |   2 +
 target/linux/ramips/mt7620/profiles/gli.mk |  16 ++
 7 files changed, 190 insertions(+)
 create mode 100644 target/linux/ramips/dts/GL-MT300A.dts
 create mode 100644 target/linux/ramips/mt7620/profiles/gli.mk

diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds 
b/target/linux/ramips/base-files/etc/board.d/01_leds
index 8fd50fe..536a363 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -137,6 +137,9 @@ fonera20n)
set_usb_led "$board:orange:usb"
set_wifi_led "$board:orange:wifi"
;;
+gl-mt300a)
+   set_wifi_led "$board:wlan"
+   ;;
 hc5661)
ucidef_set_led_default "system" "system" "$board:blue:system" "1"
ucidef_set_led_netdev "internet" "internet" "$board:blue:internet" 
"eth0.2"
diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
b/target/linux/ramips/base-files/etc/board.d/02_network
index ac5a312..74599ad 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -113,6 +113,7 @@ ramips_setup_interfaces()
dir-860l-b1|\
f5d8235-v1|\
f5d8235-v2|\
+   gl-mt300a|\
hg255d|\
mzk-wdpr|\
jhr-n805r|\
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index 3fdb562..ba27c14 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -175,6 +175,9 @@ ramips_board_detect() {
*"FreeStation5")
name="freestation5"
;;
+   *"GL-MT300A")
+   name="gl-mt300a"
+   ;;
*"HC5661")
name="hc5661"
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index e01f9ce..876416e 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -56,6 +56,7 @@ platform_check_image() {
firewrt|\
fonera20n|\
freestation5|\
+   gl-mt300a|\
hc5*61|\
hg255d|\
hlk-rm04|\
diff --git a/target/linux/ramips/dts/GL-MT300A.dts 
b/target/linux/ramips/dts/GL-MT300A.dts
new file mode 100644
index 000..c1eb0a9
--- /dev/null
+++ b/target/linux/ramips/dts/GL-MT300A.dts
@@ -0,0 +1,164 @@
+/dts-v1/;
+
+/include/ "mt7620a.dtsi"
+
+/ {
+   compatible = "GL-MT300A", "ralink,mt7620a-soc";
+   model = "GL-MT300A";
+
+   chosen {
+   bootargs = "console=ttyS0,115200";
+   };
+
+   palmbus@1000 {
+   gpio0: gpio@600 {
+   status = "okay";
+   };
+
+   gpio1: gpio@638 {
+   status = "okay";
+   };
+
+   gpio2: gpio@660 {
+   status = "okay";
+   };
+   
+   gpio3: gpio@688 {
+ status = "okay";
+};
+
+   spi@b00 {
+   status = "okay";
+
+   m25p80@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "w25q128";
+   reg = <0 0>;
+   linux,modalias = "m25p80", "w25q128";
+   spi-max-frequency = <1000>;
+
+   partition@0 {
+   label = "u-boot";
+   reg = <0x0 0x3>;
+   };
+
+   partition@3 {
+   label = "u-boot-env";
+   reg = <0x3 0x1>;
+   read-only;
+   };
+
+   factory: partition@4 {
+   label = "factory";
+   reg = <0x4 0x1>;
+   read-only;
+   };
+
+   partition@5 {
+   label = "firmware";
+   reg = <0x5 0xf8>;
+ 

[OpenWrt-Devel] [PATCH 2/3] ramips: Add support for GL-MT300N

[alzhao]

This patch adds support for GL-MT300N.
GL-MT300N is powered by MT7620N with 16MB flash, 64MB RAM,
2 LANs, USB, UART, GPIO and PoE support.
---
 target/linux/ramips/base-files/etc/board.d/01_leds |   3 +-
 .../linux/ramips/base-files/etc/board.d/02_network |   1 +
 target/linux/ramips/base-files/lib/ramips.sh   |   3 +
 .../ramips/base-files/lib/upgrade/platform.sh  |   1 +
 target/linux/ramips/dts/GL-MT300N.dts  | 153 +
 target/linux/ramips/image/Makefile |   2 +
 target/linux/ramips/mt7620/profiles/gli.mk |  11 ++
 7 files changed, 173 insertions(+), 1 deletion(-)
 create mode 100644 target/linux/ramips/dts/GL-MT300N.dts

diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds 
b/target/linux/ramips/base-files/etc/board.d/01_leds
index 536a363..132c7ce 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -137,7 +137,8 @@ fonera20n)
set_usb_led "$board:orange:usb"
set_wifi_led "$board:orange:wifi"
;;
-gl-mt300a)
+gl-mt300a|\
+gl-mt300n)
set_wifi_led "$board:wlan"
;;
 hc5661)
diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
b/target/linux/ramips/base-files/etc/board.d/02_network
index 74599ad..40c24a9 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -114,6 +114,7 @@ ramips_setup_interfaces()
f5d8235-v1|\
f5d8235-v2|\
gl-mt300a|\
+   gl-mt300n|\
hg255d|\
mzk-wdpr|\
jhr-n805r|\
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index ba27c14..fcc4b9f 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -178,6 +178,9 @@ ramips_board_detect() {
*"GL-MT300A")
name="gl-mt300a"
;;
+   *"GL-MT300N")
+   name="gl-mt300n"
+   ;;
*"HC5661")
name="hc5661"
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index 876416e..8727831 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -57,6 +57,7 @@ platform_check_image() {
fonera20n|\
freestation5|\
gl-mt300a|\
+   gl-mt300n|\
hc5*61|\
hg255d|\
hlk-rm04|\
diff --git a/target/linux/ramips/dts/GL-MT300N.dts 
b/target/linux/ramips/dts/GL-MT300N.dts
new file mode 100644
index 000..82db37e
--- /dev/null
+++ b/target/linux/ramips/dts/GL-MT300N.dts
@@ -0,0 +1,153 @@
+/dts-v1/;
+
+/include/ "mt7620n.dtsi"
+
+/ {
+   compatible = "GL-MT300N", "ralink,mt7620n-soc";
+   model = "GL-MT300N";
+
+   chosen {
+   bootargs = "console=ttyS0,115200";
+   };
+
+   palmbus@1000 {
+   gpio0: gpio@600 {
+   status = "okay";
+   };
+
+   gpio1: gpio@638 {
+   status = "okay";
+   };
+
+   gpio2: gpio@660 {
+   status = "okay";
+   };
+   
+   gpio3: gpio@688 {
+ status = "okay";
+};
+
+   spi@b00 {
+   status = "okay";
+
+   m25p80@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "w25q128";
+   reg = <0 0>;
+   linux,modalias = "m25p80", "w25q128";
+   spi-max-frequency = <1000>;
+
+   partition@0 {
+   label = "u-boot";
+   reg = <0x0 0x3>;
+   };
+
+   partition@3 {
+   label = "u-boot-env";
+   reg = <0x3 0x1>;
+   read-only;
+   };
+
+   factory: partition@4 {
+   label = "factory";
+   reg = <0x4 0x1>;
+   read-only;
+   };
+
+   partition@5 {
+   label = "firmware";
+   reg = <0x5 0xf8>;
+   };
+
+   partition@ff {
+   label = "art";
+   reg = <0xff 0x1

[OpenWrt-Devel] [PATCH 3/3] ramips: Add support for GL-MT750

[alzhao]

This patch adds support for GL-MT750.
GL-MT750 is powered by MT7620A and MT7610e, dual band 802.11ac, 2.4G 300Mbps 
and 5G 450Mbps.
It has 5 LANs, MMC interface, USB, a lot of IOs and PoE support.
---
 target/linux/ramips/base-files/etc/board.d/01_leds |   3 +-
 .../linux/ramips/base-files/etc/board.d/02_network |   1 +
 target/linux/ramips/base-files/lib/ramips.sh   |   3 +
 .../ramips/base-files/lib/upgrade/platform.sh  |   1 +
 target/linux/ramips/dts/GL-MT750.dts   | 159 +
 target/linux/ramips/image/Makefile |   2 +
 target/linux/ramips/mt7620/profiles/gli.mk |   9 ++
 7 files changed, 177 insertions(+), 1 deletion(-)
 create mode 100644 target/linux/ramips/dts/GL-MT750.dts

diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds 
b/target/linux/ramips/base-files/etc/board.d/01_leds
index 132c7ce..6c25c86 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -138,7 +138,8 @@ fonera20n)
set_wifi_led "$board:orange:wifi"
;;
 gl-mt300a|\
-gl-mt300n)
+gl-mt300n|\
+gl-mt750)
set_wifi_led "$board:wlan"
;;
 hc5661)
diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
b/target/linux/ramips/base-files/etc/board.d/02_network
index 40c24a9..dc9b5b2 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -115,6 +115,7 @@ ramips_setup_interfaces()
f5d8235-v2|\
gl-mt300a|\
gl-mt300n|\
+   gl-mt750|\
hg255d|\
mzk-wdpr|\
jhr-n805r|\
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index fcc4b9f..815765a 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -181,6 +181,9 @@ ramips_board_detect() {
*"GL-MT300N")
name="gl-mt300n"
;;
+   *"GL-MT750")
+   name="gl-mt750"
+   ;;
*"HC5661")
name="hc5661"
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index 8727831..b1d2347 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -58,6 +58,7 @@ platform_check_image() {
freestation5|\
gl-mt300a|\
gl-mt300n|\
+   gl-mt750|\
hc5*61|\
hg255d|\
hlk-rm04|\
diff --git a/target/linux/ramips/dts/GL-MT750.dts 
b/target/linux/ramips/dts/GL-MT750.dts
new file mode 100644
index 000..a36ae5e
--- /dev/null
+++ b/target/linux/ramips/dts/GL-MT750.dts
@@ -0,0 +1,159 @@
+/dts-v1/;
+
+/include/ "mt7620a.dtsi"
+
+/ {
+   compatible = "GL-MT750", "ralink,mt7620a-soc";
+   model = "GL-MT750";
+
+   chosen {
+   bootargs = "console=ttyS0,115200";
+   };
+
+   palmbus@1000 {
+   gpio0: gpio@600 {
+   status = "okay";
+   };
+
+   gpio1: gpio@638 {
+   status = "okay";
+   };
+
+   gpio2: gpio@660 {
+   status = "okay";
+   };
+   
+   gpio3: gpio@688 {
+ status = "okay";
+};
+
+   spi@b00 {
+   status = "okay";
+
+   m25p80@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "w25q128";
+   reg = <0 0>;
+   linux,modalias = "m25p80", "w25q128";
+   spi-max-frequency = <1000>;
+
+   partition@0 {
+   label = "u-boot";
+   reg = <0x0 0x3>;
+   };
+
+   partition@3 {
+   label = "u-boot-env";
+   reg = <0x3 0x1>;
+   read-only;
+   };
+
+   factory: partition@4 {
+   label = "factory";
+   reg = <0x4 0x1>;
+   read-only;
+   };
+
+   partition@5 {
+   label = "firmware";
+   reg = <0x5 0xf8>;
+   };
+
+   partition@ff {
+   label = "art";
+   

[OpenWrt-Devel] Getting error after upgrading LUCI

[nam228]

Deal all,

I am using OpenWRT Chaos Calmer (Revision: 46522).
I have the error "sending SIGSEGV to ubusd for invalid write access ..." 
after upgrading luci.


I upgraded luci by these commands:

 openwrt/script/feeds update
 openwrt/script/feeds install luci

Do you have any idea about this problem?

Thanks,
Nam.


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel