Re: [OpenWrt-Devel] Thoughts on shellcheck?
* Eric Schultz eschu...@prplfoundation.org [03.05.2015 20:28]: Hey, I wanted to let folks know about this open source tool for finding errors in shell scripts that I stumbled on: https://github.com/koalaman/shellcheck. Not sure on how applicable it will be to the complex features that OpenWrt uses but if it worked well, maybe it could be added and used for verifying new shell script modifications. We did some experiments with that and came to the conclusion, that it does not make sense. it's more an approach for beginners the get good hints... a better way for checking shellscripts it to write tests. bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Archer VR200v GPL code
Hi! Looks like the Firmware of the Archer VR200v is based on Linux. http://www.tp-link.de/support/download/?model=Archer+VR200vversion=V1 binwalk Archer_VR200vv1_0.8.0_0.14_up_boot\(150331\)_2015-03-31_09.02.51.bin DECIMAL HEXADECIMAL DESCRIPTION 20992 0x5200 uImage header, header size: 64 bytes, header CRC: 0x2E017C71, created: Tue Mar 31 02:52:56 2015, image size: 37472 bytes, Data Address: 0xA040, Entry Point: 0xA040, data CRC: 0x103D4E73, OS: Linux, CPU: MIPS, image type: Firmware Image, compression type: lzma, image name: u-boot image 21056 0x5240 LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 99532 bytes 66048 0x10200 uImage header, header size: 64 bytes, header CRC: 0xBEC297, created: Fri Oct 25 09:26:06 2013, image size: 41781 bytes, Data Address: 0x0, Entry Point: 0x0, data CRC: 0xBECBCEC2, OS: Linux, CPU: MIPS, image type: Multi-File Image, compression type: lzma, image name: GPHY Firmware 66120 0x10248 LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 131200 bytes 1320960x20400 LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 3913720 bytes 1442304 0x160200Squashfs filesystem, little endian, version 4.0, compression:lzma, size: 8816203 bytes, 643 inodes, blocksize: 131072 bytes, created: Tue Mar 31 03:01:11 2015 I cannot find the sourcecode on http://www.tp-link.de/support/gpl/ Please release GPL sourcecode allowing to reproducibly verify license compliance for the released binary firmware version 2015-03-31_09.02.51. Thank you! Best regards Daniel Golle ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Archer VR200v GPL code
On Mon, May 04, 2015 at 12:23:10PM +0200, Daniel Golle wrote: I cannot find the sourcecode on http://www.tp-link.de/support/gpl/ In the menu on the left, choose VDSL/ADSL. This leads to: http://www.tp-link.de/support/gpl/?categoryid=548 http://www.tp-link.de/resources/gpl/Archer-VR200v_GPL.tar.gz Regards Mirko ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] lantiq DSL drivers / firmware info
Hi Martin, Has anyone tried any of these firmwares with newer drivers to see if they can do vectoring? Put another way - does anyone have a driver that works with firmware 6.x? Neither v4.11.4 nor v4.11.11 support vectoring. Thus you need at least v4.15.2 (see my other thread which has the links). Unfortunately *I* did not manage to get it working yet (on ADSL2 / Annex B). You said you also don't actually have the current one working though, which was working well for me (on both Annex A and Annex B with VDSL fallback). Note that the system seems to be too slow for 100 Mbps though, so this is somewhat academic, it can't do 100 Mbps NAT in my tests. I'm probably going to replace it with something faster and leave VDSL to a separate modem. johannes ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] lantiq DSL drivers / firmware info
On Mon, 2015-05-04 at 21:00 +0200, Martin Blumenstingl wrote: Like I previously said: there's probably something wrong at my end. I have the Annex A version of the TD-W8970 and I am trying to use it with my Annex B ADSL connection (for the record: I am not using a splitter). While trying to connect the dsl_cpe_control tool reports: Wrong combination of DSL PHY Firmware and hybrid type used! Please change one of it. I've never seen that, but which firmware are you using? I'd been using the speedport 1.21 (e1ef690e8dc0075468d4b6ba7bcdd0fc710bc671) one IIRC. So either my configuration is still incorrect or the modem is somehow (probably a hardware configuration, maybe via a resistor) configured to enforce a different hybrid or Annex type (this is pure speculation though). Are you on VDSL Annex B, where you'd fall back to ADSL 16/1 when vectoring isn't supported? If so, this configuration should work: config vdsl 'dsl' option annex 'b' option firmware '/lib/firmware/vdsl.bin' option tone 'b' option xfer_mode 'ptm' (actually I think you can/should remove the annex line) On my previous ISP I was on Annex A, but I don't have the right configuration right now. Note that the system seems to be too slow for 100 Mbps though, so this is somewhat academic, it can't do 100 Mbps NAT in my tests. I'm probably going to replace it with something faster and leave VDSL to a separate modem. I am interested in your test results, even though it's purely academic :-). First I'm going to replace this router with one that's faster, and then I'll start playing with this :-) Right now I need it to have internet connectivity. Someone else has tested the new driver in the meantime (using Annex A, no VDSL): [0] It seems that the modem syncs and is even able to connect (as far as I understand with some manual steps), but after a few minutes the connection drops. Interesting. I don't think I ever saw any connection dropouts ever. OTOH, I occasionally had the whole system spontaneously wedge itself and require a power cycle, so ... johannes ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [Patch V2 1/2] ipq806x: fix boot freeze on zImage kernel
ARCH_QCOM is using the ARCH_MULTIPLATFORM option, as now recommended on most ARM architectures. This automatically calculate ZRELADDR by masking PHYS_OFFSET with 0xf800. On IPQ806x though, the first ~20MB of RAM is reserved for the hardware. In newer bootloader, when DT is used, this is not a problem, we just reserve this memory in the device tree. But if the bootloader doesn't have DT support, then ATAGS have to be used. In this case, the ARM decompressor will position the kernel in this low mem, which will not be in the RAM section mapped by the bootloader, which means the kernel will freeze in the middle of the boot process trying to map the memory. As a work around, this patch allows disabling AUTO_ZRELADDR when ARCH_QCOM is selected. It makes the zImage usage possible on bootloaders which don't support device-tree, which is the case on certain early IPQ806x based designs. Signed-off-by: Mathieu Olivari math...@codeaurora.org --- Notes: v2: *add the patch for kernel 4.0 .../300-arch-arm-force-ZRELADDR-on-arch-qcom.patch | 72 ++ .../300-arch-arm-force-ZRELADDR-on-arch-qcom.patch | 72 ++ 2 files changed, 144 insertions(+) create mode 100644 target/linux/ipq806x/patches-3.18/300-arch-arm-force-ZRELADDR-on-arch-qcom.patch create mode 100644 target/linux/ipq806x/patches-4.0/300-arch-arm-force-ZRELADDR-on-arch-qcom.patch diff --git a/target/linux/ipq806x/patches-3.18/300-arch-arm-force-ZRELADDR-on-arch-qcom.patch b/target/linux/ipq806x/patches-3.18/300-arch-arm-force-ZRELADDR-on-arch-qcom.patch new file mode 100644 index 000..82170cd --- /dev/null +++ b/target/linux/ipq806x/patches-3.18/300-arch-arm-force-ZRELADDR-on-arch-qcom.patch @@ -0,0 +1,72 @@ +From b12e230f09d4481424e6a5d7e2ae566b6954e83f Mon Sep 17 00:00:00 2001 +From: Mathieu Olivari math...@codeaurora.org +Date: Wed, 29 Apr 2015 15:21:46 -0700 +Subject: [PATCH] HACK: arch: arm: force ZRELADDR on arch-qcom + +ARCH_QCOM is using the ARCH_MULTIPLATFORM option, as now recommended +on most ARM architectures. This automatically calculate ZRELADDR by +masking PHYS_OFFSET with 0xf800. + +However, on IPQ806x, the first ~20MB of RAM is reserved for the hardware +network accelerators, and the bootloader removes this section from the +layout passed from the ATAGS (when used). + +For newer bootloader, when DT is used, this is not a problem, we just +reserve this memory in the device tree. But if the bootloader doesn't +have DT support, then ATAGS have to be used. In this case, the ARM +decompressor will position the kernel in this low mem, which will not be +in the RAM section mapped by the bootloader, which means the kernel will +freeze in the middle of the boot process trying to map the memory. + +As a work around, this patch allows disabling AUTO_ZRELADDR when +ARCH_QCOM is selected. It makes the zImage usage possible on bootloaders +which don't support device-tree, which is the case on certain early +IPQ806x based designs. + +Signed-off-by: Mathieu Olivari math...@codeaurora.org +--- + arch/arm/Kconfig | 2 +- + arch/arm/Makefile| 2 ++ + arch/arm/mach-qcom/Makefile.boot | 1 + + 3 files changed, 4 insertions(+), 1 deletion(-) + create mode 100644 arch/arm/mach-qcom/Makefile.boot + +diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig +index 89c4b5c..4583ea5 100644 +--- a/arch/arm/Kconfig b/arch/arm/Kconfig +@@ -311,7 +311,7 @@ config ARCH_MULTIPLATFORM + select ARCH_WANT_OPTIONAL_GPIOLIB + select ARM_HAS_SG_CHAIN + select ARM_PATCH_PHYS_VIRT +- select AUTO_ZRELADDR ++ select AUTO_ZRELADDR if !ARCH_QCOM + select CLKSRC_OF + select COMMON_CLK + select GENERIC_CLOCKEVENTS +diff --git a/arch/arm/Makefile b/arch/arm/Makefile +index 7453352..5d6f8ac 100644 +--- a/arch/arm/Makefile b/arch/arm/Makefile +@@ -240,9 +240,11 @@ MACHINE := arch/arm/mach-$(word 1,$(machine-y))/ + else + MACHINE := + endif ++ifeq ($(CONFIG_ARCH_QCOM),) + ifeq ($(CONFIG_ARCH_MULTIPLATFORM),y) + MACHINE := + endif ++endif + + machdirs := $(patsubst %,arch/arm/mach-%/,$(machine-y)) + platdirs := $(patsubst %,arch/arm/plat-%/,$(sort $(plat-y))) +diff --git a/arch/arm/mach-qcom/Makefile.boot b/arch/arm/mach-qcom/Makefile.boot +new file mode 100644 +index 000..67a6d5a +--- /dev/null b/arch/arm/mach-qcom/Makefile.boot +@@ -0,0 +1 @@ ++zreladdr-y+= 0x42208000 +-- +1.9.1 + diff --git a/target/linux/ipq806x/patches-4.0/300-arch-arm-force-ZRELADDR-on-arch-qcom.patch b/target/linux/ipq806x/patches-4.0/300-arch-arm-force-ZRELADDR-on-arch-qcom.patch new file mode 100644 index 000..82170cd --- /dev/null +++ b/target/linux/ipq806x/patches-4.0/300-arch-arm-force-ZRELADDR-on-arch-qcom.patch @@ -0,0 +1,72 @@ +From b12e230f09d4481424e6a5d7e2ae566b6954e83f Mon Sep 17 00:00:00 2001 +From: Mathieu Olivari math...@codeaurora.org +Date: Wed, 29 Apr 2015 15:21:46 -0700 +Subject: [PATCH] HACK: arch: arm: force ZRELADDR on arch-qcom +
Re: [OpenWrt-Devel] Intermittent Ethernet failure
Hi Bill! On Mon, May 04, 2015 at 05:53:21PM -0700, Bill wrote: I have finally been able to reproduce the problem here at home by setting up a bridge and leaving it alone for a few days. When it failed, this is what dmesg told me: [ 409.38] eth0: link up (100Mbps/Full duplex) [ 409.38] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 423.38] eth0: link down [ 424.38] eth0: link up (100Mbps/Full duplex) [ 560.38] eth0: link down [ 1674.38] eth0: link up (100Mbps/Full duplex) [ 1680.38] eth0: link down ... This very much looks like a known issue: https://dev.openwrt.org/ticket/19085 https://dev.openwrt.org/ticket/19579 Cheers Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Intermittent Ethernet failure
I have a number of Ubiquiti LOCO M5 units (ar71xx) in use as transparent (simulated layer 2) wireless bridges with the client devices relayd. I used a CC trunk pull of r42711 because I needed support for the new XW variant of this device (which was not, alas, present in BB). I'm seeing very odd behavior. The bridge will work OK for a day or even two, then fail, requiring a reboot of the client. The LOCO keeps working just fine, but the device connected to it loses connectivity to the network. So the LOCO client can still ping the network, but the computer connected to it cannot. The Ethernet port on the computer shows as still connected, but, of course, loses its IP address (provided from the router to which the AP LOCO is connected). The oddest part is that the computer connected to the LOCO still shows up in the ARP table. I have finally been able to reproduce the problem here at home by setting up a bridge and leaving it alone for a few days. When it failed, this is what dmesg told me: [ 53.04] wlan0: authenticate with 04:18:d6:4a:32:19 [ 53.05] wlan0: capabilities/regulatory prevented using AP HT/VHT configuration, downgraded [ 53.07] wlan0: send auth to 04:18:d6:4a:32:19 (try 1/3) [ 53.08] wlan0: authenticated [ 53.12] wlan0: associate with 04:18:d6:4a:32:19 (try 1/3) [ 53.13] wlan0: RX AssocResp from 04:18:d6:4a:32:19 (capab=0x11 status=0 aid=1) [ 53.13] wlan0: associated [ 53.14] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready [ 409.38] eth0: link up (100Mbps/Full duplex) [ 409.38] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 423.38] eth0: link down [ 424.38] eth0: link up (100Mbps/Full duplex) [ 560.38] eth0: link down [ 1674.38] eth0: link up (100Mbps/Full duplex) [ 1680.38] eth0: link down [ 1711.38] eth0: link up (100Mbps/Full duplex) [ 1715.38] eth0: link down [ 1746.38] eth0: link up (100Mbps/Full duplex) [ 1748.38] eth0: link down [ 1794.38] eth0: link up (100Mbps/Full duplex) [ 1998.38] eth0: link down [ 1999.38] eth0: link up (100Mbps/Full duplex) [ 2737.39] eth0: link down [81896.87] eth0: link up (100Mbps/Full duplex) [84330.92] eth0: link up (100Mbps/Half duplex) [84332.92] eth0: link up (100Mbps/Full duplex) [85734.93] eth0: link up (100Mbps/Half duplex) [85736.93] eth0: link up (100Mbps/Full duplex) [86432.96] eth0: link down [86433.96] eth0: link up (100Mbps/Full duplex) [87923.98] eth0: link up (100Mbps/Half duplex) [87925.98] eth0: link up (100Mbps/Full duplex) [92782.07] eth0: link up (100Mbps/Half duplex) [92784.07] eth0: link up (100Mbps/Full duplex) [95022.10] eth0: link down [95023.10] eth0: link up (100Mbps/Full duplex) [96515.14] eth0: link down [96516.14] eth0: link up (100Mbps/Full duplex) [96882.14] eth0: link down [96883.14] eth0: link up (100Mbps/Full duplex) [97615.15] eth0: link up (10Mbps/Half duplex) [97617.15] eth0: link up (100Mbps/Full duplex) [97951.15] eth0: link down [97952.15] eth0: link up (100Mbps/Full duplex) [100654.27] eth0: link down [100655.27] eth0: link up (100Mbps/Full duplex) [101893.27] eth0: link down [101894.27] eth0: link up (100Mbps/Full duplex) [102458.29] eth0: link up (10Mbps/Half duplex) [102460.29] eth0: link up (100Mbps/Full duplex) [103190.30] eth0: link up (100Mbps/Half duplex) [103192.30] eth0: link up (100Mbps/Full duplex) [105302.33] eth0: link down [105303.33] eth0: link up (100Mbps/Full duplex) [107167.36] eth0: link down [107168.36] eth0: link up (100Mbps/Full duplex) [108038.43] eth0: link up (100Mbps/Half duplex) [108040.43] eth0: link up (100Mbps/Full duplex) [110398.43] eth0: link down [110399.43] eth0: link up (100Mbps/Full duplex) [111099.44] eth0: link down [00.44] eth0: link up (100Mbps/Full duplex) [111346.45] eth0: link down [111347.45] eth0: link up (100Mbps/Full duplex) [112683.49] eth0: link down [112684.49] eth0: link up (100Mbps/Full duplex) [114144.49] eth0: link down [114145.49] eth0: link up (100Mbps/Full duplex) [114827.49] eth0: link down [114828.49] eth0: link up (100Mbps/Full duplex) [115088.49] eth0: link down [115089.49] eth0: link up (100Mbps/Full duplex) [117515.55] eth0: link down [117516.55] eth0: link up (100Mbps/Full duplex) [118382.55] eth0: link up (10Mbps/Half duplex) [118384.55] eth0: link up (100Mbps/Full duplex) [118692.55] eth0: link down [118693.55] eth0: link up (100Mbps/Full duplex) [119435.56] eth0: link down [119436.56] eth0: link up (100Mbps/Full duplex) [120340.60] eth0: link down [120341.60] eth0: link up (100Mbps/Full duplex) [123993.65] eth0: link down [123994.65] eth0: link up (100Mbps/Full duplex)
Re: [OpenWrt-Devel] lantiq DSL drivers / firmware info
W dniu 2015-05-04 o 21:13, Johannes Berg pisze: On Mon, 2015-05-04 at 21:00 +0200, Martin Blumenstingl wrote: Like I previously said: there's probably something wrong at my end. I have the Annex A version of the TD-W8970 and I am trying to use it with my Annex B ADSL connection (for the record: I am not using a splitter). While trying to connect the dsl_cpe_control tool reports: Wrong combination of DSL PHY Firmware and hybrid type used! Please change one of it. I've never seen that, but which firmware are you using? I'd been using the speedport 1.21 (e1ef690e8dc0075468d4b6ba7bcdd0fc710bc671) one IIRC. So either my configuration is still incorrect or the modem is somehow (probably a hardware configuration, maybe via a resistor) configured to enforce a different hybrid or Annex type (this is pure speculation though). Are you on VDSL Annex B, where you'd fall back to ADSL 16/1 when vectoring isn't supported? If so, this configuration should work: config vdsl 'dsl' option annex 'b' option firmware '/lib/firmware/vdsl.bin' option tone 'b' option xfer_mode 'ptm' (actually I think you can/should remove the annex line) On my previous ISP I was on Annex A, but I don't have the right configuration right now. Note that the system seems to be too slow for 100 Mbps though, so this is somewhat academic, it can't do 100 Mbps NAT in my tests. I'm probably going to replace it with something faster and leave VDSL to a separate modem. I am interested in your test results, even though it's purely academic :-). First I'm going to replace this router with one that's faster, and then I'll start playing with this :-) Right now I need it to have internet connectivity. Someone else has tested the new driver in the meantime (using Annex A, no VDSL): [0] It seems that the modem syncs and is even able to connect (as far as I understand with some manual steps), but after a few minutes the connection drops. Interesting. I don't think I ever saw any connection dropouts ever. OTOH, I occasionally had the whole system spontaneously wedge itself and require a power cycle, so ... johannes No dropouts, system flooded with: [ 456.056000] DSL[00]: negative response for MsgID=0x2B0A (Class=0x3100) - on try 0! [ 456.764000] DSL[00]: Error for send CMD MsgID=0x2B0A - KEEP line! [ 456.768000] DSL[00]: ERROR - ReTx PM counters read failed! [ 457.032000] MEI_DRV[00 - 01]: ReadAck[0x2B0A] - FctOP ERROR 0x31! and after about 20-30 min hangs, after disabling ReTx at build system stays online for at least 6 hours (didn't test further) with some warnings repeating every two seconds: [ 458.772000] DSL[00]: WARNING - Data Path counters are not supported for the FE! vectoring and ReTx works acording to friend but system log shows some errors as well like on my ADSL line but not so many. On ADSL and also on VDSL with never firmware and errors/warnings appearing in log, system is under quite big load, compared to stock drivers. Probably we need dsl_control script to be reworked, as new features aren't present in it and stock/default config isn't the best. Regards ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Device tree issues with TL-WDR4900 (mpc85xx) and kernel 4.0.1
I tried to make the TL-WDR4900 work under kernel 4.0.
Adjusting the platform-specific patches was quickly done and the system boots.
However I get the following error messages.
[2.959975] /leds/system: could not get #gpio-cells for
/soc@ffe0/gpio-controller@f000
[2.968276] leds-gpio: probe of leds failed with error -22
[ 34.622909] /buttons/reset: could not get #gpio-cells for
/soc@ffe0/gpio-controller@f000
[ 34.631383] gpio-keys buttons: Failed to get gpio flags, error: -22
[ 34.637657] gpio-keys: probe of buttons failed with error -22
I'm not a device tree expert, what I checked so far:
The gpio-related section in tl-wdr4900-v1.dts is empty
gpio0: gpio-controller@f000 {
};
However #gpio-cells is defined in fsl/pq3-gpio-0.dtsi and this file is imported
by fsl/p1010si-post.dtsi.
And fsl/p1010si-post.dtsi is imported by tl-wdr4900-v1.dts.
This worked under 3.19 (despite the fact that 3.19 was never officially
supported for this device),
seems like something with the DT handling has changed in 4.0.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [Patch V2 2/2] ipq806x: add support for zImage kernel
This change enable zImage+appended dtb support in ipq806x kernel options. The zImage will now be generated as part of the kernel binaries. Platforms which do not have DT support enabled in U-boot can now make use of it by generating zImage files and appending dtb to it. It is not used yet but it is done as a stepping stone for early IPQ806x platforms, which did not include DT support in U-boot. Signed-off-by: Mathieu Olivari math...@codeaurora.org --- Notes: v2: Addressing jogo comments about DTB compat. Current platforms set the console bootargs to an incorrect value in the bootloader. So we'll disable these options in order to get them from the chosen node and have a kernel boot 100% isolated from the bootloader. We also disable CONFIG_ATAGS, as we don't need it. Disables the following configs: *CONFIG_ARM_ATAG_DTB_COMPAT *CONFIG_ATAGS target/linux/ipq806x/Makefile| 2 +- target/linux/ipq806x/config-3.18 | 3 ++- target/linux/ipq806x/config-4.0 | 3 ++- 3 files changed, 5 insertions(+), 3 deletions(-) diff --git a/target/linux/ipq806x/Makefile b/target/linux/ipq806x/Makefile index 1512b30..f97db74 100644 --- a/target/linux/ipq806x/Makefile +++ b/target/linux/ipq806x/Makefile @@ -11,7 +11,7 @@ MAINTAINER:=John Crispin blo...@openwrt.org KERNEL_PATCHVER:=3.18 -KERNELNAME:=Image dtbs +KERNELNAME:=zImage Image dtbs include $(INCLUDE_DIR)/target.mk DEFAULT_PACKAGES += \ diff --git a/target/linux/ipq806x/config-3.18 b/target/linux/ipq806x/config-3.18 index 8de4cb4..48a7374 100644 --- a/target/linux/ipq806x/config-3.18 +++ b/target/linux/ipq806x/config-3.18 @@ -33,8 +33,10 @@ CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y CONFIG_ARM=y CONFIG_ARM_AMBA=y +CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ARCH_TIMER=y CONFIG_ARM_ARCH_TIMER_EVTSTREAM=y +# CONFIG_ARM_ATAG_DTB_COMPAT is not set CONFIG_ARM_CPU_SUSPEND=y CONFIG_ARM_GIC=y CONFIG_ARM_HAS_SG_CHAIN=y @@ -48,7 +50,6 @@ CONFIG_ARM_THUMB=y CONFIG_ARM_UNWIND=y CONFIG_ARM_VIRT_EXT=y CONFIG_AT803X_PHY=y -CONFIG_AUTO_ZRELADDR=y # CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0 CONFIG_BOUNCE=y diff --git a/target/linux/ipq806x/config-4.0 b/target/linux/ipq806x/config-4.0 index c7bbcd9..9d8ff65 100644 --- a/target/linux/ipq806x/config-4.0 +++ b/target/linux/ipq806x/config-4.0 @@ -34,8 +34,10 @@ CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y CONFIG_ARM=y CONFIG_ARM_AMBA=y +CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ARCH_TIMER=y CONFIG_ARM_ARCH_TIMER_EVTSTREAM=y +# CONFIG_ARM_ATAG_DTB_COMPAT is not set CONFIG_ARM_CPU_SUSPEND=y CONFIG_ARM_GIC=y CONFIG_ARM_HAS_SG_CHAIN=y @@ -50,7 +52,6 @@ CONFIG_ARM_THUMB=y CONFIG_ARM_UNWIND=y CONFIG_ARM_VIRT_EXT=y CONFIG_AT803X_PHY=y -CONFIG_AUTO_ZRELADDR=y # CONFIG_BATTERY_GAUGE_LTC2941 is not set # CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0 -- 2.1.4 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
