Re: [OpenWrt-Devel] Cross Libtool
Hello Drasko, On Wednesday 14 November 2012 00:38:08 Drasko DRASKOVIC wrote: Hi all, Trying to cross compile libdespotify, I have run into problem with libtool : libtool --tag=CC --verbose --mode=link mipsel-openwrt-linux-uclibc-gcc -o libdespotify.la -rpath /usr/lib -rpath-link /home/drasko/carambola/carambola/staging_dir/target-mipsel_r2_uClibc-0.9.33.2/usr/lib -L/home/drasko/carambola/carambola/staging_dir/target-mipsel_r2_uClibc-0.9.33.2/lib -L/home/drasko/carambola/carambola/staging_dir/target-mipsel_r2_uClibc-0.9.33.2/usr/lib -lz -lvorbisfile -lcrypto -lresolv -lpthread aes.lo auth.lo buf.lo cache.lo channel.lo commands.lo dns.lo ezxml.lo handlers.lo keyexchange.lo packet.lo puzzle.lo session.lo shn.lo sndqueue.lo util.lo network.lo despotify.lo sha1.lo hmac.lo xml.lo OpenWrt-libtool: link: gcc -shared -fPIC -DPIC .libs/aes.o .libs/auth.o .libs/buf.o .libs/cache.o .libs/channel.o .libs/commands.o .libs/dns.o .libs/ezxml.o .libs/handlers.o .libs/keyexchange.o .libs/packet.o .libs/puzzle.o .libs/session.o .libs/shn.o .libs/sndqueue.o .libs/util.o .libs/network.o .libs/despotify.o .libs/sha1.o .libs/hmac.o .libs/xml.o -L/home/drasko/carambola/carambola/staging_dir/target-mipsel_r2_uClibc-0.9.33.2/lib -L/home/drasko/carambola/carambola/staging_dir/target-mipsel_r2_uClibc-0.9.33.2/usr/lib -lz -lvorbisfile -lcrypto -lresolv -lpthread-Wl,-soname -Wl,libdespotify.so.0 -o .libs/libdespotify.so.0.0.0 /usr/bin/ld.bfd.real: .libs/aes.o: Relocations in generic ELF (EM: 8) /usr/bin/ld.bfd.real: .libs/aes.o: Relocations in generic ELF (EM: 8) /usr/bin/ld.bfd.real: .libs/aes.o: Relocations in generic ELF (EM: 8) /usr/bin/ld.bfd.real: .libs/aes.o: Relocations in generic ELF (EM: 8) /usr/bin/ld.bfd.real: .libs/aes.o: Relocations in generic ELF (EM: 8) /usr/bin/ld.bfd.real: .libs/aes.o: Relocations in generic ELF (EM: 8) .libs/aes.o: could not read symbols: File in wrong format collect2: ld returned 1 exit status make[3]: *** [libdespotify.la] Error 1 Instead of cross-compiler, libtool calls native gcc in the link mode (in the compile mode everything OK, though). I see several issues with this log excerpt: - the first libtool link command uses /usr/lib as a host path (second line) this needs fixing - the second libtool command does not use the cross-linker, and for that I have no idea yet This problem is described here : http://www.metastatic.org/text/libtool.html I have two questions at this point : 1) I sew that OpenWRT buildsystem uses staging_dir/host/bin/libtool. If this (host) libtool is normally used for building packages and not cross compiled libtool, did I do something wrong in my Makefile? The compiled libtool resides in host because it is actually compiled for the host system, there is no other libtool executable in the build system besides those copies provided by other packages we build. 2) If some other, cross-compiled libtool should be used, where can I find it? I do not see it in the toolchain directory. However, I can see many different libtools, si I was wondering why we need so many and how are they different : drasko@Marx:~/carambola/carambola$ find . -name libtool ./tools/libtool ./build_dir/linux-ramips_rt305x/opkg-618/libtool ./build_dir/linux-ramips_rt305x/iptables-1.4.10/libtool ./build_dir/target-mipsel_r2_uClibc-0.9.33.2/libao-1.1.0/libtool ./build_dir/target-mipsel_r2_uClibc-0.9.33.2/libvorbis-1.2.3/libtool ./build_dir/target-mipsel_r2_uClibc-0.9.33.2/liblo-0.26/libtool ./build_dir/target-mipsel_r2_uClibc-0.9.33.2/alsa-lib-1.0.24.1/libtool ./build_dir/target-mipsel_r2_uClibc-0.9.33.2/libogg-1.1.4/libtool ./build_dir/target-mipsel_r2_uClibc-0.9.33.2/json-c-0.9/libtool ./build_dir/target-mipsel_r2_uClibc-0.9.33.2/udev-173/libtool ./build_dir/host/gmp-5.0.5/libtool ./build_dir/host/libtool-2.4/libtool ./build_dir/host/pkg-config-0.25/glib-1.2.10/libtool ./build_dir/host/pkg-config-0.25/libtool ./build_dir/host/opkg-618/libtool ./build_dir/host/mpc-0.9/libtool ./build_dir/host/xz-5.0.3/libtool ./build_dir/host/mpfr-3.0.0/libtool ./build_dir/toolchain-mipsel_r2_gcc-4.7-linaro_uClibc-0.9.33.2/binutils-2.22/opcodes/libtool ./build_dir/toolchain-mipsel_r2_gcc-4.7-linaro_uClibc-0.9.33.2/binutils-2.22/ld/libtool ./build_dir/toolchain-mipsel_r2_gcc-4.7-linaro_uClibc-0.9.33.2/binutils-2.22/gas/libtool ./build_dir/toolchain-mipsel_r2_gcc-4.7-linaro_uClibc-0.9.33.2/binutils-2.22/binutils/libtool ./build_dir/toolchain-mipsel_r2_gcc-4.7-linaro_uClibc-0.9.33.2/binutils-2.22/bfd/libtool ./build_dir/toolchain-mipsel_r2_gcc-4.7-linaro_uClibc-0.9.33.2/binutils-2.22/gprof/libtool ./build_dir/toolchain-mipsel_r2_gcc-4.7-linaro_uClibc-0.9.33.2/gcc-linaro-4.7-2012.04-final/lto-plugin/libtool ./build_dir/toolchain-mipsel_r2_gcc-4.7-linaro_uClibc-0.9.33.2/gcc-linaro-4.7-2012.04-final/zlib/libtool
Re: [OpenWrt-Devel] Cross Libtool
Hi Florian, On Wed, Nov 14, 2012 at 10:22 AM, Florian Fainelli flor...@openwrt.org wrote: Hello Drasko, On Wednesday 14 November 2012 00:38:08 Drasko DRASKOVIC wrote: Hi all, Trying to cross compile libdespotify, I have run into problem with libtool : libtool --tag=CC --verbose --mode=link mipsel-openwrt-linux-uclibc-gcc -o libdespotify.la -rpath /usr/lib -rpath-link /home/drasko/carambola/carambola/staging_dir/target-mipsel_r2_uClibc-0.9.33.2/usr/lib -L/home/drasko/carambola/carambola/staging_dir/target-mipsel_r2_uClibc-0.9.33.2/lib -L/home/drasko/carambola/carambola/staging_dir/target-mipsel_r2_uClibc-0.9.33.2/usr/lib -lz -lvorbisfile -lcrypto -lresolv -lpthread aes.lo auth.lo buf.lo cache.lo channel.lo commands.lo dns.lo ezxml.lo handlers.lo keyexchange.lo packet.lo puzzle.lo session.lo shn.lo sndqueue.lo util.lo network.lo despotify.lo sha1.lo hmac.lo xml.lo OpenWrt-libtool: link: gcc -shared -fPIC -DPIC .libs/aes.o .libs/auth.o .libs/buf.o .libs/cache.o .libs/channel.o .libs/commands.o .libs/dns.o .libs/ezxml.o .libs/handlers.o .libs/keyexchange.o .libs/packet.o .libs/puzzle.o .libs/session.o .libs/shn.o .libs/sndqueue.o .libs/util.o .libs/network.o .libs/despotify.o .libs/sha1.o .libs/hmac.o .libs/xml.o -L/home/drasko/carambola/carambola/staging_dir/target-mipsel_r2_uClibc-0.9.33.2/lib -L/home/drasko/carambola/carambola/staging_dir/target-mipsel_r2_uClibc-0.9.33.2/usr/lib -lz -lvorbisfile -lcrypto -lresolv -lpthread-Wl,-soname -Wl,libdespotify.so.0 -o .libs/libdespotify.so.0.0.0 /usr/bin/ld.bfd.real: .libs/aes.o: Relocations in generic ELF (EM: 8) /usr/bin/ld.bfd.real: .libs/aes.o: Relocations in generic ELF (EM: 8) /usr/bin/ld.bfd.real: .libs/aes.o: Relocations in generic ELF (EM: 8) /usr/bin/ld.bfd.real: .libs/aes.o: Relocations in generic ELF (EM: 8) /usr/bin/ld.bfd.real: .libs/aes.o: Relocations in generic ELF (EM: 8) /usr/bin/ld.bfd.real: .libs/aes.o: Relocations in generic ELF (EM: 8) .libs/aes.o: could not read symbols: File in wrong format collect2: ld returned 1 exit status make[3]: *** [libdespotify.la] Error 1 Instead of cross-compiler, libtool calls native gcc in the link mode (in the compile mode everything OK, though). I see several issues with this log excerpt: - the first libtool link command uses /usr/lib as a host path (second line) this needs fixing I have passes -rpath as /usr/lib, as this should be the place where this library will reside in the system. However, -rpath-link points to staging_dir/target-mipsel_r2_uClibc-0.9.33.2/usr/lib, where other libraries needed for linking should be found. If this is not the correct procedure, where -rpath should point to? And -rpath-link? - the second libtool command does not use the cross-linker, and for that I have no idea yet It does not, and it is related to the bug (or wrong params) in the libtool described here : http://www.metastatic.org/text/libtool.html --tag=CC can be passed to libtool, and then it uses mipsel-openwrt-linux-uclibc-gcc for compilatin, which is correct. However, in the link stage with same --tag=CC passed, it switches to the native gcc which is wrong and provokes errors. Solution here is either to correct libtool or use cross libtool, I think, but I am not quite sure. It sounds strange to me that I am the first person in the world who cross compiles libraries with libtool on OpenWRT... This problem is described here : http://www.metastatic.org/text/libtool.html I have two questions at this point : 1) I sew that OpenWRT buildsystem uses staging_dir/host/bin/libtool. If this (host) libtool is normally used for building packages and not cross compiled libtool, did I do something wrong in my Makefile? The compiled libtool resides in host because it is actually compiled for the host system, there is no other libtool executable in the build system besides those copies provided by other packages we build. So, if I undersand correctly, each package provides it's own libtool ? Maybe some of these libtools are cross-compiled during package cross-compilation. However, it would be not a good practice to use libtool of some other package... Is it the mandatory for every package that should use libtool to provide it's own libtool ? BR, Drasko ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Cross Libtool
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, in most cases it is enough to specify PKG_FIXUP:=autoreconf in the OpenWrt Makefile. This will regenerate configure scripts, Makefiles and embedded libtool copies with patched variants. ~ Jow -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCjc8QACgkQdputYINPTPOE5gCfQUTbBZR/FCQGUZOFRnRVUSBl va4AnitEOcE+pzhBVwv9hAblGD4Xqzxp =sWm3 -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 4/5] ar93x: Add option to disable JTAG, which blocks a GPIO
Hi Daniel, The ath79_gpio_function_* routines should be fixed instead of adding a separate function for AR934x. I will fix those. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Cross Libtool
On Wednesday 14 November 2012 11:24:10 Drasko DRASKOVIC wrote: Hi Florian, On Wed, Nov 14, 2012 at 10:22 AM, Florian Fainelli flor...@openwrt.org wrote: Hello Drasko, On Wednesday 14 November 2012 00:38:08 Drasko DRASKOVIC wrote: Hi all, Trying to cross compile libdespotify, I have run into problem with libtool : libtool --tag=CC --verbose --mode=link mipsel-openwrt-linux-uclibc-gcc -o libdespotify.la -rpath /usr/lib -rpath-link /home/drasko/carambola/carambola/staging_dir/target-mipsel_r2_uClibc-0.9.33.2/usr/lib -L/home/drasko/carambola/carambola/staging_dir/target-mipsel_r2_uClibc-0.9.33.2/lib -L/home/drasko/carambola/carambola/staging_dir/target-mipsel_r2_uClibc-0.9.33.2/usr/lib -lz -lvorbisfile -lcrypto -lresolv -lpthread aes.lo auth.lo buf.lo cache.lo channel.lo commands.lo dns.lo ezxml.lo handlers.lo keyexchange.lo packet.lo puzzle.lo session.lo shn.lo sndqueue.lo util.lo network.lo despotify.lo sha1.lo hmac.lo xml.lo OpenWrt-libtool: link: gcc -shared -fPIC -DPIC .libs/aes.o .libs/auth.o .libs/buf.o .libs/cache.o .libs/channel.o .libs/commands.o .libs/dns.o .libs/ezxml.o .libs/handlers.o .libs/keyexchange.o .libs/packet.o .libs/puzzle.o .libs/session.o .libs/shn.o .libs/sndqueue.o .libs/util.o .libs/network.o .libs/despotify.o .libs/sha1.o .libs/hmac.o .libs/xml.o -L/home/drasko/carambola/carambola/staging_dir/target-mipsel_r2_uClibc-0.9.33.2/lib -L/home/drasko/carambola/carambola/staging_dir/target-mipsel_r2_uClibc-0.9.33.2/usr/lib -lz -lvorbisfile -lcrypto -lresolv -lpthread-Wl,-soname -Wl,libdespotify.so.0 -o .libs/libdespotify.so.0.0.0 /usr/bin/ld.bfd.real: .libs/aes.o: Relocations in generic ELF (EM: 8) /usr/bin/ld.bfd.real: .libs/aes.o: Relocations in generic ELF (EM: 8) /usr/bin/ld.bfd.real: .libs/aes.o: Relocations in generic ELF (EM: 8) /usr/bin/ld.bfd.real: .libs/aes.o: Relocations in generic ELF (EM: 8) /usr/bin/ld.bfd.real: .libs/aes.o: Relocations in generic ELF (EM: 8) /usr/bin/ld.bfd.real: .libs/aes.o: Relocations in generic ELF (EM: 8) .libs/aes.o: could not read symbols: File in wrong format collect2: ld returned 1 exit status make[3]: *** [libdespotify.la] Error 1 Instead of cross-compiler, libtool calls native gcc in the link mode (in the compile mode everything OK, though). I see several issues with this log excerpt: - the first libtool link command uses /usr/lib as a host path (second line) this needs fixing I have passes -rpath as /usr/lib, as this should be the place where this library will reside in the system. However, -rpath-link points to staging_dir/target-mipsel_r2_uClibc-0.9.33.2/usr/lib, where other libraries needed for linking should be found. Ok, I did not understand you added that. If this is not the correct procedure, where -rpath should point to? And -rpath-link? - the second libtool command does not use the cross-linker, and for that I have no idea yet It does not, and it is related to the bug (or wrong params) in the libtool described here : http://www.metastatic.org/text/libtool.html --tag=CC can be passed to libtool, and then it uses mipsel-openwrt-linux-uclibc-gcc for compilatin, which is correct. However, in the link stage with same --tag=CC passed, it switches to the native gcc which is wrong and provokes errors. Should not you use --tag=LD then? I agree that it should work anyway. Solution here is either to correct libtool or use cross libtool, I think, but I am not quite sure. It sounds strange to me that I am the first person in the world who cross compiles libraries with libtool on OpenWRT... There is no such thing as a cross-libtool, as it does not make sense, a cross libtool would mean a libtool that gets compiled for your target platform, but executed on the build platform? That does not fly. This problem is described here : http://www.metastatic.org/text/libtool.html I have two questions at this point : 1) I sew that OpenWRT buildsystem uses staging_dir/host/bin/libtool. If this (host) libtool is normally used for building packages and not cross compiled libtool, did I do something wrong in my Makefile? The compiled libtool resides in host because it is actually compiled for the host system, there is no other libtool executable in the build system besides those copies provided by other packages we build. So, if I undersand correctly, each package provides it's own libtool ? Most do, which is the reason why we build our own copy and instruct the OpenWrt build system to use our own libtool copy to make sure everything goes smoothly. Maybe some of these libtools are cross-compiled during package cross-compilation. However, it would be not a good practice to use libtool of some other package... Is it the mandatory for every package that should use libtool to provide it's own libtool ? No, but packages that do provide a libtool should be built by OpenWrt with
Re: [OpenWrt-Devel] Cross Libtool
Hi Jow, On Wed, Nov 14, 2012 at 11:34 AM, Jo-Philipp Wich x...@subsignal.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, in most cases it is enough to specify PKG_FIXUP:=autoreconf in the OpenWrt Makefile. This will regenerate configure scripts, Makefiles and embedded libtool copies with patched variants. I did not provide embedded libtool. I thought that one present in the OpenWRT can be used, passing --tag=CC as a parameter. It turns out that it is buggy on the link stage (as I described). Does this means that every package __HAS__ to provide embedded libtool ? BR, Drasko ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Cross Libtool
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It works for any other package so it is unlikely to be buggy on the link stage. It is most likely improperly called by the Makefile. And indeed, line 11 of despotify's Makefile says: LD = $(CC) That is the most likely culprit. ~ Jow -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCje7UACgkQdputYINPTPN5YgCfbomEFrqSvvs0DWiisRb90jkB MwMAoI7fBoaLnf7+eCpdWSjeM1PcUIiC =ZbM9 -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Cross Libtool
On Wed, Nov 14, 2012 at 11:36 AM, Florian Fainelli flor...@openwrt.org wrote: On Wednesday 14 November 2012 11:24:10 Drasko DRASKOVIC wrote: - the second libtool command does not use the cross-linker, and for that I have no idea yet It does not, and it is related to the bug (or wrong params) in the libtool described here : http://www.metastatic.org/text/libtool.html --tag=CC can be passed to libtool, and then it uses mipsel-openwrt-linux-uclibc-gcc for compilatin, which is correct. However, in the link stage with same --tag=CC passed, it switches to the native gcc which is wrong and provokes errors. Should not you use --tag=LD then? I agree that it should work anyway. No, this tag is not recognized by libtool (my idea exactly, unfortunately it ignores it as an unknown tag). Solution here is either to correct libtool or use cross libtool, I think, but I am not quite sure. It sounds strange to me that I am the first person in the world who cross compiles libraries with libtool on OpenWRT... There is no such thing as a cross-libtool, as it does not make sense, a cross libtool would mean a libtool that gets compiled for your target platform, but executed on the build platform? That does not fly. Well, cross-libtool sort-of, this is what I wanted to say. libtool is just a shell script (10k lines long horror), but it can be configured for the target like this : ./configure --prefix=/opt/Toolchain --host=target --program-prefix=target- Please refer to the link http://www.metastatic.org/text/libtool.html, section The wrong-gcc problem. I do not know what this configure does, but I guess it changes some internal variables inside libtool, so it changes the way it constructs it's compilation command. Libtool provided by OpenWRT is the one for the host. Libtools provided by packages are in my opinion configured and make-d during the package cross-compilation, thus they work well with the target code. What OpenWRT is missing is cross-compiled libtool that should be somewhere in the toolchain (binutils?) directory, that I can use, instead of cross-making libtool for every package. even worse, libtool has to be pached in order to change it's internal libdir variable (link http://www.metastatic.org/text/libtool.html, first section). This is done in OpenWRT by libtool patch for the host libtool, but is this done for every libtool provided with the package? I seriously doubt. Maybe this patching could be configured with PKG_FIXUP:=autoreconf, as suggested before, but this is another problem. Primary problem for now is cross-compiler call, and does every package has to provide it's own libtool. BR, Drasko ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 5/5] Add support for three PowerCloud devices
Hi Daniel, Please split this patch into smaller pieces, as I did that with your UniFi AP patch. More comments inline... Signed-off-by: Daniel Dickinson dan...@powercloudsystems.com --- target/linux/ar71xx/base-files/etc/diag.sh |6 + .../ar71xx/base-files/etc/uci-defaults/network | 11 + target/linux/ar71xx/base-files/lib/ar71xx.sh |6 + .../ar71xx/base-files/lib/upgrade/platform.sh |2 + target/linux/ar71xx/config-3.3 |1 + target/linux/ar71xx/config-3.6 |1 + target/linux/ar71xx/generic/profiles/pcs.mk| 32 +++ target/linux/ar71xx/image/Makefile |4 + .../patches-3.3/690-MIPS-ath79-pcs-cr5000.patch| 278 .../patches-3.3/700-MIPS-ath79-pcs-cap324.patch| 173 .../patches-3.6/690-MIPS-ath79-pcs-cr5000.patch| 278 .../patches-3.6/700-MIPS-ath79-pcs-cap324.patch| 173 12 files changed, 965 insertions(+) create mode 100644 target/linux/ar71xx/patches-3.3/690-MIPS-ath79-pcs-cr5000.patch create mode 100644 target/linux/ar71xx/patches-3.3/700-MIPS-ath79-pcs-cap324.patch create mode 100644 target/linux/ar71xx/patches-3.6/690-MIPS-ath79-pcs-cr5000.patch create mode 100644 target/linux/ar71xx/patches-3.6/700-MIPS-ath79-pcs-cap324.patch ... diff --git a/target/linux/ar71xx/generic/profiles/pcs.mk b/target/linux/ar71xx/generic/profiles/pcs.mk index eaf9699..5b3e260 100644 --- a/target/linux/ar71xx/generic/profiles/pcs.mk +++ b/target/linux/ar71xx/generic/profiles/pcs.mk @@ -17,6 +17,17 @@ endef $(eval $(call Profile,UBDEV01)) +define Profile/UBDEVOD + NAME:=PCS ubdevod model Please use 'PowerCloud Systems' instead of 'PCS' in profile names/descriptions as Felix suggested for the other patch. ... diff --git a/target/linux/ar71xx/image/Makefile b/target/linux/ar71xx/image/Makefile index 9678d66..27f3daa 100644 --- a/target/linux/ar71xx/image/Makefile +++ b/target/linux/ar71xx/image/Makefile @@ -171,6 +171,8 @@ cameo913x_mtdlayout=mtdparts=spi0.0:128k(u-boot)ro,64k(config)ro,960k(kernel),28 cameo933x_mtdlayout=mtdparts=spi0.0:64k(u-boot)ro,64k(art)ro,64k(mac)ro,64k(nvram)ro,192k(language)ro,896k(kernel),2752k(rootfs),3648k@0x7(firmware) cap4200ag_mtdlayout=mtdparts=spi0.0:256k(u-boot),64k(u-boot-env),320k(custom)ro,1536k(kernel),12096k(rootfs),2048k(failsafe),64k(art),13632k@0xa(firmware) db120_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,6336k(rootfs),1408k(kernel),64k(nvram),64k(art)ro,7744k@0x5(firmware) +cr5000_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,1408k(kernel),5696k(rootfs),640k(certs),64k(nvram),64k(art)ro,7104k@0x5(firmware) +cap324_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,1408k(kernel),13888k(rootfs),640k(certs),64k(nvram),64k(art)ro,15296k@0x5(firmware) Please keep these sorted alphabetically. dir825b1_mtdlayout=mtdparts=spi0.0:256k(uboot)ro,64k(config)ro,1024k(kernel),5184k(rootfs),64k(caldata)ro,1600k(unknown)ro,6208k@0x5(firmware),64k@0x7f(caldata_copy) dir825b1_mtdlayout_fat=mtdparts=spi0.0:256k(uboot)ro,64k(config)ro,1024k(kernel),6784k(rootfs),64k(caldata)ro,7808k@0x5(firmware),64k@0x66(caldata_orig),6208k@0x5(firmware_orig) ew-dorin_mtdlayout_4M=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env),1024k(kernel),2688k(rootfs),64k(art),3712k@0x5(firmware) @@ -906,6 +908,8 @@ $(eval $(call SingleProfile,ZyXEL,$(fs_64k),NBG_460N_550N_550NH,nbg460n_550n_550 $(eval $(call SingleProfile,UBDEV,$(fs_64k),UBDEV01,ubdev01,UBNT-UF,ttyS0,115200,XM,XM,ar7240)) $(eval $(call SingleProfile,DLRTDEV,$(fs_64k),DLRTDEV01,dlrtdev01,DIR-825-B1,ttyS0,115200,01AP94-AR7161-RT-080619-00,00AP94-AR7161-RT-080619-00)) +$(eval $(call SingleProfile,UBDEV,$(fs_64k),UBDEVOD,ubdevod,UBNT-U20,ttyS0,115200,XM,XM,ar7240)) +$(eval $(call SingleProfile,AthLzma,$(fs_64k),CR5000,cr5000,CR5000,ttyS0,115200,$$(cr5000_mtdlayout),1441792,5832484,KRuImage)) Keep these sorted as well. $(eval $(call MultiProfile,AP121,AP121_2M AP121_4M)) $(eval $(call MultiProfile,EWDORIN, EWDORINAP EWDORINRT)) diff --git a/target/linux/ar71xx/patches-3.3/690-MIPS-ath79-pcs-cr5000.patch b/target/linux/ar71xx/patches-3.3/690-MIPS-ath79-pcs-cr5000.patch new file mode 100644 index 000..84dcac6 --- /dev/null +++ b/target/linux/ar71xx/patches-3.3/690-MIPS-ath79-pcs-cr5000.patch Use the 611-620 range for the patch name. @@ -0,0 +1,278 @@ +Index: linux-3.3.8/arch/mips/ath79/Kconfig +=== +--- linux-3.3.8.orig/arch/mips/ath79/Kconfig 2012-11-01 22:04:55.0 -0400 linux-3.3.8/arch/mips/ath79/Kconfig 2012-11-01 23:19:57.125271409 -0400 +@@ -127,6 +127,20 @@ + help + Say 'Y' here if you want your kernel to support the + Atheros DB120
Re: [OpenWrt-Devel] [PATCH 1/2 v3] mac80211/rt2x00: support Rt3352 with external PA
Hi, Daniel!
Just one line is skipped:
rt2x00_eeprom_read(rt2x00dev, EEPROM_NIC_CONF1, eeprom);
before bit test :). After fixing wifi work again.
13.11.2012, 18:20, Daniel Golle dgo...@allnet.de:
This is needed for WiFi to work e.g. on DIR-615 rev.H1.
Signed-off-by: Daniel Golle dgo...@allnet.de
create mode 100644
package/mac80211/patches/622-rt2x00-fix-rt3352-ext-pa.patch
diff --git a/package/mac80211/patches/622-rt2x00-fix-rt3352-ext-pa.patch
b/package/mac80211/patches/622-rt2x00-fix-rt3352-ext-pa.patch
new file mode 100644
index 000..ab4f7b3
--- /dev/null
+++ b/package/mac80211/patches/622-rt2x00-fix-rt3352-ext-pa.patch
@@ -0,0 +1,207 @@
+--- a/drivers/net/wireless/rt2x00/rt2800lib.c
b/drivers/net/wireless/rt2x00/rt2800lib.c
+@@ -2271,15 +2271,18 @@ static void rt2800_config_channel(struct
+ /*
+ * Change BBP settings
+ */
++ rt2800_bbp_write(rt2x00dev, 62, 0x37 - rt2x00dev-lna_gain);
++ rt2800_bbp_write(rt2x00dev, 63, 0x37 - rt2x00dev-lna_gain);
++ rt2800_bbp_write(rt2x00dev, 64, 0x37 - rt2x00dev-lna_gain);
++
+ if (rt2x00_rt(rt2x00dev, RT3352)) {
+ rt2800_bbp_write(rt2x00dev, 27, 0x0);
+ rt2800_bbp_write(rt2x00dev, 66, 0x26 + rt2x00dev-lna_gain);
+ rt2800_bbp_write(rt2x00dev, 27, 0x20);
+ rt2800_bbp_write(rt2x00dev, 66, 0x26 + rt2x00dev-lna_gain);
++ rt2800_bbp_write(rt2x00dev, 86, 0x38);
++ rt2800_bbp_write(rt2x00dev, 83, 0x6a);
+ } else {
+- rt2800_bbp_write(rt2x00dev, 62, 0x37 - rt2x00dev-lna_gain);
+- rt2800_bbp_write(rt2x00dev, 63, 0x37 - rt2x00dev-lna_gain);
+- rt2800_bbp_write(rt2x00dev, 64, 0x37 - rt2x00dev-lna_gain);
+ rt2800_bbp_write(rt2x00dev, 86, 0);
+ }
+
+@@ -3850,6 +3853,7 @@ static int rt2800_init_rfcsr(struct rt2x
+ * Init RF calibration.
+ */
+ if (rt2x00_rt(rt2x00dev, RT3290) ||
++ rt2x00_rt(rt2x00dev, RT3352) ||
+ rt2x00_rt(rt2x00dev, RT5390) ||
+ rt2x00_rt(rt2x00dev, RT5392)) {
+ rt2800_rfcsr_read(rt2x00dev, 2, rfcsr);
+@@ -4036,6 +4040,10 @@ static int rt2800_init_rfcsr(struct rt2x
+ rt2800_rfcsr_write(rt2x00dev, 31, 0x00);
+ return 0;
+ } else if (rt2x00_rt(rt2x00dev, RT3352)) {
++ int tx0_int_pa = test_bit(CAPABILITY_INTERNAL_PA_TX0,
++ rt2x00dev-cap_flags);
++ int tx1_int_pa = test_bit(CAPABILITY_INTERNAL_PA_TX1,
++ rt2x00dev-cap_flags);
+ rt2800_rfcsr_write(rt2x00dev, 0, 0xf0);
+ rt2800_rfcsr_write(rt2x00dev, 1, 0x23);
+ rt2800_rfcsr_write(rt2x00dev, 2, 0x50);
+@@ -4069,15 +4077,30 @@ static int rt2800_init_rfcsr(struct rt2x
+ rt2800_rfcsr_write(rt2x00dev, 31, 0x80);
+ rt2800_rfcsr_write(rt2x00dev, 32, 0x80);
+ rt2800_rfcsr_write(rt2x00dev, 33, 0x00);
+- rt2800_rfcsr_write(rt2x00dev, 34, 0x01);
++ rfcsr = 0x01;
++ if (!tx0_int_pa)
++ rt2x00_set_field8(rfcsr, RFCSR34_TX0_EXT_PA, 1);
++ if (!tx1_int_pa)
++ rt2x00_set_field8(rfcsr, RFCSR34_TX1_EXT_PA, 1);
++ rt2800_rfcsr_write(rt2x00dev, 34, rfcsr );
+ rt2800_rfcsr_write(rt2x00dev, 35, 0x03);
+ rt2800_rfcsr_write(rt2x00dev, 36, 0xbd);
+ rt2800_rfcsr_write(rt2x00dev, 37, 0x3c);
+ rt2800_rfcsr_write(rt2x00dev, 38, 0x5f);
+ rt2800_rfcsr_write(rt2x00dev, 39, 0xc5);
+ rt2800_rfcsr_write(rt2x00dev, 40, 0x33);
+- rt2800_rfcsr_write(rt2x00dev, 41, 0x5b);
+- rt2800_rfcsr_write(rt2x00dev, 42, 0x5b);
++ rfcsr = 0x52;
++ if (tx0_int_pa) {
++ rt2x00_set_field8(rfcsr, RFCSR41_BIT1, 1);
++ rt2x00_set_field8(rfcsr, RFCSR41_BIT4, 1);
++ }
++ rt2800_rfcsr_write(rt2x00dev, 41, rfcsr);
++ rfcsr = 0x52;
++ if (tx1_int_pa) {
++ rt2x00_set_field8(rfcsr, RFCSR42_BIT1, 1);
++ rt2x00_set_field8(rfcsr, RFCSR42_BIT4, 1);
++ }
++ rt2800_rfcsr_write(rt2x00dev, 42, rfcsr);
+ rt2800_rfcsr_write(rt2x00dev, 43, 0xdb);
+ rt2800_rfcsr_write(rt2x00dev, 44, 0xdb);
+ rt2800_rfcsr_write(rt2x00dev, 45, 0xdb);
+@@ -4085,15 +4108,20 @@ static int rt2800_init_rfcsr(struct rt2x
+ rt2800_rfcsr_write(rt2x00dev, 47, 0x0d);
+ rt2800_rfcsr_write(rt2x00dev, 48, 0x14);
+ rt2800_rfcsr_write(rt2x00dev, 49, 0x00);
+- rt2800_rfcsr_write(rt2x00dev, 50, 0x2d);
+- rt2800_rfcsr_write(rt2x00dev, 51, 0x7f);
+- rt2800_rfcsr_write(rt2x00dev, 52, 0x00);
+- rt2800_rfcsr_write(rt2x00dev, 53, 0x52);
+- rt2800_rfcsr_write(rt2x00dev, 54, 0x1b);
+- rt2800_rfcsr_write(rt2x00dev, 55, 0x7f);
+- rt2800_rfcsr_write(rt2x00dev, 56, 0x00);
+- rt2800_rfcsr_write(rt2x00dev, 57, 0x52);
+- rt2800_rfcsr_write(rt2x00dev, 58, 0x1b);
++ rfcsr = 0x2d;
++ if (!tx0_int_pa)
++ rt2x00_set_field8(rfcsr, RFCSR50_TX0_EXT_PA, 1);
++ if (!tx1_int_pa)
++ rt2x00_set_field8(rfcsr, RFCSR50_TX1_EXT_PA, 1);
++ rt2800_rfcsr_write(rt2x00dev, 50, rfcsr);
++ rt2800_rfcsr_write(rt2x00dev, 51, (tx0_int_pa ? 0x7f : 0x52));
++ rt2800_rfcsr_write(rt2x00dev, 52, (tx0_int_pa ? 0x00 : 0xc0));
++ rt2800_rfcsr_write(rt2x00dev, 53, (tx0_int_pa ? 0x52 : 0xd2));
++ rt2800_rfcsr_write(rt2x00dev, 54, (tx0_int_pa ? 0x1b : 0xc0));
++ rt2800_rfcsr_write(rt2x00dev, 55, (tx1_int_pa ? 0x7f : 0x52));
++ rt2800_rfcsr_write(rt2x00dev, 56, (tx1_int_pa ? 0x00 : 0xc0));
++ rt2800_rfcsr_write(rt2x00dev, 57, (tx0_int_pa
Re: [OpenWrt-Devel] Build issue with r34113
On Fri, 09 Nov 2012 21:32:03 +, Jim Henderson wrote: It seems the PREFIX/INSTALL_BASE message on the third line above is what's causing my issue. Looking at the makefiles, though, I can't see where it's picking up either value from. Can someone point me in the right direction to fix this? I've done a completely fresh checkout, preserving only my .config file. I noticed feeds.conf.default had a new luci URL in it, so I changed my feeds.conf file to reflect that new item, and manually updated the config for luci to enable the modules I had enabled in earlier compilations. The compile still failed at the same point, however. Disabling luci-app-statistics and collectd has gotten me past it for now (the compile is getting further but still running), but I'd like to be able to re-enable them since that's functionality I occasionally do use. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Power PC and the USB serial interface function for the FTDI type serial port?
I've looked into this further, and it seems that any Linux 3.X, for X = (3.3.8 (OpenWRT), 3.6 (x86)), has a problem. I compared the results with my x86 2.6.24, and amd64 2.6.32 and the ftdi_sio driver works in both of these versions. Looking at the USB transfers there are some differences, and I had to leave off to work on a couple of other projects. I'll have to come back to this, but it won't be till December or so. If anyone has better (same or worse...) experience with the fitdi_sio driver for the following: FTDI: FT232RL CPU: PowerPC or x86 Type device, I'd like to hear about it. The byte endian problem I believe is a 'red herring', as it appears to be only a cosmetic 'printout error', where the printout does not properly extract the number using le16_to_cpu function. John Clark. On Oct 31, 2012, at 12:00 PM, Andreas Mohr wrote: Hi, On Wed, Oct 31, 2012 at 12:00:01PM +0100, openwrt-devel-requ...@lists.openwrt.org wrote: Date: Tue, 30 Oct 2012 17:48:48 -0700 From: John Clark jeclark2...@aim.com Has anyone used OpenWRT Linux 3.3.8 kernel, and the included FTDI serial port interface driver with the Power PC. I suspect there are byte swapping issues, and would like to know if anyone else has 'used' the driver and 1) had no problem... or 2) had and fixed a problem. As an interested party, I had a quick look at current ftdi_sio.c history ( http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=history;f=drivers/usb/serial/ftdi_sio.c;h=be845873e23dba98fc306fecceb71a672a2c7d74;hb=HEAD ), and there doesn't seem to be much committed that's relevant. However, commit d1ab903d2552b2362339b19203c7f01c797cb316 Author: Michael Wileczka mikewilec...@yahoo.com Date: Wed Aug 18 07:14:37 2010 -0700 USB: ftdi_sio: fix endianess of max packet size The USB max packet size (always little-endian) was not being byte swapped on big-endian systems. Applicable since [USB: ftdi_sio: fix hi-speed device packet size calculation] approx 2.6.31 Signed-off-by: Michael Wileczka mikewilec...@yahoo.com Cc: stable sta...@kernel.org Signed-off-by: Greg Kroah-Hartman gre...@suse.de might be a good example of where to find and how to treat such issues. HTH, Andreas Mohr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [package] hostapd: updated dynamic vlan support
Confirmed operation today.
Acked-by: Jonathan Bitherjonbit...@gmail.com
On 11/13/2012 09:14 AM, Jonathan Bither wrote:
I use this feature often. I'll try to test this today and ack it if it
works for me.
On 10/16/2012 05:30 PM, Zenon Mousmoulas wrote:
This is based on the patches submitted by Matthew Bowman:
http://patchwork.openwrt.org/patch/1258/
http://patchwork.openwrt.org/patch/1261/
More recently hostapd has added support for setting the VLAN naming
scheme (eth0.11 vs. vlan11), in commit
a00237ceb8644fc270efd9fc0d0f8d0465db8410 upstream. So the updated patch
(620-dynamic_vlan-correct_bridge_interface_names.patch) only corrects
the bridge interface names (br-vlan11 vs. brvlan11).
Rather than shipping a default hostapd VLAN file, one is created at
runtime based on the wi-fi ifname.
Should this be accepted (hopefully!), I suppose the additional UCI
options would need to be documented; on the wiki? where else?
Signed-off-by: Zenon Mousmoulas zmo...@noc.grnet.gr
---
package/network/services/hostapd/files/hostapd.sh | 17
+
...namic_vlan-correct_bridge_interface_names.patch | 20
2 files changed, 37 insertions(+), 0 deletions(-)
create mode 100644
package/network/services/hostapd/patches/620-dynamic_vlan-correct_bridge_interface_names.patch
diff --git a/package/network/services/hostapd/files/hostapd.sh
b/package/network/services/hostapd/files/hostapd.sh
index d60c26f..a462fe2 100644
--- a/package/network/services/hostapd/files/hostapd.sh
+++ b/package/network/services/hostapd/files/hostapd.sh
@@ -2,6 +2,7 @@ hostapd_set_bss_options() {
local var=$1
local vif=$2
local enc wep_rekey wpa_group_rekey wpa_pair_rekey
wpa_master_rekey wps_possible
+local vlan_enable ifname vlan_file vlan_interface vlan_naming
config_get enc $vif encryption
config_get wep_rekey$vif wep_rekey# 300
@@ -112,6 +113,22 @@ hostapd_set_bss_options() {
[ -n $wpa_group_rekey ] append $var
wpa_group_rekey=$wpa_group_rekey $N
[ -n $wpa_pair_rekey ] append $var
wpa_ptk_rekey=$wpa_pair_rekey$N
[ -n $wpa_master_rekey ] append $var
wpa_gmk_rekey=$wpa_master_rekey $N
+config_get vlan_enable $vif vlan_enable 0
+case $vlan_enable in
+1|2)
+append $var dynamic_vlan=$vlan_enable $N
+config_get ifname $vif ifname
+config_get vlan_file $vif vlan_file
/var/run/hostapd.${ifname}.vlan
+[ $vlan_file =
/var/run/hostapd.${ifname}.vlan ] cat $vlan_file -EOF
+* ${ifname}.#
+EOF
+append $var vlan_file=$vlan_file $N
+config_get vlan_interface $vif vlan_interface
eth0
+append $var
vlan_tagged_interface=$vlan_interface $N
+config_get vlan_naming $vif vlan_naming 1
+append $var vlan_naming=$vlan_naming $N
+;;
+esac
;;
*wep*)
config_get key $vif key
diff --git
a/package/network/services/hostapd/patches/620-dynamic_vlan-correct_bridge_interface_names.patch
b/package/network/services/hostapd/patches/620-dynamic_vlan-correct_bridge_interface_names.patch
new file mode 100644
index 000..ff87d3d
--- /dev/null
+++
b/package/network/services/hostapd/patches/620-dynamic_vlan-correct_bridge_interface_names.patch
@@ -0,0 +1,20 @@
+--- a/src/ap/vlan_init.c2012-10-14 22:30:08.0 +0300
b/src/ap/vlan_init.c2012-10-14 23:51:12.0 +0300
+@@ -493,7 +493,7 @@
+ while (vlan) {
+ if (os_strcmp(ifname, vlan-ifname) == 0) {
+
+-os_snprintf(br_name, sizeof(br_name), brvlan%d,
++os_snprintf(br_name, sizeof(br_name), br-vlan%d,
+ vlan-vlan_id);
+
+ if (!br_addbr(br_name))
+@@ -550,7 +550,7 @@
+
+ while (vlan) {
+ if (os_strcmp(ifname, vlan-ifname) == 0) {
+-os_snprintf(br_name, sizeof(br_name), brvlan%d,
++os_snprintf(br_name, sizeof(br_name), br-vlan%d,
+ vlan-vlan_id);
+
+ if (vlan-clean DVLAN_CLEAN_WLAN_PORT)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH][BCM63XX] Fix typo in 96338GW power LED.
Fix typo in 96338GW power LED.
---
diff --git a/target/linux/brcm63xx/patches-3.3/310-board_leds_naming.patch
b/target/linux/brcm63xx/patches-3.3/310-board_leds_naming.patch
index 798e801..df4ddb4 100644
--- a/target/linux/brcm63xx/patches-3.3/310-board_leds_naming.patch
+++ b/target/linux/brcm63xx/patches-3.3/310-board_leds_naming.patch
@@ -23,7 +23,7 @@
},
{
- .name = power,
-+ .name = 96338GW!green:power,
++ .name = 96338GW:green:power,
.gpio = 0,
.active_low = 1,
.default_trigger = default-on,
diff --git a/target/linux/brcm63xx/patches-3.6/310-board_leds_naming.patch
b/target/linux/brcm63xx/patches-3.6/310-board_leds_naming.patch
index 84603b0..8b307a2 100644
--- a/target/linux/brcm63xx/patches-3.6/310-board_leds_naming.patch
+++ b/target/linux/brcm63xx/patches-3.6/310-board_leds_naming.patch
@@ -23,7 +23,7 @@
},
{
- .name = power,
-+ .name = 96338GW!green:power,
++ .name = 96338GW:green:power,
.gpio = 0,
.active_low = 1,
.default_trigger = default-on,
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] cns3xxx: advertise pcie usb usbgadget features
Signed-off-by: Tim Harvey thar...@gateworks.com --- target/linux/cns3xxx/Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/target/linux/cns3xxx/Makefile b/target/linux/cns3xxx/Makefile index 72e51fd..50c0e94 100644 --- a/target/linux/cns3xxx/Makefile +++ b/target/linux/cns3xxx/Makefile @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk ARCH:=arm BOARD:=cns3xxx BOARDNAME:=Cavium Networks Econa CNS3xxx -FEATURES:=squashfs fpu gpio +FEATURES:=squashfs fpu gpio pcie usb usbgadget CFLAGS:=-Os -pipe -march=armv6k -mtune=mpcore -mfloat-abi=softfp -mfpu=vfp -fno-caller-saves MAINTAINER:=Imre Kaloz ka...@openwrt.org -- 1.7.5.4 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Cross Libtool
On Wed, Nov 14, 2012 at 12:08 PM, Jo-Philipp Wich x...@subsignal.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It works for any other package so it is unlikely to be buggy on the link stage. It is most likely improperly called by the Makefile. And indeed, line 11 of despotify's Makefile says: LD = $(CC) That is the most likely culprit. I commented out this line. Still the same problem : during the compile phase libtool calls cross-compiler. During link phase it calls native host gcc. BR, Drasko ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Cross Libtool
On Wed, Nov 14, 2012 at 11:36 AM, Florian Fainelli flor...@openwrt.org wrote: No, but packages that do provide a libtool should be built by OpenWrt with PKG_LIBTOOL_PATHS and PKG_FIXUP accordingly. libdespotify I am trying to compile does not provide it's libtoo. I am using OpenWRTs tool, which calls cross compiler in compile mode, but in the link mode it fails back to native gcc, which is wrong. BR, Drasko ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 5/5] Add support for three PowerCloud devices
Hi Gabor, Thank you for the feedback and UniFi and other patch commit. I have couple of quick questions before reworking the patch. On 14/11/2012 7:18 AM, Gabor Juhos wrote: Hi Daniel, Please split this patch into smaller pieces, as I did that with your UniFi AP patch. More comments inline... Signed-off-by: Daniel Dickinson dan...@powercloudsystems.com --- target/linux/ar71xx/base-files/etc/diag.sh |6 + .../ar71xx/base-files/etc/uci-defaults/network | 11 + target/linux/ar71xx/base-files/lib/ar71xx.sh |6 + .../ar71xx/base-files/lib/upgrade/platform.sh |2 + target/linux/ar71xx/config-3.3 |1 + target/linux/ar71xx/config-3.6 |1 + target/linux/ar71xx/generic/profiles/pcs.mk| 32 +++ target/linux/ar71xx/image/Makefile |4 + .../patches-3.3/690-MIPS-ath79-pcs-cr5000.patch| 278 .../patches-3.3/700-MIPS-ath79-pcs-cap324.patch| 173 .../patches-3.6/690-MIPS-ath79-pcs-cr5000.patch| 278 .../patches-3.6/700-MIPS-ath79-pcs-cap324.patch| 173 12 files changed, 965 insertions(+) create mode 100644 target/linux/ar71xx/patches-3.3/690-MIPS-ath79-pcs-cr5000.patch create mode 100644 target/linux/ar71xx/patches-3.3/700-MIPS-ath79-pcs-cap324.patch create mode 100644 target/linux/ar71xx/patches-3.6/690-MIPS-ath79-pcs-cr5000.patch create mode 100644 target/linux/ar71xx/patches-3.6/700-MIPS-ath79-pcs-cap324.patch ... diff --git a/target/linux/ar71xx/generic/profiles/pcs.mk b/target/linux/ar71xx/generic/profiles/pcs.mk index eaf9699..5b3e260 100644 --- a/target/linux/ar71xx/generic/profiles/pcs.mk +++ b/target/linux/ar71xx/generic/profiles/pcs.mk @@ -17,6 +17,17 @@ endef $(eval $(call Profile,UBDEV01)) +define Profile/UBDEVOD +NAME:=PCS ubdevod model Please use 'PowerCloud Systems' instead of 'PCS' in profile names/descriptions as Felix suggested for the other patch. ... diff --git a/target/linux/ar71xx/image/Makefile b/target/linux/ar71xx/image/Makefile index 9678d66..27f3daa 100644 --- a/target/linux/ar71xx/image/Makefile +++ b/target/linux/ar71xx/image/Makefile @@ -171,6 +171,8 @@ cameo913x_mtdlayout=mtdparts=spi0.0:128k(u-boot)ro,64k(config)ro,960k(kernel),28 cameo933x_mtdlayout=mtdparts=spi0.0:64k(u-boot)ro,64k(art)ro,64k(mac)ro,64k(nvram)ro,192k(language)ro,896k(kernel),2752k(rootfs),3648k@0x7(firmware) cap4200ag_mtdlayout=mtdparts=spi0.0:256k(u-boot),64k(u-boot-env),320k(custom)ro,1536k(kernel),12096k(rootfs),2048k(failsafe),64k(art),13632k@0xa(firmware) db120_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,6336k(rootfs),1408k(kernel),64k(nvram),64k(art)ro,7744k@0x5(firmware) +cr5000_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,1408k(kernel),5696k(rootfs),640k(certs),64k(nvram),64k(art)ro,7104k@0x5(firmware) +cap324_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,1408k(kernel),13888k(rootfs),640k(certs),64k(nvram),64k(art)ro,15296k@0x5(firmware) Please keep these sorted alphabetically. dir825b1_mtdlayout=mtdparts=spi0.0:256k(uboot)ro,64k(config)ro,1024k(kernel),5184k(rootfs),64k(caldata)ro,1600k(unknown)ro,6208k@0x5(firmware),64k@0x7f(caldata_copy) dir825b1_mtdlayout_fat=mtdparts=spi0.0:256k(uboot)ro,64k(config)ro,1024k(kernel),6784k(rootfs),64k(caldata)ro,7808k@0x5(firmware),64k@0x66(caldata_orig),6208k@0x5(firmware_orig) ew-dorin_mtdlayout_4M=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env),1024k(kernel),2688k(rootfs),64k(art),3712k@0x5(firmware) @@ -906,6 +908,8 @@ $(eval $(call SingleProfile,ZyXEL,$(fs_64k),NBG_460N_550N_550NH,nbg460n_550n_550 $(eval $(call SingleProfile,UBDEV,$(fs_64k),UBDEV01,ubdev01,UBNT-UF,ttyS0,115200,XM,XM,ar7240)) $(eval $(call SingleProfile,DLRTDEV,$(fs_64k),DLRTDEV01,dlrtdev01,DIR-825-B1,ttyS0,115200,01AP94-AR7161-RT-080619-00,00AP94-AR7161-RT-080619-00)) +$(eval $(call SingleProfile,UBDEV,$(fs_64k),UBDEVOD,ubdevod,UBNT-U20,ttyS0,115200,XM,XM,ar7240)) +$(eval $(call SingleProfile,AthLzma,$(fs_64k),CR5000,cr5000,CR5000,ttyS0,115200,$$(cr5000_mtdlayout),1441792,5832484,KRuImage)) Keep these sorted as well. $(eval $(call MultiProfile,AP121,AP121_2M AP121_4M)) $(eval $(call MultiProfile,EWDORIN, EWDORINAP EWDORINRT)) diff --git a/target/linux/ar71xx/patches-3.3/690-MIPS-ath79-pcs-cr5000.patch b/target/linux/ar71xx/patches-3.3/690-MIPS-ath79-pcs-cr5000.patch new file mode 100644 index 000..84dcac6 --- /dev/null +++ b/target/linux/ar71xx/patches-3.3/690-MIPS-ath79-pcs-cr5000.patch Use the 611-620 range for the patch name. @@ -0,0 +1,278 @@ +Index: linux-3.3.8/arch/mips/ath79/Kconfig +=== +--- linux-3.3.8.orig/arch/mips/ath79/Kconfig2012-11-01 22:04:55.0 -0400
[OpenWrt-Devel] [PATCH] cns3xxx: fix dwc_otg driver compat with udc-core
From Linux 3.0.0+ the udc-core driver provides the gadget probe/unregister
function. This removes those from the dwc_otg driver and removes the patch
that comments out the linkage of udc-core so that the dwc_otg driver can
co-exist happily with other USB Device Controllers.
Signed-off-by: Tim Harvey thar...@gateworks.com
---
.../linux/cns3xxx/files/drivers/usb/dwc/otg_pcd.c | 83
.../cns3xxx/patches-3.3/200-dwc_otg_support.patch | 11 ---
2 files changed, 0 insertions(+), 94 deletions(-)
diff --git a/target/linux/cns3xxx/files/drivers/usb/dwc/otg_pcd.c
b/target/linux/cns3xxx/files/drivers/usb/dwc/otg_pcd.c
index 2cf6243..85c6fd9 100644
--- a/target/linux/cns3xxx/files/drivers/usb/dwc/otg_pcd.c
+++ b/target/linux/cns3xxx/files/drivers/usb/dwc/otg_pcd.c
@@ -2416,87 +2416,4 @@ void dwc_otg_pcd_remove(struct platform_device *pdev)
otg_dev-pcd = 0;
}
-/**
- * This function registers a gadget driver with the PCD.
- *
- * When a driver is successfully registered, it will receive control
- * requests including set_configuration(), which enables non-control
- * requests. then usb traffic follows until a disconnect is reported.
- * then a host may connect again, or the driver might get unbound.
- *
- * @param driver The driver being registered
- */
-int usb_gadget_probe_driver(struct usb_gadget_driver *driver,
- int (*bind)(struct usb_gadget *))
-{
- int retval;
-
- DWC_DEBUGPL(DBG_PCD, registering gadget driver '%s'\n,
driver-driver.name);
-
- if (!driver || driver-max_speed == USB_SPEED_UNKNOWN ||
- !bind ||
- !driver-unbind ||
- !driver-disconnect ||
- !driver-setup) {
- DWC_DEBUGPL(DBG_PCDV,EINVAL\n);
- return -EINVAL;
- }
- if (s_pcd == 0) {
- DWC_DEBUGPL(DBG_PCDV,ENODEV\n);
- return -ENODEV;
- }
- if (s_pcd-driver != 0) {
- DWC_DEBUGPL(DBG_PCDV,EBUSY (%p)\n, s_pcd-driver);
- return -EBUSY;
- }
-
- /* hook up the driver */
- s_pcd-driver = driver;
- s_pcd-gadget.dev.driver = driver-driver;
-
- DWC_DEBUGPL(DBG_PCD, bind to driver %s\n, driver-driver.name);
- retval = bind(s_pcd-gadget);
- if (retval) {
- DWC_ERROR(bind to driver %s -- error %d\n,
- driver-driver.name, retval);
- s_pcd-driver = 0;
- s_pcd-gadget.dev.driver = 0;
- return retval;
- }
- DWC_DEBUGPL(DBG_ANY, registered gadget driver '%s'\n,
- driver-driver.name);
- return 0;
-}
-
-EXPORT_SYMBOL(usb_gadget_probe_driver);
-
-/**
- * This function unregisters a gadget driver
- *
- * @param driver The driver being unregistered
- */
-int usb_gadget_unregister_driver(struct usb_gadget_driver *driver)
-{
- //DWC_DEBUGPL(DBG_PCDV,%s(%p)\n, __func__, _driver);
-
- if (s_pcd == 0) {
- DWC_DEBUGPL(DBG_ANY, %s Return(%d): s_pcd==0\n, __func__,
- -ENODEV);
- return -ENODEV;
- }
- if (driver == 0 || driver != s_pcd-driver) {
- DWC_DEBUGPL(DBG_ANY, %s Return(%d): driver?\n, __func__,
- -EINVAL);
- return -EINVAL;
- }
-
- driver-unbind(s_pcd-gadget);
- s_pcd-driver = 0;
-
- DWC_DEBUGPL(DBG_ANY, unregistered driver '%s'\n,
- driver-driver.name);
- return 0;
-}
-EXPORT_SYMBOL(usb_gadget_unregister_driver);
-
#endif /* DWC_HOST_ONLY */
diff --git a/target/linux/cns3xxx/patches-3.3/200-dwc_otg_support.patch
b/target/linux/cns3xxx/patches-3.3/200-dwc_otg_support.patch
index ce15f7c..361c08a 100644
--- a/target/linux/cns3xxx/patches-3.3/200-dwc_otg_support.patch
+++ b/target/linux/cns3xxx/patches-3.3/200-dwc_otg_support.patch
@@ -56,14 +56,3 @@
help
A USB device uses a controller to talk to its host.
Systems should have only one such upstream link.
a/drivers/usb/gadget/Makefile
-+++ b/drivers/usb/gadget/Makefile
-@@ -3,7 +3,7 @@
- #
- ccflags-$(CONFIG_USB_GADGET_DEBUG) := -DDEBUG
-
--obj-$(CONFIG_USB_GADGET) += udc-core.o
-+#obj-$(CONFIG_USB_GADGET) += udc-core.o
- obj-$(CONFIG_USB_DUMMY_HCD) += dummy_hcd.o
- obj-$(CONFIG_USB_NET2272) += net2272.o
- obj-$(CONFIG_USB_NET2280) += net2280.o
--
1.7.5.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
