Re: [OpenWrt-Devel] [PATCH] seagate goflex support for dockstar target

[Jan Willies]

2011/2/25 Martin Mueller 

> Hi Jan,
>
> On Fri, Feb 25, 2011 at 01:21:40PM +0100, Jan Willies wrote:
> > Do you happen to know whether the GoFlex Net has the same crypto
> > hardware acceleration as the Dockstar
> > (
> http://wiki.openwrt.org/toh/seagate/dockstar#crypto.hardware.acceleration
> ),
> > ie is it common about the Kirkwood SoCs?
>
> Yes it is and it works just like on the dockstar. Performance is not
> the best as the mv_cesa still doesn't use DMA. Unfortunatelly this
> seems out of my knowledge to implement it, but it would be nice.
>

Apparently someone is working now on TDMA support for mv_cesa:
http://code.google.com/p/openrd/issues/detail?id=18#c0

Would be nice to get this going.


> root@OpenWrt:/# hdparm -t /dev/mapper/crypt
>
> /dev/mapper/crypt:
>  Timing buffered disk reads:   40 MB in  3.03 seconds =  13.19 MB/sec
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] lantiq: add ath9k support to the arv7518

[Luca Olivetti]

Al 05/07/2011 1:04, En/na John Crispin ha escrit:


So, what's the final decision?
Should I forget about ath9k support on this board?

Bye


why always so huffy ?


Because, as you always say, I'm impatient ;-) since


has the open question of the patch possibly breaking ath9k on other
targets been answered ? no it has not...


...I made the question 3 months ago, and I don't want to wait 3 more 
months to raise it again.



so until that is resolved we cant add the patch.

as you may have noticed i have been pushing lots of patches the last few
days and am still in the middle of it ...

so, if you have more insight into the

+-  if (!ath9k_hw_use_flash(ah)) {
++  if (1) {

issue let me know.
otherwise you need to wait until i verified it


Just wanted to know if you or somebody else is going to check it or 
should I forget about it. If the latter, I won't ask more questions.


Bye
--
Luca
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Automatic channel selection implementation for openwrt in Netgear WNDR3700.

[Swaminathan Vasanth Rajaraman]

Hi,

 I have a doubt regarding dynamic channel allocation for Netgear WNDR3700
running openwrt. I am currently trying to find out the channels used by the
nearby Access Points during the boot phase. (ie),  Automatic channel
selection implementation for ath9k driver with openwrt Firmware for Netgear
WNDR3700 (Access point).

 I came to know that some are working in the same mainly on hostapd.

http://marc.info/?l=linux-wireless&m=130624133910615&w=2

The first code of the same is also released.
http://wireless.kernel.org/en/users/Documentation/acs
Is there a possibility to integrate the work done on hostapd while building
the openwrt firmware for Netgear WNDR3700 ?

I am trying to do the same for ath9k driver in Netgear WNDR3700.
Is there any working on the same or having any experience of it? If so i
would like to share, test it and contribute.


Cisco has done it with a concept called controllers.
Reference : http://www.mywi-fi.info/2010/05/dynamic-channel-assignment.html


Any help and pointers for doing something like this with ath9k is much
appreciated.

Awaiting your kind reply.

Thanks,


-- 
Best Regards,
Swaminathan Vasanth Rajaraman
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] seagate goflex support for dockstar target

[Martin Mueller]

Hi Jan,

On Tue, Jul 05, 2011 at 09:52:34AM +0200, Jan Willies wrote:
> 
> Apparently someone is working now on TDMA support for mv_cesa:
> http://code.google.com/p/openrd/issues/detail?id=18#c0
> 
> Would be nice to get this going.

Yes, but he seems to have some Problems of his own with it. I
remember reading a post form the original developer of mv_cesa that he
tried to implement DMA, but was disapointed with the speed gain it
brought an so abandoned it.

Thanks for the info, let's see if soemthing shows up.

bye
  MM
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] seagate goflex support for dockstar target

[Jan Willies]

2011/7/5 Martin Mueller 

> Hi Jan,
>
> On Tue, Jul 05, 2011 at 09:52:34AM +0200, Jan Willies wrote:
> >
> > Apparently someone is working now on TDMA support for mv_cesa:
> > http://code.google.com/p/openrd/issues/detail?id=18#c0
> >
> > Would be nice to get this going.
>
> Yes, but he seems to have some Problems of his own with it. I
> remember reading a post form the original developer of mv_cesa that he
> tried to implement DMA, but was disapointed with the speed gain it
> brought an so abandoned it.
>

