ocf-linux-users Mailing List for Open Cryptographic Framework for Linux (Page 7)
Brought to you by:
david-m
Menu
▾
▴
ocf-linux-users — Anything and everything ocf-linux related
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(12) |
Sep
(39) |
Oct
(16) |
Nov
(7) |
Dec
(17) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(10) |
Feb
(1) |
Mar
(18) |
Apr
(8) |
May
(14) |
Jun
(12) |
Jul
(35) |
Aug
(11) |
Sep
(3) |
Oct
(3) |
Nov
(7) |
Dec
(2) |
| 2009 |
Jan
(20) |
Feb
(12) |
Mar
(31) |
Apr
(20) |
May
(31) |
Jun
|
Jul
(2) |
Aug
(5) |
Sep
(11) |
Oct
|
Nov
(2) |
Dec
(6) |
| 2010 |
Jan
(20) |
Feb
(10) |
Mar
(16) |
Apr
|
May
(17) |
Jun
|
Jul
(2) |
Aug
(30) |
Sep
(6) |
Oct
|
Nov
|
Dec
(1) |
| 2011 |
Jan
|
Feb
(9) |
Mar
(7) |
Apr
(6) |
May
(20) |
Jun
(2) |
Jul
(13) |
Aug
(4) |
Sep
(7) |
Oct
(9) |
Nov
(5) |
Dec
(2) |
| 2012 |
Jan
(5) |
Feb
(2) |
Mar
|
Apr
(1) |
May
|
Jun
(7) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(8) |
Dec
(19) |
| 2013 |
Jan
(2) |
Feb
(3) |
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(8) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
(2) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
|
From: David M. <dav...@mc...> - 2011-03-14 21:46:51
|
Jivin Schuurman, Herman lays it down ... > > Hi David, > > Are there any plans to re-synchronize the Linux OCF cryptodev > implementation with the OpenBSD version again, specifically the addition > of the CRYPTO_AES_CTR and CRYPTO_AES_XTS algorithms? I usually sync with FreeBSD, but sure if there is something there that would be nice to have. I don't sync very often, but I did check it a while back to see what was missing. I am supposed to be pushing out a release so maybe after that :-) Cheers, Davidm -- David McCullough, dav...@mc..., Ph:+61 734352815 McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org |
|
From: Schuurman, H. <he...@ti...> - 2011-03-14 20:42:40
|
Hi David, Are there any plans to re-synchronize the Linux OCF cryptodev implementation with the OpenBSD version again, specifically the addition of the CRYPTO_AES_CTR and CRYPTO_AES_XTS algorithms? Best regards, Herman Schuurman |
|
From: Shivdas G. <shi...@gm...> - 2011-02-04 04:30:52
|
Hi Kim, Thanks for your help. Regards, Shivdas Gujare On Thu, Feb 3, 2011 at 11:11 PM, Kim Phillips <kim...@fr...> wrote: > On Thu, 3 Feb 2011 21:50:29 +1000 > David McCullough <dav...@mc...> wrote: > >> Jivin Shivdas Gujare lays it down ... >> > do you know any other way to access kernel hardware acceleration >> > drivers from userspace >> > other than using OCF framework? >> >> There are a few OCF like (and cryptodev compatible) variants. I don't know >> of enything specific for linux that is usable and potentially better, > > Linus recently pulled this: > > commit 03c8efc1ffeb6b82a22c1af8dd908af349563314 > Author: Herbert Xu <he...@go...> > Date: Tue Oct 19 21:12:39 2010 +0800 > > crypto: af_alg - User-space interface for Crypto API > > and here's Herbert original post that has an example userspace call > sequence: > > http://www.mail-archive.com/lin...@vg.../msg04903.html > > Cheers, > > Kim > > |
|
From: David M. <dav...@mc...> - 2011-02-03 21:33:28
|
Jivin Kim Phillips lays it down ... > On Thu, 3 Feb 2011 21:50:29 +1000 > David McCullough <dav...@mc...> wrote: > > > Jivin Shivdas Gujare lays it down ... > > > do you know any other way to access kernel hardware acceleration > > > drivers from userspace > > > other than using OCF framework? > > > > There are a few OCF like (and cryptodev compatible) variants. I don't know > > of enything specific for linux that is usable and potentially better, > > Linus recently pulled this: > > commit 03c8efc1ffeb6b82a22c1af8dd908af349563314 > Author: Herbert Xu <he...@go...> > Date: Tue Oct 19 21:12:39 2010 +0800 > > crypto: af_alg - User-space interface for Crypto API > > and here's Herbert original post that has an example userspace call > sequence: > > http://www.mail-archive.com/lin...@vg.../msg04903.html Thanks Kim, I think I saw the original email but I didn't see the code posted, in fact, seems like I have not been getting the linux-crypto mails for a little while :-( Cheers, Davidm -- David McCullough, dav...@mc..., Ph:+61 734352815 McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org |
|
From: Kim P. <kim...@fr...> - 2011-02-03 17:42:05
|
On Thu, 3 Feb 2011 21:50:29 +1000
David McCullough <dav...@mc...> wrote:
> Jivin Shivdas Gujare lays it down ...
> > do you know any other way to access kernel hardware acceleration
> > drivers from userspace
> > other than using OCF framework?
>
> There are a few OCF like (and cryptodev compatible) variants. I don't know
> of enything specific for linux that is usable and potentially better,
Linus recently pulled this:
commit 03c8efc1ffeb6b82a22c1af8dd908af349563314
Author: Herbert Xu <he...@go...>
Date: Tue Oct 19 21:12:39 2010 +0800
crypto: af_alg - User-space interface for Crypto API
and here's Herbert original post that has an example userspace call
sequence:
http://www.mail-archive.com/lin...@vg.../msg04903.html
Cheers,
Kim
|
|
From: David M. <dav...@mc...> - 2011-02-03 11:54:25
|
Jivin Shivdas Gujare lays it down ... > On Thu, Feb 3, 2011 at 3:23 PM, David McCullough > <dav...@mc...> wrote: > > > > Jivin Shivdas Gujare lays it down ... > >> Hi David, > >> > >> thanks for your prompt reply. > >> > >> So, do you have ??any idea how drivers/crypto/talitos.c driver is > >> accessible via userspace, > >> much like how OCF taltios driver is accessible to openssl via /dev/crypto. > >> > >> I am not able to find as of the interface from userspace to the kernel > >> driver drivers/crypto/talitos.c. > > > > You can still use OCF with its cryptosoft driver to access the in-kernel > > talitos driver from user space. ??OCF's cryptosoft driver utilises the > > in-kernel crypto drivers to do the work, > > Thanks David, > > do you know any other way to access kernel hardware acceleration > drivers from userspace > other than using OCF framework? There are a few OCF like (and cryptodev compatible) variants. I don't know of enything specific for linux that is usable and potentially better, Cheers, Davidm > >> Thanks and Regards, > >> Shihvdas Gujare > >> > >> On Thu, Feb 3, 2011 at 2:04 PM, David McCullough > >> <dav...@mc...> wrote: > >> > > >> > Jivin Shivdas Gujare lays it down ... > >> >> Hi All, > >> >> > >> >> I have seen two implementation for the crypto acceleration driver > >> >> talitos.c on in > >> >> kernel/drivers/crypto/talitios.c and another in crypto/ocf/talitos/talitos.c > >> >> > >> >> I understand that crypto/ocf/talitos/talitos.c is a driver based on > >> >> OCF-linux framework, > >> >> but not sure how is it related to kernel driver kernel/drivers/crypto/talitios.c > >> >> > >> >> or in simple words why there are two similar drivers are available in > >> >> the kernel? > >> > > >> > Only one is available in the kernel, kernel/drivers/crypto/talitios.c. > >> > > >> > The other one is part of OCF, ??and OCF is not part of the linux kernel :-) > >> > > >> > The OCF version of the talitos driver was written before linux had adequate > >> > HW crypto support, ??but now it does and a rtalitos driver has been written > >> > for and accepted into the kernel. > >> > > >> > Hope that helps :-) > >> > > >> > Cheers, > >> > Davidm > >> > > >> > -- > >> > David McCullough, ?? ?? ??dav...@mc..., ??Ph:+61 734352815 > >> > McAfee - SnapGear ?? ?? ??http://www.mcafee.com ?? ?? ?? ?? http://www.uCdot.org > >> > > >> > >> > > > > -- > > David McCullough, ?? ?? ??dav...@mc..., ??Ph:+61 734352815 > > McAfee - SnapGear ?? ?? ??http://www.mcafee.com ?? ?? ?? ?? http://www.uCdot.org > > > > -- David McCullough, dav...@mc..., Ph:+61 734352815 McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org |
|
From: Shivdas G. <shi...@gm...> - 2011-02-03 11:40:38
|
On Thu, Feb 3, 2011 at 3:23 PM, David McCullough <dav...@mc...> wrote: > > Jivin Shivdas Gujare lays it down ... >> Hi David, >> >> thanks for your prompt reply. >> >> So, do you have any idea how drivers/crypto/talitos.c driver is >> accessible via userspace, >> much like how OCF taltios driver is accessible to openssl via /dev/crypto. >> >> I am not able to find as of the interface from userspace to the kernel >> driver drivers/crypto/talitos.c. > > You can still use OCF with its cryptosoft driver to access the in-kernel > talitos driver from user space. OCF's cryptosoft driver utilises the > in-kernel crypto drivers to do the work, Thanks David, do you know any other way to access kernel hardware acceleration drivers from userspace other than using OCF framework? -Regards, Shivdas > > Cheers, > Davidm > >> >> Thanks and Regards, >> Shihvdas Gujare >> >> On Thu, Feb 3, 2011 at 2:04 PM, David McCullough >> <dav...@mc...> wrote: >> > >> > Jivin Shivdas Gujare lays it down ... >> >> Hi All, >> >> >> >> I have seen two implementation for the crypto acceleration driver >> >> talitos.c on in >> >> kernel/drivers/crypto/talitios.c and another in crypto/ocf/talitos/talitos.c >> >> >> >> I understand that crypto/ocf/talitos/talitos.c is a driver based on >> >> OCF-linux framework, >> >> but not sure how is it related to kernel driver kernel/drivers/crypto/talitios.c >> >> >> >> or in simple words why there are two similar drivers are available in >> >> the kernel? >> > >> > Only one is available in the kernel, kernel/drivers/crypto/talitios.c. >> > >> > The other one is part of OCF, ??and OCF is not part of the linux kernel :-) >> > >> > The OCF version of the talitos driver was written before linux had adequate >> > HW crypto support, ??but now it does and a rtalitos driver has been written >> > for and accepted into the kernel. >> > >> > Hope that helps :-) >> > >> > Cheers, >> > Davidm >> > >> > -- >> > David McCullough, ?? ?? ??dav...@mc..., ??Ph:+61 734352815 >> > McAfee - SnapGear ?? ?? ??http://www.mcafee.com ?? ?? ?? ?? http://www.uCdot.org >> > >> >> > > -- > David McCullough, dav...@mc..., Ph:+61 734352815 > McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org > |
|
From: David M. <dav...@mc...> - 2011-02-03 09:55:57
|
Jivin Shivdas Gujare lays it down ... > Hi David, > > thanks for your prompt reply. > > So, do you have any idea how drivers/crypto/talitos.c driver is > accessible via userspace, > much like how OCF taltios driver is accessible to openssl via /dev/crypto. > > I am not able to find as of the interface from userspace to the kernel > driver drivers/crypto/talitos.c. You can still use OCF with its cryptosoft driver to access the in-kernel talitos driver from user space. OCF's cryptosoft driver utilises the in-kernel crypto drivers to do the work, Cheers, Davidm > > Thanks and Regards, > Shihvdas Gujare > > On Thu, Feb 3, 2011 at 2:04 PM, David McCullough > <dav...@mc...> wrote: > > > > Jivin Shivdas Gujare lays it down ... > >> Hi All, > >> > >> I have seen two implementation for the crypto acceleration driver > >> talitos.c on in > >> kernel/drivers/crypto/talitios.c and another in crypto/ocf/talitos/talitos.c > >> > >> I understand that crypto/ocf/talitos/talitos.c is a driver based on > >> OCF-linux framework, > >> but not sure how is it related to kernel driver kernel/drivers/crypto/talitios.c > >> > >> or in simple words why there are two similar drivers are available in > >> the kernel? > > > > Only one is available in the kernel, kernel/drivers/crypto/talitios.c. > > > > The other one is part of OCF, ??and OCF is not part of the linux kernel :-) > > > > The OCF version of the talitos driver was written before linux had adequate > > HW crypto support, ??but now it does and a rtalitos driver has been written > > for and accepted into the kernel. > > > > Hope that helps :-) > > > > Cheers, > > Davidm > > > > -- > > David McCullough, ?? ?? ??dav...@mc..., ??Ph:+61 734352815 > > McAfee - SnapGear ?? ?? ??http://www.mcafee.com ?? ?? ?? ?? http://www.uCdot.org > > > > -- David McCullough, dav...@mc..., Ph:+61 734352815 McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org |
|
From: Shivdas G. <shi...@gm...> - 2011-02-03 09:07:05
|
Hi David, thanks for your prompt reply. So, do you have any idea how drivers/crypto/talitos.c driver is accessible via userspace, much like how OCF taltios driver is accessible to openssl via /dev/crypto. I am not able to find as of the interface from userspace to the kernel driver drivers/crypto/talitos.c. Thanks and Regards, Shihvdas Gujare On Thu, Feb 3, 2011 at 2:04 PM, David McCullough <dav...@mc...> wrote: > > Jivin Shivdas Gujare lays it down ... >> Hi All, >> >> I have seen two implementation for the crypto acceleration driver >> talitos.c on in >> kernel/drivers/crypto/talitios.c and another in crypto/ocf/talitos/talitos.c >> >> I understand that crypto/ocf/talitos/talitos.c is a driver based on >> OCF-linux framework, >> but not sure how is it related to kernel driver kernel/drivers/crypto/talitios.c >> >> or in simple words why there are two similar drivers are available in >> the kernel? > > Only one is available in the kernel, kernel/drivers/crypto/talitios.c. > > The other one is part of OCF, and OCF is not part of the linux kernel :-) > > The OCF version of the talitos driver was written before linux had adequate > HW crypto support, but now it does and a rtalitos driver has been written > for and accepted into the kernel. > > Hope that helps :-) > > Cheers, > Davidm > > -- > David McCullough, dav...@mc..., Ph:+61 734352815 > McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org > |
|
From: David M. <dav...@mc...> - 2011-02-03 08:49:53
|
Jivin Shivdas Gujare lays it down ... > Hi All, > > I have seen two implementation for the crypto acceleration driver > talitos.c on in > kernel/drivers/crypto/talitios.c and another in crypto/ocf/talitos/talitos.c > > I understand that crypto/ocf/talitos/talitos.c is a driver based on > OCF-linux framework, > but not sure how is it related to kernel driver kernel/drivers/crypto/talitios.c > > or in simple words why there are two similar drivers are available in > the kernel? Only one is available in the kernel, kernel/drivers/crypto/talitios.c. The other one is part of OCF, and OCF is not part of the linux kernel :-) The OCF version of the talitos driver was written before linux had adequate HW crypto support, but now it does and a rtalitos driver has been written for and accepted into the kernel. Hope that helps :-) Cheers, Davidm -- David McCullough, dav...@mc..., Ph:+61 734352815 McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org |
|
From: Shivdas G. <shi...@gm...> - 2011-02-03 07:52:36
|
Hi All, I have seen two implementation for the crypto acceleration driver talitos.c on in kernel/drivers/crypto/talitios.c and another in crypto/ocf/talitos/talitos.c I understand that crypto/ocf/talitos/talitos.c is a driver based on OCF-linux framework, but not sure how is it related to kernel driver kernel/drivers/crypto/talitios.c or in simple words why there are two similar drivers are available in the kernel? Thanks for any help. Thanks and regards, Shivdas Gujare |
|
From: David M. <dav...@mc...> - 2010-12-22 15:44:28
|
Hi all, Attached is a patch that gives much improved SMP support when using ocf. It also addresses the current CBC Oracle issues circulating in the *BSD world at the moment. I am planning a release as soon as possible, but it's not the best time of year to gets things done quickly :-) I figured some people may want this ASAP, so a patch. I haven't had time to test it on all platforms and a lot of kernel versions, however current 2.4 and 2.6 systems appear to be ok. The patch is against the original ocf-linux-20100325 release. Cheers, Davidm -- David McCullough, dav...@mc..., Ph:+61 734352815 McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org |
|
From: David M. <dav...@mc...> - 2010-09-06 04:02:27
|
Jivin Pavel Roskin lays it down ... > Hello! > > This chunk is useless: > > @@ -9,6 +9,7 @@ > > #include <linux/types.h> > #include <linux/ioctl.h> > +#include <linux/types.h> /* for __u32 in user space */ > #include <linux/irqnr.h> > > /* ioctl()'s for the random number generator */ > > > As you can see, there is another linux/types.h just above the one that's > added by the patch. Applied, Thanks, Davidm -- David McCullough, dav...@mc..., Ph:+61 734352815 McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org |
|
From: David M. <dav...@mc...> - 2010-09-06 04:00:10
|
Jivin Pavel Roskin lays it down ... > Hello! > > There is no ioctl field in struct file_operations in Linux 2.6.36-rc3. > Therefore, following patch is needed to fix compilation: > > --- cryptodev.c > +++ cryptodev.c > @@ -1015,7 +1015,9 @@ static struct file_operations cryptodev_ > .owner = THIS_MODULE, > .open = cryptodev_open, > .release = cryptodev_release, > +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,36) > .ioctl = cryptodev_ioctl, > +#endif > #ifdef HAVE_UNLOCKED_IOCTL > .unlocked_ioctl = cryptodev_unlocked_ioctl, > #endif > > > The crypto device functionality is still functional with this patch > applied. Applied, thanks :-) Cheers, Davidm -- David McCullough, dav...@mc..., Ph:+61 734352815 McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org |
|
From: David M. <dav...@mc...> - 2010-09-06 03:57:28
|
Jivin Pavel Roskin lays it down ...
> Hello!
>
> This piece of code in cryptodev_open() is wrong and unnecessary:
>
> if (filp->private_data) {
> printk("cryptodev: Private data already exists !\n");
> return(0);
> }
>
> This check is triggered on Linux 2.6.35 and 2.6.36-rc3 and causes the
> initialization to be cut short, which causes an oops on uninitialized
> list in subsequent calls.
>
> Generally, it's a bad idea to bail out from a function without returning
> an error code.
>
> I'm not sure if I'm supposed to send a patch considering that OCF is a
> patch itself.
We found that one too, just not in a release yet,
The current patch is attached :-)
Thanks,
Davidm
--
David McCullough, dav...@mc..., Ph:+61 734352815
McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org
|
|
From: Pavel R. <pr...@gn...> - 2010-09-03 20:29:33
|
Hello! This chunk is useless: @@ -9,6 +9,7 @@ #include <linux/types.h> #include <linux/ioctl.h> +#include <linux/types.h> /* for __u32 in user space */ #include <linux/irqnr.h> /* ioctl()'s for the random number generator */ As you can see, there is another linux/types.h just above the one that's added by the patch. -- Regards, Pavel Roskin |
|
From: Pavel R. <pr...@gn...> - 2010-09-03 20:26:21
|
Hello! There is no ioctl field in struct file_operations in Linux 2.6.36-rc3. Therefore, following patch is needed to fix compilation: --- cryptodev.c +++ cryptodev.c @@ -1015,7 +1015,9 @@ static struct file_operations cryptodev_ .owner = THIS_MODULE, .open = cryptodev_open, .release = cryptodev_release, +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,36) .ioctl = cryptodev_ioctl, +#endif #ifdef HAVE_UNLOCKED_IOCTL .unlocked_ioctl = cryptodev_unlocked_ioctl, #endif The crypto device functionality is still functional with this patch applied. -- Regards, Pavel Roskin |
|
From: Pavel R. <pr...@gn...> - 2010-09-03 20:21:35
|
Hello!
This piece of code in cryptodev_open() is wrong and unnecessary:
if (filp->private_data) {
printk("cryptodev: Private data already exists !\n");
return(0);
}
This check is triggered on Linux 2.6.35 and 2.6.36-rc3 and causes the
initialization to be cut short, which causes an oops on uninitialized
list in subsequent calls.
Generally, it's a bad idea to bail out from a function without returning
an error code.
I'm not sure if I'm supposed to send a patch considering that OCF is a
patch itself.
--
Regards,
Pavel Roskin
|
|
From: Ronen S. <rsh...@ma...> - 2010-08-29 15:57:53
|
The idea was that accessing a reg while using a base as a define is faster then having the base as a variable... -----Original Message----- From: Harro Haan [mailto:hr...@gm...] Sent: Tuesday, August 24, 2010 12:30 PM To: dav...@mc...; Ronen Shitrit Cc: Pat...@bd...; ocf...@li... Subject: Re: infinite wait in mv_cesa (Marvell Kirkwood) icw cryptotest Problem solved! INTER_REGS_BASE (in mvSysHwConfig.h) had the value 0xFEE00000. This is the same as KIRKWOOD_PCIE_IO_VIRT_BASE in linux-2.6.33/arch/arm/mach-kirkwood/include/mach/kirkwood.h. For my configuration it should be KIRKWOOD_REGS_VIRT_BASE, which is 0xfed00000. Why does the define INTER_REGS_BASE exist? Would it not be cleaner to use “cesa_device.reg” instead (set by platform_get_resource_byname() in cesa_ocf_drv.c)? Regards, Harro On 23 August 2010 16:47, Harro Haan <hr...@gm...> wrote: > Some additional info, > > When I define CESA_OCF_POLLING in cesa_ocf_drv.c everything works fine. > > When I do "cat /proc/interrupts" (with #undef CESA_OCF_POLLING), I can > see that no cesa interrupts occurred. When I look at the debug output > (see previous mail) I do not see the line "cesa_interrupt_handler()" > either. > > So for my configuration something is wrong/missing with my interrupts. > Any hints? > > Thanks, > > Harro > > On 20 August 2010 16:52, Harro Haan <hr...@gm...> wrote: >> Hello David, >> >> I’m trying to get this driver working with a 3.6.33 kernel on my >> OpenRD-Ultimate 88F6281 development board, but the cryptotest program >> is waiting forever. >> >> Debug output for mv_cesa: >> ------------------------------------ >> root@DB88FXX81:/ ./cryptotest -a aes >> cryptodev_open() >> cryptodev_ioctl(cmd=c0046364 arg=beea0954) >> cryptodev_ioctl(CRIOGET) >> cryptodev_ioctl(cmd=c030636a arg=beea09b4) >> cryptodev_ioctl(CIOCGSESSION2) >> cryptodev_ioctl(CIOCGSESSION2) - no mac >> crypto/ocf/crypto.c,389: DRIVER_LOCK() >> crypto/ocf/crypto.c,413: DRIVER_UNLOCK() >> cesa_ocf_newsession() >> crypto/ocf/kirkwood/cesa_ocf_drv.c,875: new session 1 >> crypto/ocf/kirkwood/cesa_ocf_drv.c,896: (1) AES CBC >> crypto/ocf/kirkwood/cesa_ocf_drv.c,906: key length 16 >> crypto/ocf/crypto.c,415: DRIVER_LOCK() >> crypto/ocf/crypto.c,425: DRIVER_UNLOCK() >> csecreate() >> cseadd() >> cryptodev_ioctl(cmd=c01c6367 arg=beea0998) >> cryptodev_ioctl(CIOCCRYPT) >> csefind() >> cryptodev_op() >> crypto_dispatch() >> crypto/ocf/crypto.c,815: Q_LOCK() >> crypto/ocf/crypto.c,839: Q_UNLOCK() >> crypto_invoke() >> cesa_ocf_process() >> crypto/ocf/kirkwood/cesa_ocf_drv.c,425: handle UIO. >> crypto/ocf/kirkwood/cesa_ocf_drv.c,440: buf 0-> addr ded17500, size 10 >> crypto/ocf/kirkwood/cesa_ocf_drv.c,480: cipher encrypt >> crypto/ocf/kirkwood/cesa_ocf_drv.c,491: IV from USER (offset 0) >> crypto/ocf/kirkwood/cesa_ocf_drv.c,508: don't copy the IV back to the buffer >> >> crypto/ocf/kirkwood/cesa_ocf_drv.c,596: Sending Action: >> crypto/ocf/kirkwood/cesa_ocf_drv.c,597: IV from user: 1. IV offset 0 >> crypto/ocf/kirkwood/cesa_ocf_drv.c,598: crypt offset 10 len 10 >> crypto/ocf/kirkwood/cesa_ocf_drv.c,599: Auth offset 0 len 0 >> crypto/ocf/kirkwood/cesa_ocf_drv.c,600: set digest in offset 0 . >> SRC BUFFER: pMbuf=dfa4bc24, numFrags=2, mbufSize=32 >> # 0. bufVirt=df8ee020, bufSize=16 >> df8ee020: 33 35 38 36 74 34 69 6f 68 33 75 21 75 36 34 39 >> # 1. bufVirt=ded17500, bufSize=16 >> ded17500: 6e 33 38 39 34 36 6f 74 38 69 74 39 31 65 75 6e >> crypto/ocf/crypto.c,841: Q_LOCK() >> crypto/ocf/crypto.c,867: Q_UNLOCK() >> cryptodev_op about to WAIT >> >> ------------------------------------ >> >> Debug output for cryptosoft (which is working just fine): >> ------------------------------------ >> root@DB88FXX81:/ ./cryptotest -a aes >> cryptodev_open() >> cryptodev_ioctl(cmd=c0046364 arg=bea58954) >> cryptodev_ioctl(CRIOGET) >> cryptodev_ioctl(cmd=c030636a arg=bea589b4) >> cryptodev_ioctl(CIOCGSESSION2) >> cryptodev_ioctl(CIOCGSESSION2) - no mac >> crypto/ocf/crypto.c,389: DRIVER_LOCK() >> crypto/ocf/crypto.c,413: DRIVER_UNLOCK() >> swcr_newsession() >> swcr_newsession crypto_alloc_*blkcipher(cbc(aes), 0x0) >> swcr_newsession cbc(aes) cipher is async >> swcr_newsession key:cri->cri_klen=128,(cri->cri_klen + 7)/8=16 >> 0x32 0x61 0x38 0x6f 0x21 0x32 0x61 0x61 >> 0x21 0x35 0x75 0x21 0x69 0x30 0x65 0x21 >> crypto/ocf/crypto.c,415: DRIVER_LOCK() >> crypto/ocf/crypto.c,425: DRIVER_UNLOCK() >> csecreate() >> cseadd() >> cryptodev_ioctl(cmd=c01c6367 arg=bea58998) >> cryptodev_ioctl(CIOCCRYPT) >> csefind() >> cryptodev_op() >> crypto_dispatch() >> crypto/ocf/crypto.c,815: Q_LOCK() >> crypto/ocf/crypto.c,839: Q_UNLOCK() >> crypto_invoke() >> swcr_process() >> swcr_process_req() >> crypto OP success 0 >> crypto_done() >> crypto/ocf/crypto.c,1156: Q_LOCK() >> crypto/ocf/crypto.c,1158: Q_UNLOCK() >> cryptodev_cb() >> crypto/ocf/crypto.c,841: Q_LOCK() >> crypto/ocf/crypto.c,867: Q_UNLOCK() >> cryptodev_op about to WAIT >> cryptodev_op finished WAITING error=0 >> cryptodev_ioctl(cmd=c01c6367 arg=bea58998) >> cryptodev_ioctl(CIOCCRYPT) >> csefind() >> cryptodev_op() >> crypto_dispatch() >> crypto/ocf/crypto.c,815: Q_LOCK() >> crypto/ocf/crypto.c,839: Q_UNLOCK() >> crypto_invoke() >> swcr_process() >> swcr_process_req() >> crypto OP success 0 >> crypto_done() >> crypto/ocf/crypto.c,1156: Q_LOCK() >> crypto/ocf/crypto.c,1158: Q_UNLOCK() >> cryptodev_cb() >> crypto/ocf/crypto.c,841: Q_LOCK() >> crypto/ocf/crypto.c,867: Q_UNLOCK() >> cryptodev_op about to WAIT >> cryptodev_op finished WAITING error=0 >> cryptodev_ioctl(cmd=40046366 arg=bea589cc) >> cryptodev_ioctl(CIOCFSESSION) >> csefind() >> csedelete() >> csefree() >> crypto_freesession() >> crypto/ocf/crypto.c,450: DRIVER_LOCK() >> crypto/ocf/crypto.c,468: DRIVER_UNLOCK() >> swcr_freesession() >> crypto/ocf/crypto.c,471: DRIVER_LOCK() >> crypto/ocf/crypto.c,481: DRIVER_UNLOCK() >> 0.089 sec, cryptodev_release() >> 2 aes crypts, 16 bytes, 358 byte/sec, 0.0 Mb/sec >> root@DB88FXX81:/ >> ------------------------------------ >> >> I am following this thread as well: >> “[Ocf-linux-users] OCF driver for Marvell Kirkwood (88F6xxx) Processors” >> http://sourceforge.net/mailarchive/forum.php?thread_name=8D145DCD0F55B543949BE94258003A200DF9AD4EA6%40exchange12.bdt-rw.de&forum_name=ocf-linux-users >> >> Attached are my patches (fixes as described in the thread above) and >> series file. >> >> Do you have an idea why the system is hanging/waiting forever? >> >> Thanks, >> >> Harro >> > |
|
From: Harro H. <hr...@gm...> - 2010-08-25 11:03:35
|
Hello Patrick, I had the same problem with kirkwood icw linux-2.6.33, the cause is that platform_data is missing. See ocf-add-platform_data-to-mv_crypto.patch in this thread: http://sourceforge.net/mailarchive/forum.php?thread_name=20100825052824.GB12893%40mcafee.com&forum_name=ocf-linux-users Regards, Harro On 24 August 2010 18:15, Flaig, Patrick <Pat...@bd...> wrote: > Hello David, > > I found the reason, why the driver is not working. > The complete device registration was missing for mach-mv78xx0. > > I now tried to add that but still have some problems with a crashing driver. > > To common.c I added > > /***************************************************************************** > * Cryptographic Engines and Security Accelerator (CESA) > ****************************************************************************/ > > static struct resource mv78xx0_crypto_resources[] = { > { > .name = "regs", > .start = CRYPTO_PHYS_BASE, > .end = CRYPTO_PHYS_BASE + 0xffff, > .flags = IORESOURCE_MEM, > }, { > .name = "sram", > .start = MV78XX0_SRAM_PHYS_BASE, > .end = MV78XX0_SRAM_PHYS_BASE + MV78XX0_SRAM_SIZE - 1, > .flags = IORESOURCE_MEM, > }, { > .name = "crypto interrupt", > .start = IRQ_MV78XX0_CRYPTO, > .end = IRQ_MV78XX0_CRYPTO, > .flags = IORESOURCE_IRQ, > }, > }; > > static struct platform_device mv78xx0_crypto = { > .name = "mv_crypto", > .id = -1, > .num_resources = ARRAY_SIZE(mv78xx0_crypto_resources), > .resource = mv78xx0_crypto_resources, > }; > > void __init mv78xx0_crypto_init(void) > { > //kirkwood_clk_ctrl |= CGC_CRYPTO; > platform_device_register(&mv78xx0_crypto); > } > > With the following settings (mv78xx0.h) > > #define MV78XX0_SRAM_PHYS_BASE 0xf7000000 > #define MV78XX0_SRAM_SIZE SZ_2K > #define CRYPTO_PHYS_BASE (MV78XX0_REGS_PHYS_BASE | 0x90000) > > When loading the OCF driver for the feroceon it is crashing in setup_tdma_mbus_windows(...) in the following loop > > for (i = 0; i < dev->plat_data->dram->num_cs; i++) { > struct mbus_dram_window *cs = dev->plat_data->dram->cs + i; > writel( > ((cs->size - 1) & 0xffff0000) | > (cs->mbus_attr << 8) | > (dev->plat_data->dram->mbus_dram_target_id << 4) | 1, > dev->reg + WINDOW_CTRL(i) > ); > writel(cs->base, dev->reg + WINDOW_BASE(i)); > } > > > I think the SRAM configuration or something isn't set correct, but to get the correct values from the Feroceon documentation is not so easy. > So I tried to compare the values with the kirkwood. > > The current dump from the kernel: > --- > Unable to handle kernel NULL pointer dereference at virtual address 00000000 > pgd = dec3c000 > [00000000] *pgd=1fbd5031, *pte=00000000, *ppte=00000000 > Internal error: Oops: 17 [#1] PREEMPT > Modules linked in: mv_cesa(+) cryptodev(P) ocf(P) > CPU: 0 Tainted: P (2.6.31.14 #39) > PC is at mv_cesa_ocf_init+0x2a8/0x588 [mv_cesa] > LR is at mv_cesa_ocf_init+0x248/0x588 [mv_cesa] > pc : [<bf01aab4>] lr : [<bf01aa54>] psr: 40000013 > sp : dec0fea8 ip : 00001e3e fp : be97ae24 > r10: 00000000 r9 : dec0e000 r8 : bf032540 > r7 : c04ba968 r6 : 00000000 r5 : 00000000 r4 : 00000000 > r3 : 00000000 r2 : dec0fe9c r1 : bf0272cc r0 : 0000004f > Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user > Control: 0005397f Table: 1ec3c000 DAC: 00000015 > Process insmod (pid: 425, stack limit = 0xdec0e270) > Stack: (0xdec0fea8 to 0xdec10000) > fea0: 00000000 00000000 00000001 c04ba970 c04ba970 bf031f70 > fec0: dfa3d0c0 c04d1d88 00000000 c0226b6c c04ba970 c0225c9c c04ba970 c04ba9a4 > fee0: bf031f70 dfa3d0c0 c04d1d88 c0225db0 00000000 c0225d50 bf031f70 c02254c0 > ff00: df8035b8 df81cb10 00000000 00000060 bf031f70 c0224dd0 bf0274a2 bf0274a2 > ff20: dec0ff20 00000000 bf032340 bf031f70 00000000 c0026ae8 00000000 c0226084 > ff40: 00000000 bf032340 bf035000 00000000 c0026ae8 bf03500c 00000000 c002631c > ff60: 00000000 bf032340 000c8082 401dd008 c0026ae8 00000000 bf032340 000c8082 > ff80: 401dd008 c00733f0 401dd008 0028d614 000c8082 be97ae24 00000000 00000069 > ffa0: 00000080 c0026940 be97ae24 00000000 401dd008 0028d614 000c8082 00000000 > ffc0: be97ae24 00000000 00000069 00000080 00000001 00000002 be97ae28 be97ae24 > ffe0: be97ae24 be97aaec 000225f0 40177ba4 60000010 401dd008 feedfeed feedfeed > [<bf01aab4>] (mv_cesa_ocf_init+0x2a8/0x588 [mv_cesa]) from [<c0226b6c>] (platform_drv_probe+0x14/0x18) > [<c0226b6c>] (platform_drv_probe+0x14/0x18) from [<c0225c9c>] (driver_probe_device+0xa8/0x15c) > [<c0225c9c>] (driver_probe_device+0xa8/0x15c) from [<c0225db0>] (__driver_attach+0x60/0x84) > [<c0225db0>] (__driver_attach+0x60/0x84) from [<c02254c0>] (bus_for_each_dev+0x44/0x74) > [<c02254c0>] (bus_for_each_dev+0x44/0x74) from [<c0224dd0>] (bus_add_driver+0x134/0x2bc) > [<c0224dd0>] (bus_add_driver+0x134/0x2bc) from [<c0226084>] (driver_register+0xa8/0x130) > [<c0226084>] (driver_register+0xa8/0x130) from [<bf03500c>] (mv_cesa_init+0xc/0x3c [mv_cesa]) > [<bf03500c>] (mv_cesa_init+0xc/0x3c [mv_cesa]) from [<c002631c>] (do_one_initcall+0x5c/0x1bc) > [<c002631c>] (do_one_initcall+0x5c/0x1bc) from [<c00733f0>] (sys_init_module+0xb0/0x1c4) > [<c00733f0>] (sys_init_module+0xb0/0x1c4) from [<c0026940>] (ret_fast_syscall+0x0/0x2c) > Code: e590300c e7823001 e59f8224 e5983008 (e5932000) > ---[ end trace dd976c01f3fc5834 ]--- > Segmentation fault > --- > > Any ideas or hints for the right settings are welcome. > > Thanks. > > Patrick > > -----Original Message----- > From: David McCullough [mailto:dav...@mc...] > Sent: Monday, August 23, 2010 4:54 AM > To: Flaig, Patrick > Cc: ocf...@li... > Subject: Re: [Ocf-linux-users] OCF driver for Marvell Kirkwood (88F6xxx) Processors > > > Jivin Flaig, Patrick lays it down ... >> Hi David, >> >> I compiled the cryptotest for my target platform, and get the >> following response from the program when using > > Looks like you driver isn't loading fully, it most certainly has registered with OCF based on this output. > > You will need to trace your drivers startup and check that it calls crypto_register. > > My guess is that it isn't, > > Cheers, > Davidm > >> cryptosoft driver: >> >> sh-3.2# ./cryptotest >> cryptodev_open() >> cryptodev_ioctl(cmd=c0046364 arg=be8979bc) >> cryptodev_ioctl(CRIOGET) >> cryptodev_ioctl(cmd=c030636a arg=be897a1c) >> cryptodev_ioctl(CIOCGSESSION2) >> cryptodev_ioctl(CIOCGSESSION2) - no mac >> crypto/ocf/crypto.c,389: DRIVER_LOCK() >> crypto/ocf/crypto.c,413: DRIVER_UNLOCK() >> crypto/ocf/crypto.c,415: DRIVER_LOCK() >> crypto/ocf/crypto.c,425: DRIVER_UNLOCK() >> csecreate() >> cseadd() >> cryptodev_ioctl(cmd=c01c6367 arg=be897a00) >> cryptodev_ioctl(CIOCCRYPT) >> csefind() >> cryptodev_op() >> crypto_dispatch() >> crypto/ocf/crypto.c,815: Q_LOCK() >> crypto/ocf/crypto.c,839: Q_UNLOCK() >> crypto_invoke() >> crypto_done() >> crypto/ocf/crypto.c,1156: Q_LOCK() >> crypto/ocf/crypto.c,1158: Q_UNLOCK() >> cryptodev_cb() >> crypto/ocf/crypto.c,841: Q_LOCK() >> crypto/ocf/crypto.c,867: Q_UNLOCK() >> cryptodev_op about to WAIT >> cryptodev_op finished WAITING error=0 >> cryptodev_ioctl(cmd=c01c6367 arg=be897a00) >> cryptodev_ioctl(CIOCCRYPT) >> csefind() >> cryptodev_op() >> crypto_dispatch() >> crypto/ocf/crypto.c,815: Q_LOCK() >> crypto/ocf/crypto.c,839: Q_UNLOCK() >> crypto_invoke() >> crypto_done() >> crypto/ocf/crypto.c,1156: Q_LOCK() >> crypto/ocf/crypto.c,1158: Q_UNLOCK() >> cryptodev_cb() >> crypto/ocf/crypto.c,841: Q_LOCK() >> crypto/ocf/crypto.c,867: Q_UNLOCK() >> cryptodev_op about to WAIT >> cryptodev_op finished WAITING error=0 >> cryptodev_ioctl(cmd=40046366 arg=be897a34) >> cryptodev_ioctl(CIOCFSESSION) >> csefind() >> csedelete() >> csefree() >> crypto_freesession() >> crypto/ocf/crypto.c,450: DRIVER_LOCK() >> crypto/ocf/crypto.c,468: DRIVER_UNLOCK() >> crypto/ocf/crypto.c,471: DRIVER_LOCK() >> crypto/ocf/crypto.c,481: DRIVER_UNLOCK() >> 0.080 sec, cryptodev_release() >> 2 3des crypts, 8 bytes, 201 byte/sec, 0.0 Mb/sec >> >> >> feroceon driver: >> >> sh-3.2# ./cryptotest >> cryptodev_open() >> cryptodev_ioctl(cmd=c0046364 arg=bebe09bc) >> cryptodev_ioctl(CRIOGET) >> cryptodev_ioctl(cmd=c030636a arg=bebe0a1c) >> cryptodev_ioctl(CIOCGSESSION2) >> cryptodev_ioctl(CIOCGSESSION2) - no mac >> crypto/ocf/crypto.c,389: DRIVER_LOCK() >> crypto/ocf/crypto.c,425: DRIVER_UNLOCK() >> cryptodev_ioctl(CIOCGSESSION2) - newsession 22 >> cryptodev_ioctl(CIOCGSESSION2) - bail 22 >> cryptodev_release() >> >> A similar output when using my program: >> >> cryptodev_open() >> cryptodev_ioctl(cmd=c0046364 arg=befa0cd0) >> cryptodev_ioctl(CRIOGET) >> cryptodev_ioctl(cmd=c01c6365 arg=befa0af8) >> cryptodev_ioctl(CIOCGSESSION) >> cryptodev_ioctl(CIOCGSESSION) - no mac >> crypto/ocf/crypto.c,389: DRIVER_LOCK() >> crypto/ocf/crypto.c,425: DRIVER_UNLOCK() >> cryptodev_ioctl(CIOCGSESSION) - newsession 22 >> cryptodev_ioctl(CIOCGSESSION) - bail 22 >> cryptodev_release() >> >> >> Do you see any reason why the hardware driver is not working? >> >> Regards >> >> Patrick >> >> -----Urspr??ngliche Nachricht----- >> Von: David McCullough [mailto:dav...@mc...] >> Gesendet: Donnerstag, 19. August 2010 07:17 >> An: Flaig, Patrick >> Cc: ocf...@li... >> Betreff: Re: [Ocf-linux-users] OCF driver for Marvell Kirkwood >> (88F6xxx) Processors >> >> >> Jivin Flaig, Patrick lays it down ... >> > Hi David, >> > >> > Thanks for the feedback, ok now I know that cannot reference "/proc/crypto" for OCF details. >> > >> > But how can I check if the hardware driver is used or loaded? >> > >> > As said when I try to use an AES CBC algorithm with the Feroceon driver I'm getting in invalid argument error. >> > --- >> > /* Get crypto session for AES128 */ >> > sess.cipher = CRYPTO_AES_CBC; >> > sess.keylen = KEY_SIZE; >> > sess.key = key; >> > if (ioctl(cfd, CIOCGSESSION, &sess)) { >> > perror("ioctl(CIOCGSESSION)"); >> > return 1; >> > } >> > --- >> > >> > With the software driver no problem! >> > >> > Some time ago I did some measurements with the original Marvell SDK Kernel for the Feroceon. Without HW driver I was able to encrypt about 9 MB/s, with HW support 36 MB/s. >> > If I now do the same measurements again with loaded SW and HW driver I'm only getting a rate about 9 MB/s, which leads to the speculation that only the software driver is working. >> > Is there a way to check if the hardware driver is working? >> >> I did cover this in my previous email. Check below. >> >> Turning on debug will let you know if the driver is active or not and >> tell you lots more. Not debug while working means the driver is not being used. >> >> Debug should also give you a detailed reason why EINVAL is being returned. >> It will at least tell you the line/area the failure originated from. >> >> The debug will come out on the console/system log or somewhere. >> Whereever you kernel trace comes out. >> >> Please try building and using the cryptotest program as well. I know >> you have you own code, but the cryptotest program isa known quantity >> and I know it does everything right ;-) >> >> Cheers, >> Davidm >> >> > -----Original Message----- >> > From: David McCullough [mailto:dav...@mc...] >> > Sent: Tuesday, August 17, 2010 1:24 AM >> > To: Flaig, Patrick >> > Cc: ocf...@li... >> > Subject: Re: [Ocf-linux-users] OCF driver for Marvell Kirkwood >> > (88F6xxx) Processors >> > >> > >> > Jivin Flaig, Patrick lays it down ... >> > > Hi David, >> > > >> > > Thanks a lot, the additional lines in the Makefile let me compile the Feroceon driver. >> > > >> > > I've now compiled the OCF module and the driver directly into the kernel. >> > > >> > > I think I've now an understanding problem, how to configure OCF the right way. >> > > Do I have to configure the cryptographic API as well, with all the algorithms I want? >> > > How can I make sure that, if I have selected AES for example, the hardware acceleration is used? >> > > /proc/crypto is only showing module: kernel. >> > >> > OCF doesn't register with /proc/crypto as it is not part of the kernel crypto. >> > >> > If you only have one OCF driver loaded then only that option can be used. >> > >> > OCF, by default, preferrs HW drivers over SW drivers. Of source this only matters if you have more than one OCF crypto driver loaded, and one is SW. >> > >> > Jivin Flaig, Patrick lays it down ... >> > > Hi David, >> > > >> > > I tried to do some measurements with the Feroceon driver and run into some problems. >> > > It seems the hardware support is not fully working. >> > > >> > > I configured OCF to use the CRYPTOSOFT driver and run a little test application, everything works fine. >> > > But when I disabled the CRYPTOSOFT driver and enabled the FEROCEON driver, my test failed with an "ioctl(CIOCGSESSION): Invalid argument" error. >> > > >> > > --- >> > > /* Get crypto session for AES128 */ >> > > sess.cipher = CRYPTO_AES_CBC; >> > > sess.keylen = KEY_SIZE; >> > > sess.key = key; >> > > if (ioctl(cfd, CIOCGSESSION, &sess)) { >> > > perror("ioctl(CIOCGSESSION)"); >> > > return 1; >> > > } >> > > --- >> > > >> > > For me this looks like the driver is not loaded. >> > > Did I forget to configure something? >> > >> > This sounds like either the driver is not loaded and registered properly. >> > You said you have compiled everytihng into the kernel ? It might be easier to use modules so you can debug it more easily (add trace etc). >> > >> > Try turning on debug in the ocf and crypto drivers before you load your driver. >> > >> > echo 1 > /sys/module/ocf/parameters/crypto_debug >> > echo 1 > /sys/module/cryptodev/parameters/cryptodev_debug >> > >> > Make sure your driver is registering with OCF for the alg's you want. >> > >> > > How will OCF handle algorithms that are not supported by the hardware, will the OCF switch to the kernel algorithm? >> > >> > No, OCF has no fall back, it can only use the drivers that you have loaded. If you want it to fall back to kernel SW versions you need to load cryptosoft. OCF will use HW versions in preference to SW versions. >> > >> > > Do I have to enable the CRYPTOSOFT in combination with the hardware driver? >> > >> > No. And while you are debugging your driver I recommend only loading one driver (feroceon). >> > >> > Get the cryptotest app that in bundled in with the OCF release and use that to test your OCF driver. It can do everything you need to help debug the driver and is very simple code that talks direct to OCF via /dev/crypto. >> > >> > Cheers, >> > Davidm >> > >> > -- >> > David McCullough, dav...@mc..., Ph:+61 734352815 >> > McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org >> > >> > >> >> -- >> David McCullough, dav...@mc..., Ph:+61 734352815 >> McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org >> >> > > -- > David McCullough, dav...@mc..., Ph:+61 734352815 > McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org > > ------------------------------------------------------------------------------ > Sell apps to millions through the Intel(R) Atom(Tm) Developer Program > Be part of this innovative community and reach millions of netbook users > worldwide. Take advantage of special opportunities to increase revenue and > speed time-to-market. Join now, and jumpstart your future. > http://p.sf.net/sfu/intel-atom-d2d > _______________________________________________ > Ocf-linux-users mailing list > Ocf...@li... > https://lists.sourceforge.net/lists/listinfo/ocf-linux-users > |
|
From: David M. <dav...@mc...> - 2010-08-25 05:28:43
|
Jivin Harro Haan lays it down ... > Problem solved! > > INTER_REGS_BASE (in mvSysHwConfig.h) had the value 0xFEE00000. This is > the same as KIRKWOOD_PCIE_IO_VIRT_BASE in > linux-2.6.33/arch/arm/mach-kirkwood/include/mach/kirkwood.h. For my > configuration it should be KIRKWOOD_REGS_VIRT_BASE, which is > 0xfed00000. > > Why does the define INTER_REGS_BASE exist? Would it not be cleaner to > use ??cesa_device.reg?? instead (set by platform_get_resource_byname() > in cesa_ocf_drv.c)? Beats me, Marvel would be best to answer that one :-) I will say that if the driver isn't working (ie., no interrupts etc), you will get locked applications waiting for completion. Due to the nature of DMA/crypto processing, terminating early or timing out is just a bad idea, and besides, you need to fix the driver regardless. Luckily you found it and can move on :-) Cheers, Davidm > > On 23 August 2010 16:47, Harro Haan <hr...@gm...> wrote: > > Some additional info, > > > > When I define CESA_OCF_POLLING in cesa_ocf_drv.c everything works fine. > > > > When I do "cat /proc/interrupts" (with #undef CESA_OCF_POLLING), I can > > see that no cesa interrupts occurred. When I look at the debug output > > (see previous mail) I do not see the line "cesa_interrupt_handler()" > > either. > > > > So for my configuration something is wrong/missing with my interrupts. > > Any hints? > > > > Thanks, > > > > Harro > > > > On 20 August 2010 16:52, Harro Haan <hr...@gm...> wrote: > >> Hello David, > >> > >> I??m trying to get this driver working with a 3.6.33 kernel on my > >> OpenRD-Ultimate 88F6281 development board, but the cryptotest program > >> is waiting forever. > >> > >> Debug output for mv_cesa: > >> ------------------------------------ > >> root@DB88FXX81:/ ./cryptotest -a aes > >> cryptodev_open() > >> cryptodev_ioctl(cmd=c0046364 arg=beea0954) > >> cryptodev_ioctl(CRIOGET) > >> cryptodev_ioctl(cmd=c030636a arg=beea09b4) > >> cryptodev_ioctl(CIOCGSESSION2) > >> cryptodev_ioctl(CIOCGSESSION2) - no mac > >> crypto/ocf/crypto.c,389: DRIVER_LOCK() > >> crypto/ocf/crypto.c,413: DRIVER_UNLOCK() > >> cesa_ocf_newsession() > >> crypto/ocf/kirkwood/cesa_ocf_drv.c,875: new session 1 > >> crypto/ocf/kirkwood/cesa_ocf_drv.c,896: (1) AES CBC > >> crypto/ocf/kirkwood/cesa_ocf_drv.c,906: key length 16 > >> crypto/ocf/crypto.c,415: DRIVER_LOCK() > >> crypto/ocf/crypto.c,425: DRIVER_UNLOCK() > >> csecreate() > >> cseadd() > >> cryptodev_ioctl(cmd=c01c6367 arg=beea0998) > >> cryptodev_ioctl(CIOCCRYPT) > >> csefind() > >> cryptodev_op() > >> crypto_dispatch() > >> crypto/ocf/crypto.c,815: Q_LOCK() > >> crypto/ocf/crypto.c,839: Q_UNLOCK() > >> crypto_invoke() > >> cesa_ocf_process() > >> crypto/ocf/kirkwood/cesa_ocf_drv.c,425: handle UIO. > >> crypto/ocf/kirkwood/cesa_ocf_drv.c,440: buf 0-> addr ded17500, size 10 > >> crypto/ocf/kirkwood/cesa_ocf_drv.c,480: cipher encrypt > >> crypto/ocf/kirkwood/cesa_ocf_drv.c,491: IV from USER (offset 0) > >> crypto/ocf/kirkwood/cesa_ocf_drv.c,508: don't copy the IV back to the buffer > >> > >> crypto/ocf/kirkwood/cesa_ocf_drv.c,596: Sending Action: > >> crypto/ocf/kirkwood/cesa_ocf_drv.c,597: IV from user: 1. IV offset 0 > >> crypto/ocf/kirkwood/cesa_ocf_drv.c,598: crypt offset 10 len 10 > >> crypto/ocf/kirkwood/cesa_ocf_drv.c,599: Auth offset 0 len 0 > >> crypto/ocf/kirkwood/cesa_ocf_drv.c,600: set digest in offset 0 . > >> SRC BUFFER: pMbuf=dfa4bc24, numFrags=2, mbufSize=32 > >> # 0. bufVirt=df8ee020, bufSize=16 > >> df8ee020: 33 35 38 36 74 34 69 6f 68 33 75 21 75 36 34 39 > >> # 1. bufVirt=ded17500, bufSize=16 > >> ded17500: 6e 33 38 39 34 36 6f 74 38 69 74 39 31 65 75 6e > >> crypto/ocf/crypto.c,841: Q_LOCK() > >> crypto/ocf/crypto.c,867: Q_UNLOCK() > >> cryptodev_op about to WAIT > >> > >> ------------------------------------ > >> > >> Debug output for cryptosoft (which is working just fine): > >> ------------------------------------ > >> root@DB88FXX81:/ ./cryptotest -a aes > >> cryptodev_open() > >> cryptodev_ioctl(cmd=c0046364 arg=bea58954) > >> cryptodev_ioctl(CRIOGET) > >> cryptodev_ioctl(cmd=c030636a arg=bea589b4) > >> cryptodev_ioctl(CIOCGSESSION2) > >> cryptodev_ioctl(CIOCGSESSION2) - no mac > >> crypto/ocf/crypto.c,389: DRIVER_LOCK() > >> crypto/ocf/crypto.c,413: DRIVER_UNLOCK() > >> swcr_newsession() > >> swcr_newsession crypto_alloc_*blkcipher(cbc(aes), 0x0) > >> swcr_newsession cbc(aes) cipher is async > >> swcr_newsession key:cri->cri_klen=128,(cri->cri_klen + 7)/8=16 > >> ?? ??0x32 0x61 0x38 0x6f 0x21 0x32 0x61 0x61 > >> ?? ??0x21 0x35 0x75 0x21 0x69 0x30 0x65 0x21 > >> crypto/ocf/crypto.c,415: DRIVER_LOCK() > >> crypto/ocf/crypto.c,425: DRIVER_UNLOCK() > >> csecreate() > >> cseadd() > >> cryptodev_ioctl(cmd=c01c6367 arg=bea58998) > >> cryptodev_ioctl(CIOCCRYPT) > >> csefind() > >> cryptodev_op() > >> crypto_dispatch() > >> crypto/ocf/crypto.c,815: Q_LOCK() > >> crypto/ocf/crypto.c,839: Q_UNLOCK() > >> crypto_invoke() > >> swcr_process() > >> swcr_process_req() > >> crypto OP success 0 > >> crypto_done() > >> crypto/ocf/crypto.c,1156: Q_LOCK() > >> crypto/ocf/crypto.c,1158: Q_UNLOCK() > >> cryptodev_cb() > >> crypto/ocf/crypto.c,841: Q_LOCK() > >> crypto/ocf/crypto.c,867: Q_UNLOCK() > >> cryptodev_op about to WAIT > >> cryptodev_op finished WAITING error=0 > >> cryptodev_ioctl(cmd=c01c6367 arg=bea58998) > >> cryptodev_ioctl(CIOCCRYPT) > >> csefind() > >> cryptodev_op() > >> crypto_dispatch() > >> crypto/ocf/crypto.c,815: Q_LOCK() > >> crypto/ocf/crypto.c,839: Q_UNLOCK() > >> crypto_invoke() > >> swcr_process() > >> swcr_process_req() > >> crypto OP success 0 > >> crypto_done() > >> crypto/ocf/crypto.c,1156: Q_LOCK() > >> crypto/ocf/crypto.c,1158: Q_UNLOCK() > >> cryptodev_cb() > >> crypto/ocf/crypto.c,841: Q_LOCK() > >> crypto/ocf/crypto.c,867: Q_UNLOCK() > >> cryptodev_op about to WAIT > >> cryptodev_op finished WAITING error=0 > >> cryptodev_ioctl(cmd=40046366 arg=bea589cc) > >> cryptodev_ioctl(CIOCFSESSION) > >> csefind() > >> csedelete() > >> csefree() > >> crypto_freesession() > >> crypto/ocf/crypto.c,450: DRIVER_LOCK() > >> crypto/ocf/crypto.c,468: DRIVER_UNLOCK() > >> swcr_freesession() > >> crypto/ocf/crypto.c,471: DRIVER_LOCK() > >> crypto/ocf/crypto.c,481: DRIVER_UNLOCK() > >> ?? 0.089 sec, ?? cryptodev_release() > >> ?? ??2 ?? ??aes crypts, ?? ?? ??16 bytes, ?? ?? ??358 byte/sec, ?? ?? 0.0 Mb/sec > >> root@DB88FXX81:/ > >> ------------------------------------ > >> > >> I am following this thread as well: > >> ??[Ocf-linux-users] OCF driver for Marvell Kirkwood (88F6xxx) Processors?? > >> http://sourceforge.net/mailarchive/forum.php?thread_name=8D145DCD0F55B543949BE94258003A200DF9AD4EA6%40exchange12.bdt-rw.de&forum_name=ocf-linux-users > >> > >> Attached are my patches (fixes as described in the thread above) and > >> series file. > >> > >> Do you have an idea why the system is hanging/waiting forever? > >> > >> Thanks, > >> > >> Harro > >> > > > > -- David McCullough, dav...@mc..., Ph:+61 734352815 McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org |
|
From: David M. <dav...@mc...> - 2010-08-25 05:25:11
|
Jivin Flaig, Patrick lays it down ...
> Hello David,
>
> I found the reason, why the driver is not working.
> The complete device registration was missing for mach-mv78xx0.
>
> I now tried to add that but still have some problems with a crashing driver.
>
> To common.c I added
>
> /*****************************************************************************
> * Cryptographic Engines and Security Accelerator (CESA)
> ****************************************************************************/
>
> static struct resource mv78xx0_crypto_resources[] = {
> {
> .name = "regs",
> .start = CRYPTO_PHYS_BASE,
> .end = CRYPTO_PHYS_BASE + 0xffff,
> .flags = IORESOURCE_MEM,
> }, {
> .name = "sram",
> .start = MV78XX0_SRAM_PHYS_BASE,
> .end = MV78XX0_SRAM_PHYS_BASE + MV78XX0_SRAM_SIZE - 1,
> .flags = IORESOURCE_MEM,
> }, {
> .name = "crypto interrupt",
> .start = IRQ_MV78XX0_CRYPTO,
> .end = IRQ_MV78XX0_CRYPTO,
> .flags = IORESOURCE_IRQ,
> },
> };
>
> static struct platform_device mv78xx0_crypto = {
> .name = "mv_crypto",
> .id = -1,
> .num_resources = ARRAY_SIZE(mv78xx0_crypto_resources),
> .resource = mv78xx0_crypto_resources,
> };
>
> void __init mv78xx0_crypto_init(void)
> {
> //kirkwood_clk_ctrl |= CGC_CRYPTO;
> platform_device_register(&mv78xx0_crypto);
> }
>
> With the following settings (mv78xx0.h)
>
> #define MV78XX0_SRAM_PHYS_BASE 0xf7000000
> #define MV78XX0_SRAM_SIZE SZ_2K
> #define CRYPTO_PHYS_BASE (MV78XX0_REGS_PHYS_BASE | 0x90000)
>
> When loading the OCF driver for the feroceon it is crashing in setup_tdma_mbus_windows(...) in the following loop
>
> for (i = 0; i < dev->plat_data->dram->num_cs; i++) {
> struct mbus_dram_window *cs = dev->plat_data->dram->cs + i;
> writel(
> ((cs->size - 1) & 0xffff0000) |
> (cs->mbus_attr << 8) |
> (dev->plat_data->dram->mbus_dram_target_id << 4) | 1,
> dev->reg + WINDOW_CTRL(i)
> );
> writel(cs->base, dev->reg + WINDOW_BASE(i));
> }
>
>
> I think the SRAM configuration or something isn't set correct, but to get the correct values from the Feroceon documentation is not so easy.
> So I tried to compare the values with the kirkwood.
>
> The current dump from the kernel:
> ---
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
> pgd = dec3c000
> [00000000] *pgd=1fbd5031, *pte=00000000, *ppte=00000000
> Internal error: Oops: 17 [#1] PREEMPT
> Modules linked in: mv_cesa(+) cryptodev(P) ocf(P)
> CPU: 0 Tainted: P (2.6.31.14 #39)
> PC is at mv_cesa_ocf_init+0x2a8/0x588 [mv_cesa]
> LR is at mv_cesa_ocf_init+0x248/0x588 [mv_cesa]
> pc : [<bf01aab4>] lr : [<bf01aa54>] psr: 40000013
> sp : dec0fea8 ip : 00001e3e fp : be97ae24
> r10: 00000000 r9 : dec0e000 r8 : bf032540
> r7 : c04ba968 r6 : 00000000 r5 : 00000000 r4 : 00000000
> r3 : 00000000 r2 : dec0fe9c r1 : bf0272cc r0 : 0000004f
> Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
> Control: 0005397f Table: 1ec3c000 DAC: 00000015
> Process insmod (pid: 425, stack limit = 0xdec0e270)
> Stack: (0xdec0fea8 to 0xdec10000)
> fea0: 00000000 00000000 00000001 c04ba970 c04ba970 bf031f70
> fec0: dfa3d0c0 c04d1d88 00000000 c0226b6c c04ba970 c0225c9c c04ba970 c04ba9a4
> fee0: bf031f70 dfa3d0c0 c04d1d88 c0225db0 00000000 c0225d50 bf031f70 c02254c0
> ff00: df8035b8 df81cb10 00000000 00000060 bf031f70 c0224dd0 bf0274a2 bf0274a2
> ff20: dec0ff20 00000000 bf032340 bf031f70 00000000 c0026ae8 00000000 c0226084
> ff40: 00000000 bf032340 bf035000 00000000 c0026ae8 bf03500c 00000000 c002631c
> ff60: 00000000 bf032340 000c8082 401dd008 c0026ae8 00000000 bf032340 000c8082
> ff80: 401dd008 c00733f0 401dd008 0028d614 000c8082 be97ae24 00000000 00000069
> ffa0: 00000080 c0026940 be97ae24 00000000 401dd008 0028d614 000c8082 00000000
> ffc0: be97ae24 00000000 00000069 00000080 00000001 00000002 be97ae28 be97ae24
> ffe0: be97ae24 be97aaec 000225f0 40177ba4 60000010 401dd008 feedfeed feedfeed
> [<bf01aab4>] (mv_cesa_ocf_init+0x2a8/0x588 [mv_cesa]) from [<c0226b6c>] (platform_drv_probe+0x14/0x18)
> [<c0226b6c>] (platform_drv_probe+0x14/0x18) from [<c0225c9c>] (driver_probe_device+0xa8/0x15c)
> [<c0225c9c>] (driver_probe_device+0xa8/0x15c) from [<c0225db0>] (__driver_attach+0x60/0x84)
> [<c0225db0>] (__driver_attach+0x60/0x84) from [<c02254c0>] (bus_for_each_dev+0x44/0x74)
> [<c02254c0>] (bus_for_each_dev+0x44/0x74) from [<c0224dd0>] (bus_add_driver+0x134/0x2bc)
> [<c0224dd0>] (bus_add_driver+0x134/0x2bc) from [<c0226084>] (driver_register+0xa8/0x130)
> [<c0226084>] (driver_register+0xa8/0x130) from [<bf03500c>] (mv_cesa_init+0xc/0x3c [mv_cesa])
> [<bf03500c>] (mv_cesa_init+0xc/0x3c [mv_cesa]) from [<c002631c>] (do_one_initcall+0x5c/0x1bc)
> [<c002631c>] (do_one_initcall+0x5c/0x1bc) from [<c00733f0>] (sys_init_module+0xb0/0x1c4)
> [<c00733f0>] (sys_init_module+0xb0/0x1c4) from [<c0026940>] (ret_fast_syscall+0x0/0x2c)
> Code: e590300c e7823001 e59f8224 e5983008 (e5932000)
> ---[ end trace dd976c01f3fc5834 ]---
> Segmentation fault
> ---
>
> Any ideas or hints for the right settings are welcome.
Nothing from me really. I would be surprised if Marvel don't already have
support for this in their source tree. I would try there. They have been
pretty good OSS citizens and getting the code etc never seemed too hard.
I would also expect they have a working feroceon/ocf driver as well, could
be wrong though ;-)
Cheers,
Davidm
> -----Original Message-----
> From: David McCullough [mailto:dav...@mc...]
> Sent: Monday, August 23, 2010 4:54 AM
> To: Flaig, Patrick
> Cc: ocf...@li...
> Subject: Re: [Ocf-linux-users] OCF driver for Marvell Kirkwood (88F6xxx) Processors
>
>
> Jivin Flaig, Patrick lays it down ...
> > Hi David,
> >
> > I compiled the cryptotest for my target platform, and get the
> > following response from the program when using
>
> Looks like you driver isn't loading fully, it most certainly has registered with OCF based on this output.
>
> You will need to trace your drivers startup and check that it calls crypto_register.
>
> My guess is that it isn't,
>
> Cheers,
> Davidm
>
> > cryptosoft driver:
> >
> > sh-3.2# ./cryptotest
> > cryptodev_open()
> > cryptodev_ioctl(cmd=c0046364 arg=be8979bc)
> > cryptodev_ioctl(CRIOGET)
> > cryptodev_ioctl(cmd=c030636a arg=be897a1c)
> > cryptodev_ioctl(CIOCGSESSION2)
> > cryptodev_ioctl(CIOCGSESSION2) - no mac
> > crypto/ocf/crypto.c,389: DRIVER_LOCK()
> > crypto/ocf/crypto.c,413: DRIVER_UNLOCK()
> > crypto/ocf/crypto.c,415: DRIVER_LOCK()
> > crypto/ocf/crypto.c,425: DRIVER_UNLOCK()
> > csecreate()
> > cseadd()
> > cryptodev_ioctl(cmd=c01c6367 arg=be897a00)
> > cryptodev_ioctl(CIOCCRYPT)
> > csefind()
> > cryptodev_op()
> > crypto_dispatch()
> > crypto/ocf/crypto.c,815: Q_LOCK()
> > crypto/ocf/crypto.c,839: Q_UNLOCK()
> > crypto_invoke()
> > crypto_done()
> > crypto/ocf/crypto.c,1156: Q_LOCK()
> > crypto/ocf/crypto.c,1158: Q_UNLOCK()
> > cryptodev_cb()
> > crypto/ocf/crypto.c,841: Q_LOCK()
> > crypto/ocf/crypto.c,867: Q_UNLOCK()
> > cryptodev_op about to WAIT
> > cryptodev_op finished WAITING error=0
> > cryptodev_ioctl(cmd=c01c6367 arg=be897a00)
> > cryptodev_ioctl(CIOCCRYPT)
> > csefind()
> > cryptodev_op()
> > crypto_dispatch()
> > crypto/ocf/crypto.c,815: Q_LOCK()
> > crypto/ocf/crypto.c,839: Q_UNLOCK()
> > crypto_invoke()
> > crypto_done()
> > crypto/ocf/crypto.c,1156: Q_LOCK()
> > crypto/ocf/crypto.c,1158: Q_UNLOCK()
> > cryptodev_cb()
> > crypto/ocf/crypto.c,841: Q_LOCK()
> > crypto/ocf/crypto.c,867: Q_UNLOCK()
> > cryptodev_op about to WAIT
> > cryptodev_op finished WAITING error=0
> > cryptodev_ioctl(cmd=40046366 arg=be897a34)
> > cryptodev_ioctl(CIOCFSESSION)
> > csefind()
> > csedelete()
> > csefree()
> > crypto_freesession()
> > crypto/ocf/crypto.c,450: DRIVER_LOCK()
> > crypto/ocf/crypto.c,468: DRIVER_UNLOCK()
> > crypto/ocf/crypto.c,471: DRIVER_LOCK()
> > crypto/ocf/crypto.c,481: DRIVER_UNLOCK()
> > 0.080 sec, cryptodev_release()
> > 2 3des crypts, 8 bytes, 201 byte/sec, 0.0 Mb/sec
> >
> >
> > feroceon driver:
> >
> > sh-3.2# ./cryptotest
> > cryptodev_open()
> > cryptodev_ioctl(cmd=c0046364 arg=bebe09bc)
> > cryptodev_ioctl(CRIOGET)
> > cryptodev_ioctl(cmd=c030636a arg=bebe0a1c)
> > cryptodev_ioctl(CIOCGSESSION2)
> > cryptodev_ioctl(CIOCGSESSION2) - no mac
> > crypto/ocf/crypto.c,389: DRIVER_LOCK()
> > crypto/ocf/crypto.c,425: DRIVER_UNLOCK()
> > cryptodev_ioctl(CIOCGSESSION2) - newsession 22
> > cryptodev_ioctl(CIOCGSESSION2) - bail 22
> > cryptodev_release()
> >
> > A similar output when using my program:
> >
> > cryptodev_open()
> > cryptodev_ioctl(cmd=c0046364 arg=befa0cd0)
> > cryptodev_ioctl(CRIOGET)
> > cryptodev_ioctl(cmd=c01c6365 arg=befa0af8)
> > cryptodev_ioctl(CIOCGSESSION)
> > cryptodev_ioctl(CIOCGSESSION) - no mac
> > crypto/ocf/crypto.c,389: DRIVER_LOCK()
> > crypto/ocf/crypto.c,425: DRIVER_UNLOCK()
> > cryptodev_ioctl(CIOCGSESSION) - newsession 22
> > cryptodev_ioctl(CIOCGSESSION) - bail 22
> > cryptodev_release()
> >
> >
> > Do you see any reason why the hardware driver is not working?
> >
> > Regards
> >
> > Patrick
> >
> > -----Urspr??ngliche Nachricht-----
> > Von: David McCullough [mailto:dav...@mc...]
> > Gesendet: Donnerstag, 19. August 2010 07:17
> > An: Flaig, Patrick
> > Cc: ocf...@li...
> > Betreff: Re: [Ocf-linux-users] OCF driver for Marvell Kirkwood
> > (88F6xxx) Processors
> >
> >
> > Jivin Flaig, Patrick lays it down ...
> > > Hi David,
> > >
> > > Thanks for the feedback, ok now I know that cannot reference "/proc/crypto" for OCF details.
> > >
> > > But how can I check if the hardware driver is used or loaded?
> > >
> > > As said when I try to use an AES CBC algorithm with the Feroceon driver I'm getting in invalid argument error.
> > > ---
> > > /* Get crypto session for AES128 */
> > > sess.cipher = CRYPTO_AES_CBC;
> > > sess.keylen = KEY_SIZE;
> > > sess.key = key;
> > > if (ioctl(cfd, CIOCGSESSION, &sess)) {
> > > perror("ioctl(CIOCGSESSION)");
> > > return 1;
> > > }
> > > ---
> > >
> > > With the software driver no problem!
> > >
> > > Some time ago I did some measurements with the original Marvell SDK Kernel for the Feroceon. Without HW driver I was able to encrypt about 9 MB/s, with HW support 36 MB/s.
> > > If I now do the same measurements again with loaded SW and HW driver I'm only getting a rate about 9 MB/s, which leads to the speculation that only the software driver is working.
> > > Is there a way to check if the hardware driver is working?
> >
> > I did cover this in my previous email. Check below.
> >
> > Turning on debug will let you know if the driver is active or not and
> > tell you lots more. Not debug while working means the driver is not being used.
> >
> > Debug should also give you a detailed reason why EINVAL is being returned.
> > It will at least tell you the line/area the failure originated from.
> >
> > The debug will come out on the console/system log or somewhere.
> > Whereever you kernel trace comes out.
> >
> > Please try building and using the cryptotest program as well. I know
> > you have you own code, but the cryptotest program isa known quantity
> > and I know it does everything right ;-)
> >
> > Cheers,
> > Davidm
> >
> > > -----Original Message-----
> > > From: David McCullough [mailto:dav...@mc...]
> > > Sent: Tuesday, August 17, 2010 1:24 AM
> > > To: Flaig, Patrick
> > > Cc: ocf...@li...
> > > Subject: Re: [Ocf-linux-users] OCF driver for Marvell Kirkwood
> > > (88F6xxx) Processors
> > >
> > >
> > > Jivin Flaig, Patrick lays it down ...
> > > > Hi David,
> > > >
> > > > Thanks a lot, the additional lines in the Makefile let me compile the Feroceon driver.
> > > >
> > > > I've now compiled the OCF module and the driver directly into the kernel.
> > > >
> > > > I think I've now an understanding problem, how to configure OCF the right way.
> > > > Do I have to configure the cryptographic API as well, with all the algorithms I want?
> > > > How can I make sure that, if I have selected AES for example, the hardware acceleration is used?
> > > > /proc/crypto is only showing module: kernel.
> > >
> > > OCF doesn't register with /proc/crypto as it is not part of the kernel crypto.
> > >
> > > If you only have one OCF driver loaded then only that option can be used.
> > >
> > > OCF, by default, preferrs HW drivers over SW drivers. Of source this only matters if you have more than one OCF crypto driver loaded, and one is SW.
> > >
> > > Jivin Flaig, Patrick lays it down ...
> > > > Hi David,
> > > >
> > > > I tried to do some measurements with the Feroceon driver and run into some problems.
> > > > It seems the hardware support is not fully working.
> > > >
> > > > I configured OCF to use the CRYPTOSOFT driver and run a little test application, everything works fine.
> > > > But when I disabled the CRYPTOSOFT driver and enabled the FEROCEON driver, my test failed with an "ioctl(CIOCGSESSION): Invalid argument" error.
> > > >
> > > > ---
> > > > /* Get crypto session for AES128 */
> > > > sess.cipher = CRYPTO_AES_CBC;
> > > > sess.keylen = KEY_SIZE;
> > > > sess.key = key;
> > > > if (ioctl(cfd, CIOCGSESSION, &sess)) {
> > > > perror("ioctl(CIOCGSESSION)");
> > > > return 1;
> > > > }
> > > > ---
> > > >
> > > > For me this looks like the driver is not loaded.
> > > > Did I forget to configure something?
> > >
> > > This sounds like either the driver is not loaded and registered properly.
> > > You said you have compiled everytihng into the kernel ? It might be easier to use modules so you can debug it more easily (add trace etc).
> > >
> > > Try turning on debug in the ocf and crypto drivers before you load your driver.
> > >
> > > echo 1 > /sys/module/ocf/parameters/crypto_debug
> > > echo 1 > /sys/module/cryptodev/parameters/cryptodev_debug
> > >
> > > Make sure your driver is registering with OCF for the alg's you want.
> > >
> > > > How will OCF handle algorithms that are not supported by the hardware, will the OCF switch to the kernel algorithm?
> > >
> > > No, OCF has no fall back, it can only use the drivers that you have loaded. If you want it to fall back to kernel SW versions you need to load cryptosoft. OCF will use HW versions in preference to SW versions.
> > >
> > > > Do I have to enable the CRYPTOSOFT in combination with the hardware driver?
> > >
> > > No. And while you are debugging your driver I recommend only loading one driver (feroceon).
> > >
> > > Get the cryptotest app that in bundled in with the OCF release and use that to test your OCF driver. It can do everything you need to help debug the driver and is very simple code that talks direct to OCF via /dev/crypto.
> > >
> > > Cheers,
> > > Davidm
> > >
> > > --
> > > David McCullough, dav...@mc..., Ph:+61 734352815
> > > McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org
> > >
> > >
> >
> > --
> > David McCullough, dav...@mc..., Ph:+61 734352815
> > McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org
> >
> >
>
> --
> David McCullough, dav...@mc..., Ph:+61 734352815
> McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org
>
>
--
David McCullough, dav...@mc..., Ph:+61 734352815
McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org
|
|
From: Flaig, P. <Pat...@bd...> - 2010-08-24 16:15:58
|
Hello David,
I found the reason, why the driver is not working.
The complete device registration was missing for mach-mv78xx0.
I now tried to add that but still have some problems with a crashing driver.
To common.c I added
/*****************************************************************************
* Cryptographic Engines and Security Accelerator (CESA)
****************************************************************************/
static struct resource mv78xx0_crypto_resources[] = {
{
.name = "regs",
.start = CRYPTO_PHYS_BASE,
.end = CRYPTO_PHYS_BASE + 0xffff,
.flags = IORESOURCE_MEM,
}, {
.name = "sram",
.start = MV78XX0_SRAM_PHYS_BASE,
.end = MV78XX0_SRAM_PHYS_BASE + MV78XX0_SRAM_SIZE - 1,
.flags = IORESOURCE_MEM,
}, {
.name = "crypto interrupt",
.start = IRQ_MV78XX0_CRYPTO,
.end = IRQ_MV78XX0_CRYPTO,
.flags = IORESOURCE_IRQ,
},
};
static struct platform_device mv78xx0_crypto = {
.name = "mv_crypto",
.id = -1,
.num_resources = ARRAY_SIZE(mv78xx0_crypto_resources),
.resource = mv78xx0_crypto_resources,
};
void __init mv78xx0_crypto_init(void)
{
//kirkwood_clk_ctrl |= CGC_CRYPTO;
platform_device_register(&mv78xx0_crypto);
}
With the following settings (mv78xx0.h)
#define MV78XX0_SRAM_PHYS_BASE 0xf7000000
#define MV78XX0_SRAM_SIZE SZ_2K
#define CRYPTO_PHYS_BASE (MV78XX0_REGS_PHYS_BASE | 0x90000)
When loading the OCF driver for the feroceon it is crashing in setup_tdma_mbus_windows(...) in the following loop
for (i = 0; i < dev->plat_data->dram->num_cs; i++) {
struct mbus_dram_window *cs = dev->plat_data->dram->cs + i;
writel(
((cs->size - 1) & 0xffff0000) |
(cs->mbus_attr << 8) |
(dev->plat_data->dram->mbus_dram_target_id << 4) | 1,
dev->reg + WINDOW_CTRL(i)
);
writel(cs->base, dev->reg + WINDOW_BASE(i));
}
I think the SRAM configuration or something isn't set correct, but to get the correct values from the Feroceon documentation is not so easy.
So I tried to compare the values with the kirkwood.
The current dump from the kernel:
---
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = dec3c000
[00000000] *pgd=1fbd5031, *pte=00000000, *ppte=00000000
Internal error: Oops: 17 [#1] PREEMPT
Modules linked in: mv_cesa(+) cryptodev(P) ocf(P)
CPU: 0 Tainted: P (2.6.31.14 #39)
PC is at mv_cesa_ocf_init+0x2a8/0x588 [mv_cesa]
LR is at mv_cesa_ocf_init+0x248/0x588 [mv_cesa]
pc : [<bf01aab4>] lr : [<bf01aa54>] psr: 40000013
sp : dec0fea8 ip : 00001e3e fp : be97ae24
r10: 00000000 r9 : dec0e000 r8 : bf032540
r7 : c04ba968 r6 : 00000000 r5 : 00000000 r4 : 00000000
r3 : 00000000 r2 : dec0fe9c r1 : bf0272cc r0 : 0000004f
Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 0005397f Table: 1ec3c000 DAC: 00000015
Process insmod (pid: 425, stack limit = 0xdec0e270)
Stack: (0xdec0fea8 to 0xdec10000)
fea0: 00000000 00000000 00000001 c04ba970 c04ba970 bf031f70
fec0: dfa3d0c0 c04d1d88 00000000 c0226b6c c04ba970 c0225c9c c04ba970 c04ba9a4
fee0: bf031f70 dfa3d0c0 c04d1d88 c0225db0 00000000 c0225d50 bf031f70 c02254c0
ff00: df8035b8 df81cb10 00000000 00000060 bf031f70 c0224dd0 bf0274a2 bf0274a2
ff20: dec0ff20 00000000 bf032340 bf031f70 00000000 c0026ae8 00000000 c0226084
ff40: 00000000 bf032340 bf035000 00000000 c0026ae8 bf03500c 00000000 c002631c
ff60: 00000000 bf032340 000c8082 401dd008 c0026ae8 00000000 bf032340 000c8082
ff80: 401dd008 c00733f0 401dd008 0028d614 000c8082 be97ae24 00000000 00000069
ffa0: 00000080 c0026940 be97ae24 00000000 401dd008 0028d614 000c8082 00000000
ffc0: be97ae24 00000000 00000069 00000080 00000001 00000002 be97ae28 be97ae24
ffe0: be97ae24 be97aaec 000225f0 40177ba4 60000010 401dd008 feedfeed feedfeed
[<bf01aab4>] (mv_cesa_ocf_init+0x2a8/0x588 [mv_cesa]) from [<c0226b6c>] (platform_drv_probe+0x14/0x18)
[<c0226b6c>] (platform_drv_probe+0x14/0x18) from [<c0225c9c>] (driver_probe_device+0xa8/0x15c)
[<c0225c9c>] (driver_probe_device+0xa8/0x15c) from [<c0225db0>] (__driver_attach+0x60/0x84)
[<c0225db0>] (__driver_attach+0x60/0x84) from [<c02254c0>] (bus_for_each_dev+0x44/0x74)
[<c02254c0>] (bus_for_each_dev+0x44/0x74) from [<c0224dd0>] (bus_add_driver+0x134/0x2bc)
[<c0224dd0>] (bus_add_driver+0x134/0x2bc) from [<c0226084>] (driver_register+0xa8/0x130)
[<c0226084>] (driver_register+0xa8/0x130) from [<bf03500c>] (mv_cesa_init+0xc/0x3c [mv_cesa])
[<bf03500c>] (mv_cesa_init+0xc/0x3c [mv_cesa]) from [<c002631c>] (do_one_initcall+0x5c/0x1bc)
[<c002631c>] (do_one_initcall+0x5c/0x1bc) from [<c00733f0>] (sys_init_module+0xb0/0x1c4)
[<c00733f0>] (sys_init_module+0xb0/0x1c4) from [<c0026940>] (ret_fast_syscall+0x0/0x2c)
Code: e590300c e7823001 e59f8224 e5983008 (e5932000)
---[ end trace dd976c01f3fc5834 ]---
Segmentation fault
---
Any ideas or hints for the right settings are welcome.
Thanks.
Patrick
-----Original Message-----
From: David McCullough [mailto:dav...@mc...]
Sent: Monday, August 23, 2010 4:54 AM
To: Flaig, Patrick
Cc: ocf...@li...
Subject: Re: [Ocf-linux-users] OCF driver for Marvell Kirkwood (88F6xxx) Processors
Jivin Flaig, Patrick lays it down ...
> Hi David,
>
> I compiled the cryptotest for my target platform, and get the
> following response from the program when using
Looks like you driver isn't loading fully, it most certainly has registered with OCF based on this output.
You will need to trace your drivers startup and check that it calls crypto_register.
My guess is that it isn't,
Cheers,
Davidm
> cryptosoft driver:
>
> sh-3.2# ./cryptotest
> cryptodev_open()
> cryptodev_ioctl(cmd=c0046364 arg=be8979bc)
> cryptodev_ioctl(CRIOGET)
> cryptodev_ioctl(cmd=c030636a arg=be897a1c)
> cryptodev_ioctl(CIOCGSESSION2)
> cryptodev_ioctl(CIOCGSESSION2) - no mac
> crypto/ocf/crypto.c,389: DRIVER_LOCK()
> crypto/ocf/crypto.c,413: DRIVER_UNLOCK()
> crypto/ocf/crypto.c,415: DRIVER_LOCK()
> crypto/ocf/crypto.c,425: DRIVER_UNLOCK()
> csecreate()
> cseadd()
> cryptodev_ioctl(cmd=c01c6367 arg=be897a00)
> cryptodev_ioctl(CIOCCRYPT)
> csefind()
> cryptodev_op()
> crypto_dispatch()
> crypto/ocf/crypto.c,815: Q_LOCK()
> crypto/ocf/crypto.c,839: Q_UNLOCK()
> crypto_invoke()
> crypto_done()
> crypto/ocf/crypto.c,1156: Q_LOCK()
> crypto/ocf/crypto.c,1158: Q_UNLOCK()
> cryptodev_cb()
> crypto/ocf/crypto.c,841: Q_LOCK()
> crypto/ocf/crypto.c,867: Q_UNLOCK()
> cryptodev_op about to WAIT
> cryptodev_op finished WAITING error=0
> cryptodev_ioctl(cmd=c01c6367 arg=be897a00)
> cryptodev_ioctl(CIOCCRYPT)
> csefind()
> cryptodev_op()
> crypto_dispatch()
> crypto/ocf/crypto.c,815: Q_LOCK()
> crypto/ocf/crypto.c,839: Q_UNLOCK()
> crypto_invoke()
> crypto_done()
> crypto/ocf/crypto.c,1156: Q_LOCK()
> crypto/ocf/crypto.c,1158: Q_UNLOCK()
> cryptodev_cb()
> crypto/ocf/crypto.c,841: Q_LOCK()
> crypto/ocf/crypto.c,867: Q_UNLOCK()
> cryptodev_op about to WAIT
> cryptodev_op finished WAITING error=0
> cryptodev_ioctl(cmd=40046366 arg=be897a34)
> cryptodev_ioctl(CIOCFSESSION)
> csefind()
> csedelete()
> csefree()
> crypto_freesession()
> crypto/ocf/crypto.c,450: DRIVER_LOCK()
> crypto/ocf/crypto.c,468: DRIVER_UNLOCK()
> crypto/ocf/crypto.c,471: DRIVER_LOCK()
> crypto/ocf/crypto.c,481: DRIVER_UNLOCK()
> 0.080 sec, cryptodev_release()
> 2 3des crypts, 8 bytes, 201 byte/sec, 0.0 Mb/sec
>
>
> feroceon driver:
>
> sh-3.2# ./cryptotest
> cryptodev_open()
> cryptodev_ioctl(cmd=c0046364 arg=bebe09bc)
> cryptodev_ioctl(CRIOGET)
> cryptodev_ioctl(cmd=c030636a arg=bebe0a1c)
> cryptodev_ioctl(CIOCGSESSION2)
> cryptodev_ioctl(CIOCGSESSION2) - no mac
> crypto/ocf/crypto.c,389: DRIVER_LOCK()
> crypto/ocf/crypto.c,425: DRIVER_UNLOCK()
> cryptodev_ioctl(CIOCGSESSION2) - newsession 22
> cryptodev_ioctl(CIOCGSESSION2) - bail 22
> cryptodev_release()
>
> A similar output when using my program:
>
> cryptodev_open()
> cryptodev_ioctl(cmd=c0046364 arg=befa0cd0)
> cryptodev_ioctl(CRIOGET)
> cryptodev_ioctl(cmd=c01c6365 arg=befa0af8)
> cryptodev_ioctl(CIOCGSESSION)
> cryptodev_ioctl(CIOCGSESSION) - no mac
> crypto/ocf/crypto.c,389: DRIVER_LOCK()
> crypto/ocf/crypto.c,425: DRIVER_UNLOCK()
> cryptodev_ioctl(CIOCGSESSION) - newsession 22
> cryptodev_ioctl(CIOCGSESSION) - bail 22
> cryptodev_release()
>
>
> Do you see any reason why the hardware driver is not working?
>
> Regards
>
> Patrick
>
> -----Urspr??ngliche Nachricht-----
> Von: David McCullough [mailto:dav...@mc...]
> Gesendet: Donnerstag, 19. August 2010 07:17
> An: Flaig, Patrick
> Cc: ocf...@li...
> Betreff: Re: [Ocf-linux-users] OCF driver for Marvell Kirkwood
> (88F6xxx) Processors
>
>
> Jivin Flaig, Patrick lays it down ...
> > Hi David,
> >
> > Thanks for the feedback, ok now I know that cannot reference "/proc/crypto" for OCF details.
> >
> > But how can I check if the hardware driver is used or loaded?
> >
> > As said when I try to use an AES CBC algorithm with the Feroceon driver I'm getting in invalid argument error.
> > ---
> > /* Get crypto session for AES128 */
> > sess.cipher = CRYPTO_AES_CBC;
> > sess.keylen = KEY_SIZE;
> > sess.key = key;
> > if (ioctl(cfd, CIOCGSESSION, &sess)) {
> > perror("ioctl(CIOCGSESSION)");
> > return 1;
> > }
> > ---
> >
> > With the software driver no problem!
> >
> > Some time ago I did some measurements with the original Marvell SDK Kernel for the Feroceon. Without HW driver I was able to encrypt about 9 MB/s, with HW support 36 MB/s.
> > If I now do the same measurements again with loaded SW and HW driver I'm only getting a rate about 9 MB/s, which leads to the speculation that only the software driver is working.
> > Is there a way to check if the hardware driver is working?
>
> I did cover this in my previous email. Check below.
>
> Turning on debug will let you know if the driver is active or not and
> tell you lots more. Not debug while working means the driver is not being used.
>
> Debug should also give you a detailed reason why EINVAL is being returned.
> It will at least tell you the line/area the failure originated from.
>
> The debug will come out on the console/system log or somewhere.
> Whereever you kernel trace comes out.
>
> Please try building and using the cryptotest program as well. I know
> you have you own code, but the cryptotest program isa known quantity
> and I know it does everything right ;-)
>
> Cheers,
> Davidm
>
> > -----Original Message-----
> > From: David McCullough [mailto:dav...@mc...]
> > Sent: Tuesday, August 17, 2010 1:24 AM
> > To: Flaig, Patrick
> > Cc: ocf...@li...
> > Subject: Re: [Ocf-linux-users] OCF driver for Marvell Kirkwood
> > (88F6xxx) Processors
> >
> >
> > Jivin Flaig, Patrick lays it down ...
> > > Hi David,
> > >
> > > Thanks a lot, the additional lines in the Makefile let me compile the Feroceon driver.
> > >
> > > I've now compiled the OCF module and the driver directly into the kernel.
> > >
> > > I think I've now an understanding problem, how to configure OCF the right way.
> > > Do I have to configure the cryptographic API as well, with all the algorithms I want?
> > > How can I make sure that, if I have selected AES for example, the hardware acceleration is used?
> > > /proc/crypto is only showing module: kernel.
> >
> > OCF doesn't register with /proc/crypto as it is not part of the kernel crypto.
> >
> > If you only have one OCF driver loaded then only that option can be used.
> >
> > OCF, by default, preferrs HW drivers over SW drivers. Of source this only matters if you have more than one OCF crypto driver loaded, and one is SW.
> >
> > Jivin Flaig, Patrick lays it down ...
> > > Hi David,
> > >
> > > I tried to do some measurements with the Feroceon driver and run into some problems.
> > > It seems the hardware support is not fully working.
> > >
> > > I configured OCF to use the CRYPTOSOFT driver and run a little test application, everything works fine.
> > > But when I disabled the CRYPTOSOFT driver and enabled the FEROCEON driver, my test failed with an "ioctl(CIOCGSESSION): Invalid argument" error.
> > >
> > > ---
> > > /* Get crypto session for AES128 */
> > > sess.cipher = CRYPTO_AES_CBC;
> > > sess.keylen = KEY_SIZE;
> > > sess.key = key;
> > > if (ioctl(cfd, CIOCGSESSION, &sess)) {
> > > perror("ioctl(CIOCGSESSION)");
> > > return 1;
> > > }
> > > ---
> > >
> > > For me this looks like the driver is not loaded.
> > > Did I forget to configure something?
> >
> > This sounds like either the driver is not loaded and registered properly.
> > You said you have compiled everytihng into the kernel ? It might be easier to use modules so you can debug it more easily (add trace etc).
> >
> > Try turning on debug in the ocf and crypto drivers before you load your driver.
> >
> > echo 1 > /sys/module/ocf/parameters/crypto_debug
> > echo 1 > /sys/module/cryptodev/parameters/cryptodev_debug
> >
> > Make sure your driver is registering with OCF for the alg's you want.
> >
> > > How will OCF handle algorithms that are not supported by the hardware, will the OCF switch to the kernel algorithm?
> >
> > No, OCF has no fall back, it can only use the drivers that you have loaded. If you want it to fall back to kernel SW versions you need to load cryptosoft. OCF will use HW versions in preference to SW versions.
> >
> > > Do I have to enable the CRYPTOSOFT in combination with the hardware driver?
> >
> > No. And while you are debugging your driver I recommend only loading one driver (feroceon).
> >
> > Get the cryptotest app that in bundled in with the OCF release and use that to test your OCF driver. It can do everything you need to help debug the driver and is very simple code that talks direct to OCF via /dev/crypto.
> >
> > Cheers,
> > Davidm
> >
> > --
> > David McCullough, dav...@mc..., Ph:+61 734352815
> > McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org
> >
> >
>
> --
> David McCullough, dav...@mc..., Ph:+61 734352815
> McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org
>
>
--
David McCullough, dav...@mc..., Ph:+61 734352815
McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org
|
|
From: Harro H. <hr...@gm...> - 2010-08-24 09:30:03
|
Problem solved! INTER_REGS_BASE (in mvSysHwConfig.h) had the value 0xFEE00000. This is the same as KIRKWOOD_PCIE_IO_VIRT_BASE in linux-2.6.33/arch/arm/mach-kirkwood/include/mach/kirkwood.h. For my configuration it should be KIRKWOOD_REGS_VIRT_BASE, which is 0xfed00000. Why does the define INTER_REGS_BASE exist? Would it not be cleaner to use “cesa_device.reg” instead (set by platform_get_resource_byname() in cesa_ocf_drv.c)? Regards, Harro On 23 August 2010 16:47, Harro Haan <hr...@gm...> wrote: > Some additional info, > > When I define CESA_OCF_POLLING in cesa_ocf_drv.c everything works fine. > > When I do "cat /proc/interrupts" (with #undef CESA_OCF_POLLING), I can > see that no cesa interrupts occurred. When I look at the debug output > (see previous mail) I do not see the line "cesa_interrupt_handler()" > either. > > So for my configuration something is wrong/missing with my interrupts. > Any hints? > > Thanks, > > Harro > > On 20 August 2010 16:52, Harro Haan <hr...@gm...> wrote: >> Hello David, >> >> I’m trying to get this driver working with a 3.6.33 kernel on my >> OpenRD-Ultimate 88F6281 development board, but the cryptotest program >> is waiting forever. >> >> Debug output for mv_cesa: >> ------------------------------------ >> root@DB88FXX81:/ ./cryptotest -a aes >> cryptodev_open() >> cryptodev_ioctl(cmd=c0046364 arg=beea0954) >> cryptodev_ioctl(CRIOGET) >> cryptodev_ioctl(cmd=c030636a arg=beea09b4) >> cryptodev_ioctl(CIOCGSESSION2) >> cryptodev_ioctl(CIOCGSESSION2) - no mac >> crypto/ocf/crypto.c,389: DRIVER_LOCK() >> crypto/ocf/crypto.c,413: DRIVER_UNLOCK() >> cesa_ocf_newsession() >> crypto/ocf/kirkwood/cesa_ocf_drv.c,875: new session 1 >> crypto/ocf/kirkwood/cesa_ocf_drv.c,896: (1) AES CBC >> crypto/ocf/kirkwood/cesa_ocf_drv.c,906: key length 16 >> crypto/ocf/crypto.c,415: DRIVER_LOCK() >> crypto/ocf/crypto.c,425: DRIVER_UNLOCK() >> csecreate() >> cseadd() >> cryptodev_ioctl(cmd=c01c6367 arg=beea0998) >> cryptodev_ioctl(CIOCCRYPT) >> csefind() >> cryptodev_op() >> crypto_dispatch() >> crypto/ocf/crypto.c,815: Q_LOCK() >> crypto/ocf/crypto.c,839: Q_UNLOCK() >> crypto_invoke() >> cesa_ocf_process() >> crypto/ocf/kirkwood/cesa_ocf_drv.c,425: handle UIO. >> crypto/ocf/kirkwood/cesa_ocf_drv.c,440: buf 0-> addr ded17500, size 10 >> crypto/ocf/kirkwood/cesa_ocf_drv.c,480: cipher encrypt >> crypto/ocf/kirkwood/cesa_ocf_drv.c,491: IV from USER (offset 0) >> crypto/ocf/kirkwood/cesa_ocf_drv.c,508: don't copy the IV back to the buffer >> >> crypto/ocf/kirkwood/cesa_ocf_drv.c,596: Sending Action: >> crypto/ocf/kirkwood/cesa_ocf_drv.c,597: IV from user: 1. IV offset 0 >> crypto/ocf/kirkwood/cesa_ocf_drv.c,598: crypt offset 10 len 10 >> crypto/ocf/kirkwood/cesa_ocf_drv.c,599: Auth offset 0 len 0 >> crypto/ocf/kirkwood/cesa_ocf_drv.c,600: set digest in offset 0 . >> SRC BUFFER: pMbuf=dfa4bc24, numFrags=2, mbufSize=32 >> # 0. bufVirt=df8ee020, bufSize=16 >> df8ee020: 33 35 38 36 74 34 69 6f 68 33 75 21 75 36 34 39 >> # 1. bufVirt=ded17500, bufSize=16 >> ded17500: 6e 33 38 39 34 36 6f 74 38 69 74 39 31 65 75 6e >> crypto/ocf/crypto.c,841: Q_LOCK() >> crypto/ocf/crypto.c,867: Q_UNLOCK() >> cryptodev_op about to WAIT >> >> ------------------------------------ >> >> Debug output for cryptosoft (which is working just fine): >> ------------------------------------ >> root@DB88FXX81:/ ./cryptotest -a aes >> cryptodev_open() >> cryptodev_ioctl(cmd=c0046364 arg=bea58954) >> cryptodev_ioctl(CRIOGET) >> cryptodev_ioctl(cmd=c030636a arg=bea589b4) >> cryptodev_ioctl(CIOCGSESSION2) >> cryptodev_ioctl(CIOCGSESSION2) - no mac >> crypto/ocf/crypto.c,389: DRIVER_LOCK() >> crypto/ocf/crypto.c,413: DRIVER_UNLOCK() >> swcr_newsession() >> swcr_newsession crypto_alloc_*blkcipher(cbc(aes), 0x0) >> swcr_newsession cbc(aes) cipher is async >> swcr_newsession key:cri->cri_klen=128,(cri->cri_klen + 7)/8=16 >> 0x32 0x61 0x38 0x6f 0x21 0x32 0x61 0x61 >> 0x21 0x35 0x75 0x21 0x69 0x30 0x65 0x21 >> crypto/ocf/crypto.c,415: DRIVER_LOCK() >> crypto/ocf/crypto.c,425: DRIVER_UNLOCK() >> csecreate() >> cseadd() >> cryptodev_ioctl(cmd=c01c6367 arg=bea58998) >> cryptodev_ioctl(CIOCCRYPT) >> csefind() >> cryptodev_op() >> crypto_dispatch() >> crypto/ocf/crypto.c,815: Q_LOCK() >> crypto/ocf/crypto.c,839: Q_UNLOCK() >> crypto_invoke() >> swcr_process() >> swcr_process_req() >> crypto OP success 0 >> crypto_done() >> crypto/ocf/crypto.c,1156: Q_LOCK() >> crypto/ocf/crypto.c,1158: Q_UNLOCK() >> cryptodev_cb() >> crypto/ocf/crypto.c,841: Q_LOCK() >> crypto/ocf/crypto.c,867: Q_UNLOCK() >> cryptodev_op about to WAIT >> cryptodev_op finished WAITING error=0 >> cryptodev_ioctl(cmd=c01c6367 arg=bea58998) >> cryptodev_ioctl(CIOCCRYPT) >> csefind() >> cryptodev_op() >> crypto_dispatch() >> crypto/ocf/crypto.c,815: Q_LOCK() >> crypto/ocf/crypto.c,839: Q_UNLOCK() >> crypto_invoke() >> swcr_process() >> swcr_process_req() >> crypto OP success 0 >> crypto_done() >> crypto/ocf/crypto.c,1156: Q_LOCK() >> crypto/ocf/crypto.c,1158: Q_UNLOCK() >> cryptodev_cb() >> crypto/ocf/crypto.c,841: Q_LOCK() >> crypto/ocf/crypto.c,867: Q_UNLOCK() >> cryptodev_op about to WAIT >> cryptodev_op finished WAITING error=0 >> cryptodev_ioctl(cmd=40046366 arg=bea589cc) >> cryptodev_ioctl(CIOCFSESSION) >> csefind() >> csedelete() >> csefree() >> crypto_freesession() >> crypto/ocf/crypto.c,450: DRIVER_LOCK() >> crypto/ocf/crypto.c,468: DRIVER_UNLOCK() >> swcr_freesession() >> crypto/ocf/crypto.c,471: DRIVER_LOCK() >> crypto/ocf/crypto.c,481: DRIVER_UNLOCK() >> 0.089 sec, cryptodev_release() >> 2 aes crypts, 16 bytes, 358 byte/sec, 0.0 Mb/sec >> root@DB88FXX81:/ >> ------------------------------------ >> >> I am following this thread as well: >> “[Ocf-linux-users] OCF driver for Marvell Kirkwood (88F6xxx) Processors” >> http://sourceforge.net/mailarchive/forum.php?thread_name=8D145DCD0F55B543949BE94258003A200DF9AD4EA6%40exchange12.bdt-rw.de&forum_name=ocf-linux-users >> >> Attached are my patches (fixes as described in the thread above) and >> series file. >> >> Do you have an idea why the system is hanging/waiting forever? >> >> Thanks, >> >> Harro >> > |
|
From: Harro H. <hr...@gm...> - 2010-08-23 14:47:42
|
Some additional info, When I define CESA_OCF_POLLING in cesa_ocf_drv.c everything works fine. When I do "cat /proc/interrupts" (with #undef CESA_OCF_POLLING), I can see that no cesa interrupts occurred. When I look at the debug output (see previous mail) I do not see the line "cesa_interrupt_handler()" either. So for my configuration something is wrong/missing with my interrupts. Any hints? Thanks, Harro On 20 August 2010 16:52, Harro Haan <hr...@gm...> wrote: > Hello David, > > I’m trying to get this driver working with a 3.6.33 kernel on my > OpenRD-Ultimate 88F6281 development board, but the cryptotest program > is waiting forever. > > Debug output for mv_cesa: > ------------------------------------ > root@DB88FXX81:/ ./cryptotest -a aes > cryptodev_open() > cryptodev_ioctl(cmd=c0046364 arg=beea0954) > cryptodev_ioctl(CRIOGET) > cryptodev_ioctl(cmd=c030636a arg=beea09b4) > cryptodev_ioctl(CIOCGSESSION2) > cryptodev_ioctl(CIOCGSESSION2) - no mac > crypto/ocf/crypto.c,389: DRIVER_LOCK() > crypto/ocf/crypto.c,413: DRIVER_UNLOCK() > cesa_ocf_newsession() > crypto/ocf/kirkwood/cesa_ocf_drv.c,875: new session 1 > crypto/ocf/kirkwood/cesa_ocf_drv.c,896: (1) AES CBC > crypto/ocf/kirkwood/cesa_ocf_drv.c,906: key length 16 > crypto/ocf/crypto.c,415: DRIVER_LOCK() > crypto/ocf/crypto.c,425: DRIVER_UNLOCK() > csecreate() > cseadd() > cryptodev_ioctl(cmd=c01c6367 arg=beea0998) > cryptodev_ioctl(CIOCCRYPT) > csefind() > cryptodev_op() > crypto_dispatch() > crypto/ocf/crypto.c,815: Q_LOCK() > crypto/ocf/crypto.c,839: Q_UNLOCK() > crypto_invoke() > cesa_ocf_process() > crypto/ocf/kirkwood/cesa_ocf_drv.c,425: handle UIO. > crypto/ocf/kirkwood/cesa_ocf_drv.c,440: buf 0-> addr ded17500, size 10 > crypto/ocf/kirkwood/cesa_ocf_drv.c,480: cipher encrypt > crypto/ocf/kirkwood/cesa_ocf_drv.c,491: IV from USER (offset 0) > crypto/ocf/kirkwood/cesa_ocf_drv.c,508: don't copy the IV back to the buffer > > crypto/ocf/kirkwood/cesa_ocf_drv.c,596: Sending Action: > crypto/ocf/kirkwood/cesa_ocf_drv.c,597: IV from user: 1. IV offset 0 > crypto/ocf/kirkwood/cesa_ocf_drv.c,598: crypt offset 10 len 10 > crypto/ocf/kirkwood/cesa_ocf_drv.c,599: Auth offset 0 len 0 > crypto/ocf/kirkwood/cesa_ocf_drv.c,600: set digest in offset 0 . > SRC BUFFER: pMbuf=dfa4bc24, numFrags=2, mbufSize=32 > # 0. bufVirt=df8ee020, bufSize=16 > df8ee020: 33 35 38 36 74 34 69 6f 68 33 75 21 75 36 34 39 > # 1. bufVirt=ded17500, bufSize=16 > ded17500: 6e 33 38 39 34 36 6f 74 38 69 74 39 31 65 75 6e > crypto/ocf/crypto.c,841: Q_LOCK() > crypto/ocf/crypto.c,867: Q_UNLOCK() > cryptodev_op about to WAIT > > ------------------------------------ > > Debug output for cryptosoft (which is working just fine): > ------------------------------------ > root@DB88FXX81:/ ./cryptotest -a aes > cryptodev_open() > cryptodev_ioctl(cmd=c0046364 arg=bea58954) > cryptodev_ioctl(CRIOGET) > cryptodev_ioctl(cmd=c030636a arg=bea589b4) > cryptodev_ioctl(CIOCGSESSION2) > cryptodev_ioctl(CIOCGSESSION2) - no mac > crypto/ocf/crypto.c,389: DRIVER_LOCK() > crypto/ocf/crypto.c,413: DRIVER_UNLOCK() > swcr_newsession() > swcr_newsession crypto_alloc_*blkcipher(cbc(aes), 0x0) > swcr_newsession cbc(aes) cipher is async > swcr_newsession key:cri->cri_klen=128,(cri->cri_klen + 7)/8=16 > 0x32 0x61 0x38 0x6f 0x21 0x32 0x61 0x61 > 0x21 0x35 0x75 0x21 0x69 0x30 0x65 0x21 > crypto/ocf/crypto.c,415: DRIVER_LOCK() > crypto/ocf/crypto.c,425: DRIVER_UNLOCK() > csecreate() > cseadd() > cryptodev_ioctl(cmd=c01c6367 arg=bea58998) > cryptodev_ioctl(CIOCCRYPT) > csefind() > cryptodev_op() > crypto_dispatch() > crypto/ocf/crypto.c,815: Q_LOCK() > crypto/ocf/crypto.c,839: Q_UNLOCK() > crypto_invoke() > swcr_process() > swcr_process_req() > crypto OP success 0 > crypto_done() > crypto/ocf/crypto.c,1156: Q_LOCK() > crypto/ocf/crypto.c,1158: Q_UNLOCK() > cryptodev_cb() > crypto/ocf/crypto.c,841: Q_LOCK() > crypto/ocf/crypto.c,867: Q_UNLOCK() > cryptodev_op about to WAIT > cryptodev_op finished WAITING error=0 > cryptodev_ioctl(cmd=c01c6367 arg=bea58998) > cryptodev_ioctl(CIOCCRYPT) > csefind() > cryptodev_op() > crypto_dispatch() > crypto/ocf/crypto.c,815: Q_LOCK() > crypto/ocf/crypto.c,839: Q_UNLOCK() > crypto_invoke() > swcr_process() > swcr_process_req() > crypto OP success 0 > crypto_done() > crypto/ocf/crypto.c,1156: Q_LOCK() > crypto/ocf/crypto.c,1158: Q_UNLOCK() > cryptodev_cb() > crypto/ocf/crypto.c,841: Q_LOCK() > crypto/ocf/crypto.c,867: Q_UNLOCK() > cryptodev_op about to WAIT > cryptodev_op finished WAITING error=0 > cryptodev_ioctl(cmd=40046366 arg=bea589cc) > cryptodev_ioctl(CIOCFSESSION) > csefind() > csedelete() > csefree() > crypto_freesession() > crypto/ocf/crypto.c,450: DRIVER_LOCK() > crypto/ocf/crypto.c,468: DRIVER_UNLOCK() > swcr_freesession() > crypto/ocf/crypto.c,471: DRIVER_LOCK() > crypto/ocf/crypto.c,481: DRIVER_UNLOCK() > 0.089 sec, cryptodev_release() > 2 aes crypts, 16 bytes, 358 byte/sec, 0.0 Mb/sec > root@DB88FXX81:/ > ------------------------------------ > > I am following this thread as well: > “[Ocf-linux-users] OCF driver for Marvell Kirkwood (88F6xxx) Processors” > http://sourceforge.net/mailarchive/forum.php?thread_name=8D145DCD0F55B543949BE94258003A200DF9AD4EA6%40exchange12.bdt-rw.de&forum_name=ocf-linux-users > > Attached are my patches (fixes as described in the thread above) and > series file. > > Do you have an idea why the system is hanging/waiting forever? > > Thanks, > > Harro > |
4 messages has been excluded from this view by a project administrator.
