[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 dedec...@gmail.com
---
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] ubus: Fix memleak in examples/client in case of failure
Signed-off-by: Hans Dedecker dedec...@gmail.com
---
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
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 meule...@broadcom.com 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
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
Re: [OpenWrt-Devel] AR8334 switch support
On Tue, Apr 28, 2015 at 5:15 AM, Christian Mehlis christ...@m3hlis.de 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 math...@qca.qualcomm.com
---
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 roger.pu...@guifi.net
---
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;
+
+ partition@0 {
+ label = u-boot;
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 meule...@broadcom.com 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
[OpenWrt-Devel] [PATCH 3/4] ralink: change FireWRT memory to 448MB
Signed-off-by: wengbj fl.serv...@t-firefly.com
---
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 fl.serv...@t-firefly.com --- .../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
[OpenWrt-Devel] [PATCH 2/4] ralink: add HIGHMEM support for mt7621
Signed-off-by: wengbj fl.serv...@t-firefly.com --- 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