Hm, too bad. Do you remember his name? The source states "
Sebastian Andrzej Siewior".
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] seagate goflex support for dockstar target

[Martin Mueller]

On Tue, Jul 05, 2011 at 05:56:03PM +0200, Jan Willies wrote:
> 2011/7/5 Martin Mueller 
> 
> >
> > Yes, but he seems to have some Problems of his own with it. I
> > remember reading a post form the original developer of mv_cesa that he
> > tried to implement DMA, but was disapointed with the speed gain it
> > brought an so abandoned it.
> >
> 
> Hm, too bad. Do you remember his name? The source states "
> Sebastian Andrzej Siewior".

Yes, correct. This is the post:

http://lists.debian.org/debian-arm/2009/11/msg00113.html

bye
  MM
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] Orion doesn't build anymore

[Matthias Buecher / Germany]

Thanks Maarten, now kernel compiles again.
One of your patches had a typo (COFIG instead of CONFIG), corrected it
and recreated it for the latest trunk revision.

Index: package/kernel/modules/crypto.mk
===
--- package/kernel/modules/crypto.mk(revision 27463)
+++ package/kernel/modules/crypto.mk(working copy)
@@ -41,7 +41,9 @@

 define KernelPackage/crypto-hash
   TITLE:=CryptoAPI hash support
-  KCONFIG:=CONFIG_CRYPTO_HASH
+  KCONFIG:= \
+   CONFIG_CRYPTO_HASH  \
+   CONFIG_CRYPTO_HASH2
   FILES:=$(LINUX_DIR)/crypto/crypto_hash.ko
   AUTOLOAD:=$(call AutoLoad,02,crypto_hash)
   $(call AddDepends/crypto)
@@ -447,7 +449,7 @@

 define KernelPackage/crypto-mv-cesa
   TITLE:=Marvell crypto engine
-  DEPENDS:=+kmod-crypto-manager +kmod-crypto-aes
@TARGET_kirkwood||TARGET_orion
+  DEPENDS:=+kmod-crypto-manager +kmod-crypto-aes +kmod-crypto-sha1
+kmod-crypto-hmac @TARGET_kirkwood||TARGET_orion
   KCONFIG:=CONFIG_CRYPTO_DEV_MV_CESA
   FILES:=$(LINUX_DIR)/drivers/crypto/mv_cesa.ko
   AUTOLOAD:=$(call AutoLoad,09,mv_cesa)



