[OpenWrt-Devel] [PATCH 2/4] ralink: add HIGHMEM support for mt7621
Signed-off-by: wengbj --- target/linux/ramips/mt7621/config-3.18 |1 + .../0112-add-mt7621-support-high-memory.patch | 13 + 2 files changed, 14 insertions(+) create mode 100644 target/linux/ramips/patches-3.18/0112-add-mt7621-support-high-memory.patch diff --git a/target/linux/ramips/mt7621/config-3.18 b/target/linux/ramips/mt7621/config-3.18 index 11d372b..dcc7b5a 100644 --- a/target/linux/ramips/mt7621/config-3.18 +++ b/target/linux/ramips/mt7621/config-3.18 @@ -217,3 +217,4 @@ CONFIG_WATCHDOG_CORE=y CONFIG_WEAK_ORDERING=y CONFIG_XPS=y CONFIG_ZONE_DMA_FLAG=0 +CONFIG_BOUNCE=y diff --git a/target/linux/ramips/patches-3.18/0112-add-mt7621-support-high-memory.patch b/target/linux/ramips/patches-3.18/0112-add-mt7621-support-high-memory.patch new file mode 100644 index 000..b3df1c5 --- /dev/null +++ b/target/linux/ramips/patches-3.18/0112-add-mt7621-support-high-memory.patch @@ -0,0 +1,13 @@ +Index: linux-3.18.11/arch/mips/ralink/Kconfig +=== +--- linux-3.18.11.orig/arch/mips/ralink/Kconfig2015-04-28 17:30:50.631568808 +0800 linux-3.18.11/arch/mips/ralink/Kconfig 2015-04-28 17:32:10.167567161 +0800 +@@ -46,6 +46,8 @@ + select SYS_SUPPORTS_MULTITHREADING + select SYS_SUPPORTS_SMP + select SYS_SUPPORTS_MIPS_CMP ++ select SYS_SUPPORTS_HIGHMEM ++ select HIGHMEM + select IRQ_GIC + select HW_HAS_PCI + -- 1.7.9.5 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 3/4] ralink: change FireWRT memory to 448MB
Signed-off-by: wengbj
---
target/linux/ramips/dts/FIREWRT.dts |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/linux/ramips/dts/FIREWRT.dts
b/target/linux/ramips/dts/FIREWRT.dts
index 2b018e6..7d90157 100644
--- a/target/linux/ramips/dts/FIREWRT.dts
+++ b/target/linux/ramips/dts/FIREWRT.dts
@@ -8,7 +8,7 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x1000>;
+ reg = <0x0 0x1c00>;
};
chosen {
--
1.7.9.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/4] kernel: mips jump only works with memory less then 256mb. when enable HIGHMEM use long jump
Signed-off-by: wengbj --- .../patches-3.18/305-mips_module_reloc.patch |7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/target/linux/generic/patches-3.18/305-mips_module_reloc.patch b/target/linux/generic/patches-3.18/305-mips_module_reloc.patch index 41cf806..fd31f9f 100644 --- a/target/linux/generic/patches-3.18/305-mips_module_reloc.patch +++ b/target/linux/generic/patches-3.18/305-mips_module_reloc.patch @@ -1,6 +1,6 @@ --- a/arch/mips/Makefile +++ b/arch/mips/Makefile -@@ -90,8 +90,13 @@ all-$(CONFIG_SYS_SUPPORTS_ZBOOT)+= vmlin +@@ -90,8 +90,18 @@ all-$(CONFIG_SYS_SUPPORTS_ZBOOT)+= vmlin cflags-y += -G 0 -mno-abicalls -fno-pic -pipe -mno-branch-likely cflags-y += -msoft-float LDFLAGS_vmlinux += -G 0 -static -n -nostdlib --gc-sections @@ -8,9 +8,14 @@ KBUILD_AFLAGS_MODULE += -mlong-calls KBUILD_CFLAGS_MODULE += -mlong-calls +else ++ifdef CONFIG_HIGHMEM ++KBUILD_AFLAGS_MODULE += -mlong-calls ++KBUILD_CFLAGS_MODULE += -mlong-calls ++else +KBUILD_AFLAGS_MODULE += -mno-long-calls +KBUILD_CFLAGS_MODULE += -mno-long-calls +endif ++endif ifndef CONFIG_FUNCTION_TRACER KBUILD_CFLAGS_KERNEL += -ffunction-sections -fdata-sections -- 1.7.9.5 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.
Hello Rafał Attached is the brcmfmac patch as it is under review. One comment needs to be processed, but the general idea remains the same. All calls for this nvram reading are made under the define CONFIG_BCM47XX_NVRAM. Therefor it is mandatory that openwrt gets updated first. Only once the patch in openwrt is out the patch for brcmfmac will be posted. It can only break openwrt builds and nothing else as CONFIG_BCM47XX_NVRAM is openwrt specific. The reason why I choose not to copy the buffer in a freshly allocated buffer is that it was much more work. The problem is that allocating more than 64K or more will fail with kzalloc (or similar) so other alloc function need to be used. As a result also an API (and implementation) for releasing this memory needs to be added. This buffer is to be used read-only. So I choose the easy road, but if you prefer something else then I can do that. Regards, Hante -Original Message- From: Rafał Miłecki [mailto:zaj...@gmail.com] Sent: vrijdag 24 april 2015 14:08 To: Hante Meuleman Cc: Ian Kent; Arend Van Spriel; Jonas Gorski; mailinglist Subject: Re: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram. On 24 April 2015 at 12:03, Hante Meuleman wrote: > Attached are the two patch files. They were generated from > include/linux/bcm47xx_nvram.h and from > drivers/firmware/broadcom/bcm47xx_nvram.c. I think your idea is correct, I was just thinking about bcm47xx_nvram copying content to provided buffer, instead of sharing its own. I got an impression it's solution usually used when dealing with such situations & this would also protect bcm47xx internals. I'm not really sure how to submit this patch. It exports symbol and will be required by brcmfmac, so I guess we should ask Kalle to pick it. However I also planned moving nvram.c from mips to bcm47xx_nvram.c in firmware and I planned to submit this patch to Ralf (mips maintainer). Maybe it'll be better to work on moving NVRAM driver first? This would make more sense to Kalle accepting drivers/firmware/ patch rather than arch/mips/. We could keep this change in OpenWrt for now. I could submit patch to Ralf for 3.2 kernel. Then for 3.3 we could finally upstream your change to Kalle's tree. Can you also share your brcmfmac patch? firmware_nvram.patch Description: firmware_nvram.patch ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] AR8334 switch support
Am 27.04.2015 um 20:56 schrieb Heiner Kallweit: The only other difference I found is the initial setting of LED_CTRL3 register. Could you please test the following patch (first remove the initial patch attempt)? [0.85] switch0: Atheros AR833X rev. 2 switch registered on ag71xx-mdio.0 [0.86] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: led_val = 3f [0.86] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: Detected AR8337 It seems that we have no luck here... In case you have any new idea I'll test the patch. Here is a picture of the switch chip: http://c33.imgup.net/2015-04-166a5b.jpg Best Christian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] OpenHub account for uci, ubus etc.
As for now OpenWrt account pulls following repositories: https://www.openhub.net/p/openwrt/enlistments Should uci, libubox, ubus etc. be also included into these locations or should these projects get own accounts? Regards, Yegor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] odhcp6c: Fix white space errors
Signed-off-by: Hans Dedecker
---
package/network/ipv6/odhcp6c/files/dhcpv6.script | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/package/network/ipv6/odhcp6c/files/dhcpv6.script
b/package/network/ipv6/odhcp6c/files/dhcpv6.script
index 5f3ff15..5e5b9a9 100755
--- a/package/network/ipv6/odhcp6c/files/dhcpv6.script
+++ b/package/network/ipv6/odhcp6c/files/dhcpv6.script
@@ -34,10 +34,10 @@ setup_interface () {
for prefix in $PREFIXES; do
proto_add_ipv6_prefix "$prefix"
-local entry="${prefix#*/}"
-entry="${entry#*,}"
-entry="${entry#*,}"
-local valid="${entry%%,*}"
+ local entry="${prefix#*/}"
+ entry="${entry#*,}"
+ entry="${entry#*,}"
+ local valid="${entry%%,*}"
if [ -z "$RA_ADDRESSES" -a -z "$RA_ROUTES" -a \
-z "$RA_DNS" -a "$FAKE_ROUTES" = 1 ]; then
@@ -69,10 +69,10 @@ setup_interface () {
proto_add_ipv6_address "$addr" "$mask" "$preferred" "$valid" 1
-if [ -z "$RA_ADDRESSES" -a -z "$RA_ROUTES" -a \
--z "$RA_DNS" -a "$FAKE_ROUTES" = 1 ]; then
-RA_ROUTES="::/0,$SERVER,$valid,4096"
-fi
+ if [ -z "$RA_ADDRESSES" -a -z "$RA_ROUTES" -a \
+ -z "$RA_DNS" -a "$FAKE_ROUTES" = 1 ]; then
+ RA_ROUTES="::/0,$SERVER,$valid,4096"
+ fi
done
for entry in $RA_ROUTES; do
--
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] uci: properly close input before exit
Signed-off-by: Hans Dedecker
---
cli.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/cli.c b/cli.c
index 557472e..e1e0a66 100644
--- a/cli.c
+++ b/cli.c
@@ -687,6 +687,7 @@ int main(int argc, char **argv)
break;
case 'f':
if (input != stdin) {
+ fclose(input);
perror("uci");
return 1;
}
--
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] ubus: Fix memleak in examples/client in case of failure
Signed-off-by: Hans Dedecker
---
examples/client.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/examples/client.c b/examples/client.c
index 952ab54..7ef5663 100644
--- a/examples/client.c
+++ b/examples/client.c
@@ -118,6 +118,7 @@ static void test_count(struct uloop_timeout *timeout)
blobmsg_add_string(&b, "string", s);
if (ubus_lookup_id(ctx, "test", &id)) {
+ free(s);
fprintf(stderr, "Failed to look up test object\n");
return;
}
--
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] odhcpd: Remove prefix class config option as not supported anymore by odhcpd
Signed-off-by: Hans Dedecker --- package/network/services/odhcpd/Makefile | 8 1 file changed, 8 deletions(-) diff --git a/package/network/services/odhcpd/Makefile b/package/network/services/odhcpd/Makefile index 635a251..22b9e38 100644 --- a/package/network/services/odhcpd/Makefile +++ b/package/network/services/odhcpd/Makefile @@ -25,10 +25,6 @@ include $(INCLUDE_DIR)/cmake.mk CMAKE_OPTIONS += -DUBUS=1 -ifneq ($(CONFIG_PACKAGE_odhcpd_ext_prefix_class),0) - CMAKE_OPTIONS += -DEXT_PREFIX_CLASS=$(CONFIG_PACKAGE_odhcpd_ext_prefix_class) -endif - ifneq ($(CONFIG_PACKAGE_odhcpd_ext_cer_id),0) CMAKE_OPTIONS += -DEXT_CER_ID=$(CONFIG_PACKAGE_odhcpd_ext_cer_id) endif @@ -42,10 +38,6 @@ define Package/odhcpd endef define Package/odhcpd/config - config PACKAGE_odhcpd_ext_prefix_class -int "Prefix Class Extension ID (0 = disabled)" -depends on PACKAGE_odhcpd -default 0 config PACKAGE_odhcpd_ext_cer_id int "CER-ID Extension ID (0 = disabled)" depends on PACKAGE_odhcpd -- 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] AR8334 switch support
On Tue, Apr 28, 2015 at 5:15 AM, Christian Mehlis wrote: > Am 27.04.2015 um 20:56 schrieb Heiner Kallweit: >> >> The only other difference I found is the initial setting of LED_CTRL3 >> register. >> Could you please test the following patch (first remove the initial patch >> attempt)? > > > [0.85] switch0: Atheros AR833X rev. 2 switch registered on > ag71xx-mdio.0 > [0.86] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: led_val = 3f > [0.86] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: Detected > AR8337 > > It seems that we have no luck here... > In case you have any new idea I'll test the patch. Here's some general info about the QCA8334 chip that might help. If you have specific questions let me know and I will try to find answers. The four ports of the Gigabit switch engine are: Port 0 GMAC: RGMII/MII/RMII Port 2 and 3 GMAC: 2 *10/100/1000BASE-T Port 6 GMAC: SerDes/SGMII It can be configured using serial EEPROM and/or the MDC/MDIO interface. kg ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] build: don't call prereq for any package/symlinks rules
make package/symlinks can be used as an alternative to the ./scripts/feeds
command to update & install all feeds available in feeds.conf
Here is the code from the top Makefile:
# update all feeds, re-create index files, install symlinks
package/symlinks:
$(SCRIPT_DIR)/feeds update -a
$(SCRIPT_DIR)/feeds install -a
# re-create index files, install symlinks
package/symlinks-install:
$(SCRIPT_DIR)/feeds update -i
$(SCRIPT_DIR)/feeds install -a
# remove all symlinks, don't touch ./feeds
package/symlinks-clean:
$(SCRIPT_DIR)/feeds uninstall -a
Thanks,
Mathieu
-Original Message-
From: 'Toerless Eckert' [mailto:t...@cs.fau.de]
Sent: Monday, April 27, 2015 6:46 PM
To: Mathieu Olivari
Cc: 'Mathieu Olivari'; openwrt-devel@lists.openwrt.org
Subject: Re: [OpenWrt-Devel] [PATCH] build: don't call prereq for any
package/symlinks rules
So if "make package/symlinks" is optional, when is it needed ?
Sorry for the beginner q.
On Mon, Apr 27, 2015 at 05:15:36PM -0700, Mathieu Olivari wrote:
> I'm actually talking about the command below:
> $ make package/symlinks
>
> Right after the git clone, it does open the menuconfig. Which ends-up
> in generating a .config, which has to be deleted anyway as any package
> from feed would get removed.
>
> Thanks,
> Mathieu
>
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Toerless Eckert
> Sent: Monday, April 27, 2015 4:59 PM
> To: Mathieu Olivari
> Cc: openwrt-devel@lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] [PATCH] build: don't call prereq for any
> package/symlinks rules
>
>
> Mathieu:
>
> I can't quite follow your explanations. I ahve been building what
> looks to me perfectly well working 14.07 images by just doing:
>
> git clone git://git.openwrt.org/openwrt.git cd openwrt # Clean
> workspace now
>
> cp real.config .config
> make defconfig
> make
>
> Your mail seems to indicate that that supposedly does not work. Can
> you please tell me what exactly is breaking when i do that ?
>
> Thanks
> Toerless
>
> On Mon, Apr 27, 2015 at 04:46:49PM -0700, Mathieu Olivari wrote:
> > Most of the time, we want to make sure OpenWrt has been configured
> > and setup before start running make. However, in case of
> > package/symlinks, forcing prereq as a dependency creates multiple
issues:
> > *when executed on a clean workspace, it will prompt for user input
> > and open a menuconfig window before executing the feeds command *the
> > only way around that is to provide a .config. However, the "prereq"
> > target would then run a "make defconfig", which will remove all the
> > packages in the .config but from external feeds, as feeds have not
> > been installed yet.
> >
> > The only way to currently work around this, is to generate a fake
> > config by running "make defconfig", then "make package/symlinks",
> > copy the real config (which at this point disregards the previously
> > generated config), and run make defconfig again. Something like this:
> >
> > make defconfig
> > make package/symlinks
> > cp real.config .config
> > make defconfig
> >
> > This change is removing the need for the first defconfig, making the
> > process more logical for OpenWrt users using the package/symlinks
target.
> >
> > Signed-off-by: Mathieu Olivari
> > ---
> > include/toplevel.mk | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/include/toplevel.mk b/include/toplevel.mk index
> > d8651d9..b3b344d 100644
> > --- a/include/toplevel.mk
> > +++ b/include/toplevel.mk
> > @@ -178,6 +178,7 @@ ifeq ($(SDK),1)
> > else
> >
> > %::
> > +ifeq ($(filter package/symlinks%,$(MAKECMDGOALS)),)
> > @+$(PREP_MK) $(NO_TRACE_MAKE) -r -s prereq
> > @( \
> > cp .config tmp/.config; \
> > @@ -186,6 +187,7 @@ else
> > printf "$(_R)WARNING: your configuration is out of
> sync. Please run make menuconfig, oldconfig or defconfig!$(_N)\n" >&2;
> \
> > fi \
> > )
> > +endif
> > @+$(ULIMIT_FIX) $(SUBMAKE) -r $@ $(if $(WARN_PARALLEL_ERROR), || {
\
> > printf "$(_R)Build failed - please re-run with -j1 to see
> the real error message$(_N)\n" >&2; \
> > false; \
> > --
> > 1.9.1
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
--
---
toerless.eck...@informatik.uni-erlangen.de
/C=de/A=d400/P=uni-erlangen/OU=informatik/S=Eckert/G=Toerless/
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] AR8334 switch support
Am 28.04.2015 um 14:15 schrieb Christian Mehlis: > Am 27.04.2015 um 20:56 schrieb Heiner Kallweit: >> The only other difference I found is the initial setting of LED_CTRL3 >> register. >> Could you please test the following patch (first remove the initial patch >> attempt)? > > [0.85] switch0: Atheros AR833X rev. 2 switch registered on > ag71xx-mdio.0 > [0.86] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: led_val = 3f > [0.86] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: Detected AR8337 > > It seems that we have no luck here... > In case you have any new idea I'll test the patch. > > Here is a picture of the switch chip: > http://c33.imgup.net/2015-04-166a5b.jpg > > Best > Christian > . > I found a datasheet for QCA8334 and according to it these bits in LED_CTRl3 are supposed to be 0 for this chip. But this doesn't seem to be true .. Meanwhile I'm running out of ideas how to tell between the two chips. However I have another hypothesis: The drivers sets bit MAC06_EXCHANGE_EN for AR8337. According to the datasheet this means "Exchange MAC0 and MAC6". My assumption is that MAC6 is used as CPU port if this bit is set. Having said this whether to set this bit or not might not be chip-specific but board-specific (CPU connected to MAC0 vs. MAC6 pins of the switch chip). AR8334 has no MAC6 (R)GMII pins therefore this bit must not be set. Not sure how many supported devices actually use an AR8337. Maybe they share some reference design and use MAC6 in general? Conclusion would be that the driver can not know whether to set the bit or not. It would have to be defined in platform configuration or device tree. I'm not an expert and refactored few parts of the driver only. Therefore I can not promise any quick results, however I'll have a look at it. Rgds, Heiner ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [ramips] Add support for Comfast CF-WR800N
This patch adds support for Comfast CF-WR800N, a wall-plug wireless router
based on the MT7620N SoC with one Ethernet port and a 802.11n 2.4 GHz radio.
Signed-off-by: Roger Pueyo Centelles
---
target/linux/ramips/base-files/etc/board.d/01_leds | 4 +
.../linux/ramips/base-files/etc/board.d/02_network | 6 ++
target/linux/ramips/base-files/etc/diag.sh | 3 +
target/linux/ramips/base-files/lib/ramips.sh | 3 +
.../ramips/base-files/lib/upgrade/platform.sh | 1 +
target/linux/ramips/dts/CF-WR800N.dts | 114 +
target/linux/ramips/image/Makefile | 2 +
7 files changed, 133 insertions(+)
create mode 100644 target/linux/ramips/dts/CF-WR800N.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 56ba3b7..80623f4 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -73,6 +73,10 @@ case $board in
br6524n)
set_wifi_led "edimax:blue:wlan"
;;
+ cf-wr800n)
+ ucidef_set_led_netdev "lan" "lan" "comfast:white:ethernet"
eth0.1
+ set_wifi_led "comfast:white:wifi"
+ ;;
cy-swr1100)
ucidef_set_led_default "wps" "WPS" "samsung:blue:wps" "0"
set_usb_led "samsung:blue:usb"
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 24e1ba8..c8ef69f 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -108,6 +108,12 @@ ramips_setup_interfaces()
ucidef_add_switch_vlan "switch0" "1" "1 2 3 4 6t"
;;
+ cf-wr800n)
+ ucidef_set_interface_lan "eth0.1"
+ ucidef_add_switch "switch0" "1" "1"
+ ucidef_add_switch_vlan "switch0" "1" "4 6t"
+ ;;
+
cy-swr1100)
ucidef_set_interfaces_lan_wan "eth0.1" "eth0.2"
ucidef_add_switch "switch0" "1" "1"
diff --git a/target/linux/ramips/base-files/etc/diag.sh
b/target/linux/ramips/base-files/etc/diag.sh
index 5301593..caede7b 100644
--- a/target/linux/ramips/base-files/etc/diag.sh
+++ b/target/linux/ramips/base-files/etc/diag.sh
@@ -36,6 +36,9 @@ get_status_led() {
br6425 | br-6475nd)
status_led="edimax:green:power"
;;
+ cf-wr800n)
+ status_led="comfast:white:wps"
+ ;;
cy-swr1100)
status_led="samsung:blue:wps"
;;
diff --git a/target/linux/ramips/base-files/lib/ramips.sh
b/target/linux/ramips/base-files/lib/ramips.sh
index 616f4a1..5769d26 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -91,6 +91,9 @@ ramips_board_detect() {
*"Buffalo WSR-1166DHP")
name="wsr-1166"
;;
+ *"Comfast CF-WR800N")
+ name="cf-wr800n"
+ ;;
*"Firefly FireWRT")
name="firewrt"
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index 17b456b..4ecf331 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -33,6 +33,7 @@ platform_check_image() {
bc2 | \
broadway | \
carambola | \
+ cf-wr800n | \
d105 | \
dap-1350 | \
dcs-930 | \
diff --git a/target/linux/ramips/dts/CF-WR800N.dts
b/target/linux/ramips/dts/CF-WR800N.dts
new file mode 100644
index 000..5db6c83
--- /dev/null
+++ b/target/linux/ramips/dts/CF-WR800N.dts
@@ -0,0 +1,114 @@
+/dts-v1/;
+
+/include/ "mt7620n.dtsi"
+
+/ {
+ compatible = "cf-wr800n", "ralink,mt7620n-soc";
+ model = "Comfast CF-WR800N";
+
+ 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 = "mx25l6405d";
+ reg = <0 0>;
+ linux,modalias = "m25p80", "w25q64";
+ spi-max-frequency = <1000>;
+
+
Re: [OpenWrt-Devel] AR8334 switch support
Am 28.04.2015 um 20:37 schrieb Heiner Kallweit:
> Am 28.04.2015 um 14:15 schrieb Christian Mehlis:
>> Am 27.04.2015 um 20:56 schrieb Heiner Kallweit:
>>> The only other difference I found is the initial setting of LED_CTRL3
>>> register.
>>> Could you please test the following patch (first remove the initial patch
>>> attempt)?
>>
>> [0.85] switch0: Atheros AR833X rev. 2 switch registered on
>> ag71xx-mdio.0
>> [0.86] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: led_val = 3f
>> [0.86] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: Detected AR8337
>>
>> It seems that we have no luck here...
>> In case you have any new idea I'll test the patch.
>>
>> Here is a picture of the switch chip:
>> http://c33.imgup.net/2015-04-166a5b.jpg
>>
>> Best
>> Christian
>> .
>>
> I found a datasheet for QCA8334 and according to it these bits in LED_CTRl3
> are supposed to
> be 0 for this chip. But this doesn't seem to be true ..
> Meanwhile I'm running out of ideas how to tell between the two chips.
>
> However I have another hypothesis:
> The drivers sets bit MAC06_EXCHANGE_EN for AR8337. According to the datasheet
> this means
> "Exchange MAC0 and MAC6". My assumption is that MAC6 is used as CPU port if
> this bit is set.
> Having said this whether to set this bit or not might not be chip-specific
> but board-specific
> (CPU connected to MAC0 vs. MAC6 pins of the switch chip).
> AR8334 has no MAC6 (R)GMII pins therefore this bit must not be set.
> Not sure how many supported devices actually use an AR8337. Maybe they share
> some
> reference design and use MAC6 in general?
> Conclusion would be that the driver can not know whether to set the bit or
> not. It would
> have to be defined in platform configuration or device tree.
>
> I'm not an expert and refactored few parts of the driver only.
> Therefore I can not promise any quick results, however I'll have a look at it.
>
> Rgds, Heiner
>
It was easier than I thought, here comes the related patch.
Known limitations:
1. The patch supports configuration of this bit for platform-data-configured
platforms only. DT-based platforms would need a similar extension.
2. For now it's for WPJ344 only. Every other AR8334-based device would need the
same
extension to the platform data.
Rgds, Heiner
---
target/linux/ar71xx/files/arch/mips/ath79/mach-wpj344.c| 1 +
target/linux/generic/files/drivers/net/phy/ar8327.c| 5 -
target/linux/generic/files/include/linux/ar8216_platform.h | 4 +++-
3 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-wpj344.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-wpj344.c
index fd718bd..590778e 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-wpj344.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-wpj344.c
@@ -98,6 +98,7 @@ static struct ar8327_pad_cfg wpj344_ar8327_pad0_cfg = {
.rxclk_delay_en = true,
.txclk_delay_sel = AR8327_CLK_DELAY_SEL1,
.rxclk_delay_sel = AR8327_CLK_DELAY_SEL2,
+ .mac06_exchange_en = -1,
};
static struct ar8327_led_cfg wpj344_ar8327_led_cfg = {
diff --git a/target/linux/generic/files/drivers/net/phy/ar8327.c
b/target/linux/generic/files/drivers/net/phy/ar8327.c
index 07e837e..772d03f 100644
--- a/target/linux/generic/files/drivers/net/phy/ar8327.c
+++ b/target/linux/generic/files/drivers/net/phy/ar8327.c
@@ -124,6 +124,9 @@ ar8327_get_pad_cfg(struct ar8327_pad_cfg *cfg)
break;
}
+ if (cfg->mac06_exchange_en == 1)
+ t |= AR8337_PAD_MAC06_EXCHANGE_EN;
+
return t;
}
@@ -508,7 +511,7 @@ ar8327_hw_config_pdata(struct ar8xxx_priv *priv,
data->port6_status = ar8327_get_port_init_status(&pdata->port6_cfg);
t = ar8327_get_pad_cfg(pdata->pad0_cfg);
- if (chip_is_ar8337(priv))
+ if (chip_is_ar8337(priv) && pdata->pad0_cfg->mac06_exchange_en == 0)
t |= AR8337_PAD_MAC06_EXCHANGE_EN;
ar8xxx_write(priv, AR8327_REG_PAD0_MODE, t);
diff --git a/target/linux/generic/files/include/linux/ar8216_platform.h
b/target/linux/generic/files/include/linux/ar8216_platform.h
index 4935ad3..821ff27 100644
--- a/target/linux/generic/files/include/linux/ar8216_platform.h
+++ b/target/linux/generic/files/include/linux/ar8216_platform.h
@@ -47,6 +47,8 @@ struct ar8327_pad_cfg {
bool sgmii_delay_en;
enum ar8327_clk_delay_sel txclk_delay_sel;
enum ar8327_clk_delay_sel rxclk_delay_sel;
+ /* 0 = use driver default -1 = disable 1 = enable */
+ int mac06_exchange_en;
};
enum ar8327_port_speed {
@@ -128,4 +130,4 @@ struct ar8327_platform_data {
const struct ar8327_led_info *leds;
};
-#endif /* AR8216_PLATFORM_H */
\ No newline at end of file
+#endif /* AR8216_PLATFORM_H */
--
2.3.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listin
Re: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.
On Tue, 2015-04-28 at 10:31 +, Hante Meuleman wrote: > Hello Rafał > > Attached is the brcmfmac patch as it is under review. One comment > needs to be processed, but the general idea remains the same. All > calls for this nvram reading are made under the define > CONFIG_BCM47XX_NVRAM. Therefor it is mandatory that openwrt > gets updated first. Only once the patch in openwrt is out the patch > for brcmfmac will be posted. It can only break openwrt builds and > nothing else as CONFIG_BCM47XX_NVRAM is openwrt specific. > > The reason why I choose not to copy the buffer in a freshly allocated > buffer is that it was much more work. The problem is that allocating > more than 64K or more will fail with kzalloc (or similar) so other > alloc function need to be used. As a result also an API (and > implementation) for releasing this memory needs to be added. This > buffer is to be used read-only. So I choose the easy road, but if you > prefer something else then I can do that. Yeah, I wonder if there is any possibility that the buffer could go away while brcmfmac thinks it's still available? That would be the only reason to worry. Not sure I see the difficulty here either. Reading the nvram isn't done in interrupt context (is it?) and I think it's not time critical either? So kvmalloc() is essentially a drop in replacement for kmalloc() > > Regards, > Hante > > -Original Message- > From: Rafał Miłecki [mailto:zaj...@gmail.com] > Sent: vrijdag 24 april 2015 14:08 > To: Hante Meuleman > Cc: Ian Kent; Arend Van Spriel; Jonas Gorski; mailinglist > Subject: Re: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for > multiple PCIE devices in nvram. > > On 24 April 2015 at 12:03, Hante Meuleman wrote: > > Attached are the two patch files. They were generated from > > include/linux/bcm47xx_nvram.h and from > > drivers/firmware/broadcom/bcm47xx_nvram.c. > > I think your idea is correct, I was just thinking about bcm47xx_nvram > copying content to provided buffer, instead of sharing its own. I got > an impression it's solution usually used when dealing with such > situations & this would also protect bcm47xx internals. > > I'm not really sure how to submit this patch. It exports symbol and > will be required by brcmfmac, so I guess we should ask Kalle to pick > it. However I also planned moving nvram.c from mips to bcm47xx_nvram.c > in firmware and I planned to submit this patch to Ralf (mips > maintainer). > > Maybe it'll be better to work on moving NVRAM driver first? This would > make more sense to Kalle accepting drivers/firmware/ patch rather than > arch/mips/. We could keep this change in OpenWrt for now. I could > submit patch to Ralf for 3.2 kernel. Then for 3.3 we could finally > upstream your change to Kalle's tree. > > Can you also share your brcmfmac patch? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
