Re: [Ocf-linux-users] OCF driver for Marvell Kirkwood (88F6xxx) Processors
Brought to you by:
david-m
Menu
▾
▴
Re: [Ocf-linux-users] OCF driver for Marvell Kirkwood (88F6xxx) Processors
|
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
|