But now I run into another issue with ltq-tapi:
...
Set the kernel architecture to arm
configure: error: The lib_ifxos include directory is not valid!
make[3]: ***
[/home/maddes/openwrt/trunk/build_dir/linux-orion_generic/drv_tapi-3.13.0/.configured_]
Error 1
make[3]: Leaving directory `/home/maddes/openwrt/trunk/package/ltq-tapi'
...


Maddes

On 04.07.2011 21:52, Maarten Bezemer wrote:
> I noticed the same yesterday, but did not get to it to submit the
> patches.
> 
> In order to automatically select the kmod-crypto-sha1 and
> kmod-crypto-hmac packages the fix-crypto-mv-cesa.patch needs to be
> applied
> 
> For some reasons the linux source expects CONFIG_CRYPTO_HASH2 instead
> (?) of CONFIG_CRYPTO_HASH. See attached fix-crypto-hash.patch
> 
> Maybe for the crypto-hash patch the CONFIG_CRYPTO_HASH part needs to be
> removed? I am not a real Linux kernel developer so I do not know. Having
> both at least does not give errors.
> 
> With both patches applied the Orion target builds again without problems
> when kmod-mv-cesa is selected
> 
> Greetings,
>   Maarten
> 
> On Mon, 2011-07-04 at 20:24 +0200, Matthias Buecher / Germany wrote:
>> Hi everybody,
>>
>> I just got back to OpenWrt development after 6 months and recognized
>> that the Orion platform doesn't build anymore.
>> According to ticket #9209 [1] this happened ~3 months ago.
>> Can anybody please help, so I can continue developing some packages for
>> my platform.
>>
>> Thanks in advance
>> Maddes
>>
>> [1] https://dev.openwrt.org/ticket/9209
>> ___
>> 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

Matthias "Maddes" Bücher

-- 
http://www.maddes.net/
Home: Earth / Germany / Ruhr-Area
Index: package/kernel/modules/crypto.mk
===
--- package/kernel/modules/crypto.mk	(revision 27463)
+++ package/kernel/modules/crypto.mk	(working copy)
@@ -41,7 +41,9 @@
 
 define KernelPackage/crypto-hash
   TITLE:=CryptoAPI hash support
-  KCONFIG:=CONFIG_CRYPTO_HASH
+  KCONFIG:= \
+	CONFIG_CRYPTO_HASH  \
+	CONFIG_CRYPTO_HASH2 
   FILES:=$(LINUX_DIR)/crypto/crypto_hash.ko
   AUTOLOAD:=$(call AutoLoad,02,crypto_hash)
   $(call AddDepends/crypto)
@@ -447,7 +449,7 @@
 
 define KernelPackage/crypto-mv-cesa
   TITLE:=Marvell crypto engine
-  DEPENDS:=+kmod-crypto-manager +kmod-crypto-aes @TARGET_kirkwood||TARGET_orion
+  DEPENDS:=+kmod-crypto-manager +kmod-crypto-aes +kmod-crypto-sha1 +kmod-crypto-hmac @TARGET_kirkwood||TARGET_orion
   KCONFIG:=CONFIG_CRYPTO_DEV_MV_CESA
   FILES:=$(LINUX_DIR)/drivers/crypto/mv_cesa.ko
   AUTOLOAD:=$(call AutoLoad,09,mv_cesa)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] minor compile fix for ltq-vmmc (r27408)

[Luka Perkov]

Patch solves this compile error when compiling lantiq target:

DANUBE device is used
Configured for common VMMC and MPS driver (default)
configure: error: conditional "FALCON" was never defined.
Usually this means the macro was only invoked conditionally.
make[2]: *** 
[/home/luka/devel/openwrt-lantiq-lvm/openwrt-lantiq/build_dir/linux-lantiq_xway/drv_vmmc-1.9.0/.configured_]
 Error 1
make[2]: Leaving directory 
`/home/luka/devel/openwrt-lantiq-lvm/openwrt-lantiq/package/ltq-vmmc'
make[1]: *** [package/ltq-vmmc/compile] Error 2
make[1]: Leaving directory `/home/luka/devel/openwrt-lantiq-lvm/openwrt-lantiq'
make: *** [package/ltq-vmmc/compile] Error 2

Signed-off-by: Luka Perkov < openwrt ->-to->- lukaperkov.net >
---

Index: package/ltq-vmmc/patches/400-falcon.patch
===
--- package/ltq-vmmc/patches/400-falcon.patch   (revision 27465)
+++ package/ltq-vmmc/patches/400-falcon.patch   (working copy)
@@ -1,6 +1,24 @@
 --- a/configure.in
 +++ b/configure.in
-@@ -986,6 +986,11 @@ AC_ARG_WITH(device,
+@@ -956,14 +956,15 @@ AC_DEFINE([VMMC],[1],[enable VMMC suppor
+ AM_CONDITIONAL(DANUBE, false)
+ AM_CONDITIONAL(AR9, false)
+ AM_CONDITIONAL(VR9, false)
++AM_CONDITIONAL(FALCON, false)
+ AC_ARG_WITH(device,
+AC_HELP_STRING(
+-  [--with-device=DANUBE|TWINPASS|AR9|VR9],
++  [--with-device=DANUBE|TWINPASS|AR9|VR9|FALCON],
+   [Set device type, default is DANUBE]
+),
+[
+   if test "$withval" = yes; then
+- AC_MSG_ERROR([Set device type! Valid choices are 
DANUBE|TWINPASS|AR9|VR9]);
++ AC_MSG_ERROR([Set device type! Valid choices are 
DANUBE|TWINPASS|AR9|VR9|FALCON]);
+   else
+  case $withval in
+DANUBE)
+@@ -986,8 +987,13 @@ AC_ARG_WITH(device,
 AC_DEFINE([SYSTEM_VR9],[1],[enable VR9 specific code])
 AM_CONDITIONAL(VR9, true)
 ;;
@@ -10,8 +28,11 @@
 +   AM_CONDITIONAL(FALCON, true)
 +   ;;
 *)
-AC_MSG_ERROR([Set device type! Valid choices are 
DANUBE|TWINPASS|AR9|VR9]);
+-   AC_MSG_ERROR([Set device type! Valid choices are 
DANUBE|TWINPASS|AR9|VR9]);
++   AC_MSG_ERROR([Set device type! Valid choices are 
DANUBE|TWINPASS|AR9|VR9|FALCON]);
 ;;
+esac
+   fi
 --- a/src/Makefile.am
 +++ b/src/Makefile.am
 @@ -70,6 +70,11 @@ drv_vmmc_SOURCES +=\
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] Orion doesn't build anymore

[Luca Olivetti]

Al 05/07/11 22:47, En/na Matthias Buecher / Germany ha escrit:

> 
> But now I run into another issue with ltq-tapi:


Unsurprisingly, since, AFAIK, that's only meant for lantiq hardware,
so you should deselect it.
Did you select it in make menuconfig or was it selected automatically?

Bye
-- 
Luca
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] Lantiq TAPI driver also build for other platforms

[Matthias Buecher / Germany]

On 06.07.2011 00:38, Luca Olivetti wrote:
> Al 05/07/11 22:47, En/na Matthias Buecher / Germany ha escrit:
> 
>>
>> But now I run into another issue with ltq-tapi:
> 
> 
> Unsurprisingly, since, AFAIK, that's only meant for lantiq hardware,
> so you should deselect it.
> Did you select it in make menuconfig or was it selected automatically?
> 

It was selected automatically by "Build all packages".
I adopted the platform exclusion from the other Lantiq packages.

Let's hope this will be the last compilation issue for Orion.

Good night
Maddes


Index: package/ltq-tapi/Makefile
===
--- package/ltq-tapi/Makefile   (revision 27463)
+++ package/ltq-tapi/Makefile   (working copy)
@@ -60,10 +60,12 @@
$(call Build/Configure/Default)
 endef

-define Build/InstallDev
+ifdef CONFIG_TARGET_lantiq
+  define Build/InstallDev
$(INSTALL_DIR) $(1)/usr/include/drv_tapi
$(CP) --dereference $(PKG_BUILD_DIR)/include/* $(1)/usr/include/drv_tapi
(cd $(1)/usr/include/drv_tapi && ln -s . include && ln -s
../ifxos/ifx_types.h .)
-endef
+  endef
+endif

 $(eval $(call KernelPackage,ltq-tapi))
Index: package/ltq-tapi/Makefile
===
--- package/ltq-tapi/Makefile	(revision 27463)
+++ package/ltq-tapi/Makefile	(working copy)
@@ -60,10 +60,12 @@
 	$(call Build/Configure/Default)
 endef
 
-define Build/InstallDev
+ifdef CONFIG_TARGET_lantiq
+  define Build/InstallDev
 	$(INSTALL_DIR) $(1)/usr/include/drv_tapi
 	$(CP) --dereference $(PKG_BUILD_DIR)/include/* $(1)/usr/include/drv_tapi
 	(cd $(1)/usr/include/drv_tapi && ln -s . include && ln -s ../ifxos/ifx_types.h .)
-endef
+  endef
+endif
 
 $(eval $(call KernelPackage,ltq-tapi))
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [OpenWrt-Commits] r27466 - in trunk/package/e2fsprogs: . patches

[Philip Prindeville]

Personally I'd be inclined to put libraries at the end of the link order... 
since 'ld' will use the first match it finds... putting the libraries last 
gives the user the opportunity to explicitly override any library symbols.


On 7/5/11 4:10 PM, openwrt-comm...@openwrt.org wrote:
> Author: cshore
> Date: 2011-07-06 01:10:47 +0200 (Wed, 06 Jul 2011)
> New Revision: 27466
> 
> Added:
>trunk/package/e2fsprogs/patches/
>trunk/package/e2fsprogs/patches/100_add_missing_libpthread_for_blkid
> Log:
> [package] e2fsprogs: Added libpthread back to blkid link, otherwise blkid 
> fails to link)
> 
> Added: trunk/package/e2fsprogs/patches/100_add_missing_libpthread_for_blkid
> ===
> --- trunk/package/e2fsprogs/patches/100_add_missing_libpthread_for_blkid  
> (rev 0)
> +++ trunk/package/e2fsprogs/patches/100_add_missing_libpthread_for_blkid  
> 2011-07-05 23:10:47 UTC (rev 27466)
> @@ -0,0 +1,11 @@
> +--- a/lib/blkid/Makefile.in
>  b/lib/blkid/Makefile.in
> +@@ -126,7 +126,7 @@ tst_types: tst_types.o blkid_types.h
> + 
> + blkid: ../../misc/blkid.o libblkid.a $(DEPLIBUUID)
> + $(E) "  LD $@"
> +-$(Q) $(CC) -o blkid ../../misc/blkid.o libblkid.a $(LIBUUID)
> ++$(Q) $(CC) -lpthread -o blkid ../../misc/blkid.o libblkid.a $(LIBUUID)
> + 
> + test_probe: test_probe.in Makefile
> + $(E) "Creating test_probe..."
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel