linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* mpc8248  SEC -- interrupt handler not invoked
@ 2005-07-29 15:40 Vikas Aggarwal
  2005-07-29 20:33 ` Kim Phillips
  0 siblings, 1 reply; 16+ messages in thread
From: Vikas Aggarwal @ 2005-07-29 15:40 UTC (permalink / raw)
  To: linuxppc-embedded

Hi All,
  Will  appreciate if someone can guide me how to debug this inside SEC
(security co-processor) core.

 The linux driver is writing descriptor into the FETCH-Register(0x2048) 
for Random Number generation execution unit(RNG-EU). The request came
through a test program from user space. The RNG generation request never
seems to complete as my ISR is not invoked.
 I checked the CCPSR(Crypto Channel Pointer Status register = 0x2010) and
it has value=0:7(0-31 : 32-63 bits). 7 means "channel_error". But its
always there even before I write the RNG descriptor to Fetch-register.

1. I can read the ID register and verified it is 0x09000000.
2. I can see my ISR is registered(0x47)  under /proc/interrupts.

I don't see anything wrong with the descriptor which is very simple Random
Number Generation request.

regards
-vikas aggarwal

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: mpc8248  SEC -- interrupt handler not invoked
  2005-07-29 15:40 mpc8248 SEC -- interrupt handler not invoked Vikas Aggarwal
@ 2005-07-29 20:33 ` Kim Phillips
  2005-07-30  3:39   ` Vikas Aggarwal
  0 siblings, 1 reply; 16+ messages in thread
From: Kim Phillips @ 2005-07-29 20:33 UTC (permalink / raw)
  To: Vikas Aggarwal; +Cc: linuxppc-embedded

On Fri, 29 Jul 2005 11:40:27 -0400 (EDT)
"Vikas Aggarwal" <va824363@albany.edu> wrote:

> Hi All,
>   Will  appreciate if someone can guide me how to debug this inside SEC
> (security co-processor) core.
> 
>  The linux driver is writing descriptor into the FETCH-Register(0x2048) 
> for Random Number generation execution unit(RNG-EU). The request came
> through a test program from user space. The RNG generation request never
> seems to complete as my ISR is not invoked.
>  I checked the CCPSR(Crypto Channel Pointer Status register = 0x2010) and
> it has value=0:7(0-31 : 32-63 bits). 7 means "channel_error". But its
> always there even before I write the RNG descriptor to Fetch-register.

a value of 7 in bits 56-63 (PAIR_PTR) can suggest processing has not begun.

can you verify you are writing the upper bits of the FR (i.e. 0x204c)?

Kim

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: mpc8248  SEC -- interrupt handler not invoked
  2005-07-29 20:33 ` Kim Phillips
@ 2005-07-30  3:39   ` Vikas Aggarwal
  2005-07-30 23:32     ` Kim Phillips
  0 siblings, 1 reply; 16+ messages in thread
From: Vikas Aggarwal @ 2005-07-30  3:39 UTC (permalink / raw)
  To: Kim Phillips; +Cc: linuxppc-embedded

Hi Kim,
 Thanks for helping out.
 Yes i verified , i am writing to upper bits of FR.

 Now my ISR does get invoked and InterruptStatus(0x1010) has 4 in upper
bits.  That means TEA (Transfer Error Acknowledge). Next thing i did is i
dumped the lower bits of master-error-address-register MEAR(0x1038) and
it has 0x011af4d0. As per definition of this register my data phase was
terminated .  Was it due to bad address being written into FR.

 I am using virt_to_phys()  to convert the DPD's address and then writing
this into FR.

 Also u may be thinking what did i change that ISR gets invoked now.
Earlier i was using __vpa instead of virt_to_phys().  __vpa came from the
original SEC driver(for mpc8555 and kernel 2.4) which i downloaded from
freescale.  After i replaced __vpa with kernel's virt_to_phys() gets
invoked.

#define __vpa(va) ((pte_val(*(unsigned long
*)pte_offset_kernel(pmd_offset(pgd_offset_k(va), (va)), (va))) &
PAGE_MASK) + (va & ~PAGE_MASK))

But i still think that may be virt_to_phys() is not doing what FR expects.

Thanks for your patience  with detailed mail.
Please help
-vikas aggarwal

> On Fri, 29 Jul 2005 11:40:27 -0400 (EDT)
> "Vikas Aggarwal" <va824363@albany.edu> wrote:
>
>> Hi All,
>>   Will  appreciate if someone can guide me how to debug this inside SEC
>> (security co-processor) core.
>>
>>  The linux driver is writing descriptor into the FETCH-Register(0x2048)
>> for Random Number generation execution unit(RNG-EU). The request came
>> through a test program from user space. The RNG generation request never
>> seems to complete as my ISR is not invoked.
>>  I checked the CCPSR(Crypto Channel Pointer Status register = 0x2010)
>> and
>> it has value=0:7(0-31 : 32-63 bits). 7 means "channel_error". But its
>> always there even before I write the RNG descriptor to Fetch-register.
>
> a value of 7 in bits 56-63 (PAIR_PTR) can suggest processing has not
> begun.
>
> can you verify you are writing the upper bits of the FR (i.e. 0x204c)?
>
> Kim
>

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: mpc8248  SEC -- interrupt handler not invoked
  2005-07-30  3:39   ` Vikas Aggarwal
@ 2005-07-30 23:32     ` Kim Phillips
  2005-08-01  0:48       ` mpc8248 SEC -- interrupt handler "is" invoked Vikas Aggarwal
  0 siblings, 1 reply; 16+ messages in thread
From: Kim Phillips @ 2005-07-30 23:32 UTC (permalink / raw)
  To: Vikas Aggarwal; +Cc: linuxppc-embedded

On Fri, 29 Jul 2005 23:39:32 -0400 (EDT)
"Vikas Aggarwal" <va824363@albany.edu> wrote:

> 
> But i still think that may be virt_to_phys() is not doing what FR expects.
> 
try dma_map_single().  See drivers/net/gianfar.c

Kim

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: mpc8248  SEC -- interrupt handler "is" invoked
  2005-07-30 23:32     ` Kim Phillips
@ 2005-08-01  0:48       ` Vikas Aggarwal
  2005-08-01 17:37         ` Kim Phillips
  0 siblings, 1 reply; 16+ messages in thread
From: Vikas Aggarwal @ 2005-08-01  0:48 UTC (permalink / raw)
  To: Kim Phillips; +Cc: linuxppc-embedded

Tried it as u said . No luck :(
But something more i noted now in CPSR(channel pointer status
register=0x2040)  that before ISR invoked it has 0x0:0x7.

After ISR invoked it has 0x7:0x2007 .  The 7 in low bits means
channel_error and 2 is at "reserved" bits as per documentation, don't know
what that means.

I also tried kmalloc with GFP_DMA, for the memory where i create the
Descriptor.
Please keep giving ideas for debugging this as this is what driving me
right now.
regards
-vikas


> On Fri, 29 Jul 2005 23:39:32 -0400 (EDT)
> "Vikas Aggarwal" <va824363@albany.edu> wrote:
>
>>
>> But i still think that may be virt_to_phys() is not doing what FR
>> expects.
>>
> try dma_map_single().  See drivers/net/gianfar.c
>
> Kim
>

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: mpc8248  SEC -- interrupt handler "is" invoked
  2005-08-01  0:48       ` mpc8248 SEC -- interrupt handler "is" invoked Vikas Aggarwal
@ 2005-08-01 17:37         ` Kim Phillips
  2005-08-01 18:50           ` mpc8248 SEC -- interrupt handler 'is' invoked Vikas Aggarwal
  2005-08-02 15:45           ` Vikas Aggarwal
  0 siblings, 2 replies; 16+ messages in thread
From: Kim Phillips @ 2005-08-01 17:37 UTC (permalink / raw)
  To: Vikas Aggarwal; +Cc: linuxppc-embedded

On Sun, 31 Jul 2005 20:48:16 -0400 (EDT)
"Vikas Aggarwal" <va824363@albany.edu> wrote:

> Tried it as u said . No luck :(
> But something more i noted now in CPSR(channel pointer status
> register=0x2040)  that before ISR invoked it has 0x0:0x7.
> 
> After ISR invoked it has 0x7:0x2007 .  The 7 in low bits means
> channel_error and 2 is at "reserved" bits as per documentation, don't know
> what that means.
> 
> I also tried kmalloc with GFP_DMA, for the memory where i create the
> Descriptor.
> Please keep giving ideas for debugging this as this is what driving me
> right now.
> regards
> -vikas


So you reset the master, then the channel, allocate the RNG descriptor, allocate the random data buffer, fill the descriptor with values for an RNG request the size of your buffer (filling with the physical address of your random data buffer), and submit the descriptor's physical address to the FR..

btw, I'm finding it hard to help without seeing sec register transaction data, descriptor data, virtual and physical addresses, etc.

Kim

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: mpc8248  SEC -- interrupt handler 'is' invoked
  2005-08-01 17:37         ` Kim Phillips
@ 2005-08-01 18:50           ` Vikas Aggarwal
  2005-08-02 15:45           ` Vikas Aggarwal
  1 sibling, 0 replies; 16+ messages in thread
From: Vikas Aggarwal @ 2005-08-01 18:50 UTC (permalink / raw)
  To: Kim Phillips; +Cc: linuxppc-embedded

Hi Kim,
Yes, i checked to my knowledge that i am doing all these steps and also
checked the
bit positions.

I will send you the code excerpts. The code was written for 2.4 kernel and
8555E(downloaded from freescale)  and i ported it to  8248/kernel 2.6.

thanks for your help
-vikas


> On Sun, 31 Jul 2005 20:48:16 -0400 (EDT)
> "Vikas Aggarwal" <va824363@albany.edu> wrote:
>
>> Tried it as u said . No luck :(
>> But something more i noted now in CPSR(channel pointer status
>> register=0x2040)  that before ISR invoked it has 0x0:0x7.
>>
>> After ISR invoked it has 0x7:0x2007 .  The 7 in low bits means
>> channel_error and 2 is at "reserved" bits as per documentation, don't
>> know
>> what that means.
>>
>> I also tried kmalloc with GFP_DMA, for the memory where i create the
>> Descriptor.
>> Please keep giving ideas for debugging this as this is what driving me
>> right now.
>> regards
>> -vikas
>
>
> So you reset the master, then the channel, allocate the RNG descriptor,
> allocate the random data buffer, fill the descriptor with values for an
> RNG request the size of your buffer (filling with the physical address of
> your random data buffer), and submit the descriptor's physical address to
> the FR..
>
> btw, I'm finding it hard to help without seeing sec register transaction
> data, descriptor data, virtual and physical addresses, etc.
>
> Kim
>

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: mpc8248  SEC -- interrupt handler 'is' invoked
  2005-08-01 17:37         ` Kim Phillips
  2005-08-01 18:50           ` mpc8248 SEC -- interrupt handler 'is' invoked Vikas Aggarwal
@ 2005-08-02 15:45           ` Vikas Aggarwal
  2005-08-03 16:47             ` Kim Phillips
  1 sibling, 1 reply; 16+ messages in thread
From: Vikas Aggarwal @ 2005-08-02 15:45 UTC (permalink / raw)
  To: Kim Phillips; +Cc: linuxppc-embedded

Hi Kim,
 Code excerpts are at after the TRACE.
TRACE Messages from the test ---------

bash-2.05b# modprobe secmpc8248
bash-2.05b# ^[[K/lib/modules/2.6.10-rc3/\akernel/crypto/mpc8248/test
SEC1Open() called, inode 0xc0a564cc, file 0xc024e2f4
 *** Test RNG ***

First ID=21474820 ChannelPointerStatusRegister[0]=0x0:
ChannelPointerStatusRegister[0]=0x7

 ChannelPointerStatusRegister[1]=0x0: ChannelPointerStatusRegister[1]=0x7

 ChannelPointerStatusRegister[2]=0x0: ChannelPointerStatusRegister[2]=0x7

 ChannelPointerStatusRegister[3]=0x0: ChannelPointerStatusRegister[3]=0x7

ProcessRequest(): free channel = 0

RequestToDpd(): req @0x7ffff820 ch1

RequestToDpd(): get entry for opId 0x00001000

RequestToDpd(): VerifyRequest(0x7ffff820, 0xc11b9cf0)

RequestToDpd(): clear DPD 0xc11bb910

RequestToDpd(): converting entry4 4->0xc09ffc5c vikas


RequestToDpd(): set length = 160

DPD header         = 0x40000011

Primary EU/Mode 0x04:00, Secondary EU/Mode 0x00:00, Desc Type 0x01, Snoop
Output Data Mode, Done

DPD ptr:len/ext p0 = 0x00000000:00000000

DPD ptr:len/ext p1 = 0x00000000:00000000

DPD ptr:len/ext p2 = 0x00000000:00000000

DPD ptr:len/ext p3 = 0x00000000:00000000

DPD ptr:len/ext p4 = 0x009ffc5c:000000a0

DPD ptr:len/ext p5 = 0x00000000:00000000

DPD ptr:len/ext p6 = 0x00000000:00000000

RequestToDpd() EndOfFunc: req @0x00000000 ch1

ProcessRequest() endOffunc: free channel = 0


InterruptServiceRoutine()

ProcessingComplete(): IntStatus - 0x0000000000000040

ProcessingComplete():->Controller_MEAR=0x011bb910

 ChannelPointerStatusRegister[0]=0x7: ChannelPointerStatusRegister[0]=0x2007

 ChannelPointerStatusRegister[1]=0x0: ChannelPointerStatusRegister[1]=0x7

 ChannelPointerStatusRegister[2]=0x0: ChannelPointerStatusRegister[2]=0x7

 ChannelPointerStatusRegister[3]=0x0: ChannelPointerStatusRegister[3]=0x7

Unknown

ProcessingComplete Done
 ID1
nfs: server 192.168.2.4 not responding, still trying

nfs: server 192.168.2.4 OK

Request Ti ChannelPointerStatusRegister[0]=0x7:
ChannelPointerStatusRegister[0]=0x2007

 ChannelPointerStatusRegister[1]=0x0: ChannelPointerStatusRegister[1]=0x7

 ChannelPointerStatusRegister[2]=0x0: ChannelPointerStatusRegister[2]=0x7

 ChannelPointerStatusRegister[3]=0x0: ChannelPointerStatusRegister[3]=0x7

testSEC1Close() called

ReleaseChannel(1, taskID=0x     148, lock=1)

bash-2.05b#
------------TRACE COMPLETE ------------------------

This is how i write the address of RNG buffer(sec1_dpd.c.
DPDPTR->fld[i].ptr = virt_to_phys(*(unsigned int *) ((unsigned int)pReq +
pDesc->fld[i].ptrOffset1st));

This is how i write the length of RNG buffer(sec1_dpd.c.
DPDPTR->fld[i].len = *(unsigned int *) ((unsigned int)pReq +
pDesc->fld[i].lenOffset1st);
DPDPTR->nxt_dpd_ptr = 0;

This is how i write the DPD's address?(sec1_request.c).
*(ChannelNextDescriptorRegister[freeChannel]+1) =
dma_map_single(NULL,(volatile void
*)(ChannelAssignments[freeChannel].Dpds[0]),64,DMA_BIDIRECTIONAL);

DPD_TABLE
-----------------------------------------------
/*  DPD_FLD_DETAILS_ENTRY
    Describes where and how a field in a request goes to a field in a DPD
*/
typedef struct
{
    char                    *txt;               /* Description of the
                                                   field within the request
                                                   a NULL indicates the end
                                                   of field entries */
    unsigned int            lenOffset1st;       /* Offset into request
pointer
                                                   for the initial length
field */
    unsigned int            lenOffsetNxt;       /* Offset into request
pointer
                                                   for the next length field
                                                   Used when input points to
                                                   output of the previous
                                                   request */
    unsigned int            ptrOffset1st;       /* Offset into request
pointer
                                                   for the initial data
area */
    unsigned int            extOffset;
    FLD_TYPE                dataType;           /* Data type either:
                                                   a "Read" or "Write"
area */
    BOOLEAN                 (*pFncSize)(unsigned long len); /* Pointer to
                                                    function that checks
                                                    whether the length is
                                                    consistent with the
request */
} DPD_FLD_DETAILS_ENTRY;

/*! \struct DPD_DETAILS_ENTRY
    \brief Describes how a request is broken into a single DPD or a set of
chained
    DPDs
*/
typedef struct DPD_DETAILS_ENTRY
{
    unsigned long           opId;               /* Operation ID for entry */
    char                    *txt;               /* Description of request
                                                   a NULL indicates the end
                                                   of the table */
    unsigned long           sz;                 /* Size of request */
    const unsigned long     *hdrDesc;           /* Descriptor Header */
    unsigned int            lenOffsetBlockLen;  /* Offset into request
pointer
                                                   for total length of
data */
    DPD_FLD_DETAILS_ENTRY   fld[NUM_DPD_FLDS];
} DPD_DETAILS_ENTRY;        /* Each request is enumerated here */

#ifndef offsetof
/*  offsetof(s,m)
    Macro that identifies the byte offset of a field m within a structure s
*/
#define offsetof(s,m)   (size_t)&(((s *)0)->m)
#endif
#define STD_OFFSETS(s,l1,l2,p1,p2)  offsetof(s,l1), offsetof(s,l2),\
                                    offsetof(s,p1), 0
#define EXT_OFFSETS(s,l1,l2,p1,p2)  offsetof(s,l1), offsetof(s,l2),\
                                    offsetof(s,p1), offsetof(s,p2)
#define NULL_PTR_OFFSETS(s,l1,l2)   offsetof(s,l1), offsetof(s,l2), 0, 0
#define ZERO_LEN_OFFSETS(s,p1,p2)   0, 0, offsetof(s,p1), offsetof(s,p2)
#define ALL_ZERO_OFFSETS            0, 0, 0, 0
static char NIL[] = {"NIL"};
DPD_DETAILS_ENTRY DpdDetails[] =
{


    /* DPD_RNG_GROUP */
    {
        DPD_RNG_GROUP, "DPD_RNG_GROUP",
        sizeof(RNG_REQ), RngDesc,
        offsetof(RNG_REQ,rngBytes),
        {
            {NIL,           ALL_ZERO_OFFSETS, Read, NULL},
            {NIL,           ALL_ZERO_OFFSETS, Read, NULL},
            {NIL,           ALL_ZERO_OFFSETS, Read, NULL},
            {NIL,           ALL_ZERO_OFFSETS, Read, NULL},
            {"rngData",    
STD_OFFSETS(RNG_REQ,rngBytes,rngBytes,rngData,rngData), Write,
NULL},
            {NULL, ALL_ZERO_OFFSETS, Read, NULL}
        },
    },
    /* DPD_DES_CBC_GROUP */
    {
----------------------------------
testRNG user-space function-----------
int testRng(int fd)
{
    RNG_REQ rngReq;
    int device=0, status;


    /* RNG test */
    printf("\n*** Test RNG ***\n");

    memset(&rngReq, 0, sizeof(rngReq));
    memset(rngBuf, 0, RNG_TESTSIZE);

    rngReq.opId     = DPD_RNG_GETRN;
    rngReq.rngBytes = RNG_TESTSIZE;
    rngReq.rngData  = rngBuf;


    status = putKmem(fd, "vikas\n\0", &rngReq.rngData, RNG_TESTSIZE);
    if (status)
        return status;

    armCompletion(&rngReq);
    {
        int status1;
        SEC1_STATUS statusReq;
        printf("\nFirst ID=%d\n",statusReq.IdRegister);
        status1 = ioctl(fd, IOCTL_GET_STATUS, (int)&statusReq);
    }
    status = ioctl(fd, IOCTL_PROC_REQ, (int)&rngReq);
    printf("\nID1\n");

    if (status = waitCompletion("testRng(): data extraction test", status,
&rngReq))
    {
        int status1;
        SEC1_STATUS statusReq;
        printf("\nID=%d\n",statusReq.IdRegister);
        status1 = ioctl(fd, IOCTL_GET_STATUS, (int)&statusReq);
        fflush(stdout);

        freeKmem(fd, &rngReq.rngData);
        return status;
    }
    printf("\nID2\n");
    fflush(stdout);

    getKmem(fd, rngBuf, &rngReq.rngData, RNG_TESTSIZE);

    freeKmem(fd, &rngReq.rngData);


    /* check random buffer content for nonzero */
    if (rngBuf[0]) {
        printf("*** Test RNG Data ***\n");
        status = 0;
    } else {
        printf("*** Test RNG Failed ***\n");
        status = -1;
    }

    return status;
}
------------------------------------------------------------------










> On Sun, 31 Jul 2005 20:48:16 -0400 (EDT)
> "Vikas Aggarwal" <va824363@albany.edu> wrote:
>
>> Tried it as u said . No luck :(
>> But something more i noted now in CPSR(channel pointer status
>> register=0x2040)  that before ISR invoked it has 0x0:0x7.
>>
>> After ISR invoked it has 0x7:0x2007 .  The 7 in low bits means
>> channel_error and 2 is at "reserved" bits as per documentation, don't
>> know
>> what that means.
>>
>> I also tried kmalloc with GFP_DMA, for the memory where i create the
>> Descriptor.
>> Please keep giving ideas for debugging this as this is what driving me
>> right now.
>> regards
>> -vikas
>
>
> So you reset the master, then the channel, allocate the RNG descriptor,
> allocate the random data buffer, fill the descriptor with values for an
> RNG request the size of your buffer (filling with the physical address of
> your random data buffer), and submit the descriptor's physical address to
> the FR..
>
> btw, I'm finding it hard to help without seeing sec register transaction
> data, descriptor data, virtual and physical addresses, etc.
>
> Kim
>

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: mpc8248  SEC -- interrupt handler 'is' invoked
  2005-08-02 15:45           ` Vikas Aggarwal
@ 2005-08-03 16:47             ` Kim Phillips
  2005-08-03 18:33               ` Vikas Aggarwal
  0 siblings, 1 reply; 16+ messages in thread
From: Kim Phillips @ 2005-08-03 16:47 UTC (permalink / raw)
  To: Vikas Aggarwal; +Cc: linuxppc-embedded

On Tue, 2 Aug 2005 11:45:15 -0400 (EDT)
"Vikas Aggarwal" <va824363@albany.edu> wrote:

> 
> This is how i write the address of RNG buffer(sec1_dpd.c.
> DPDPTR->fld[i].ptr = virt_to_phys(*(unsigned int *) ((unsigned int)pReq +
> pDesc->fld[i].ptrOffset1st));
> 

everything looks good except I'd try changing the above to something like:

DPDPTR->fld[i].ptr = dma_map_single(NULL, ...ptrOffset1st,
		...lenOffset1st, DMA_TO_DEVICE);

and change the DMA_BIDIRECTIONAL to DMA_TO_DEVICE in the DPD's address assignment.

btw, a BSP upgrade (based on 2.6.11) for your platform should be available in a couple of weeks.  I'll let you know the status of the SEC driver for it.

Kim

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: mpc8248  SEC -- interrupt handler 'is' invoked
  2005-08-03 16:47             ` Kim Phillips
@ 2005-08-03 18:33               ` Vikas Aggarwal
  2005-08-03 20:35                 ` Kim Phillips
  0 siblings, 1 reply; 16+ messages in thread
From: Vikas Aggarwal @ 2005-08-03 18:33 UTC (permalink / raw)
  To: Kim Phillips; +Cc: linuxppc-embedded

I will try the new BSP but meanwhile like to debug my ported driver.

Is there a way , like kernel level single-stepping to know why the
"interrupt status register"  gets a value of "0x0000000000000040" which
means TEA , transfer error acknowledge.

I changed and tested ur latest advice but same error in "interrupt status
register"

-vikas


> On Tue, 2 Aug 2005 11:45:15 -0400 (EDT)
> "Vikas Aggarwal" <va824363@albany.edu> wrote:
>
>>
>> This is how i write the address of RNG buffer(sec1_dpd.c.
>> DPDPTR->fld[i].ptr = virt_to_phys(*(unsigned int *) ((unsigned int)pReq
>> +
>> pDesc->fld[i].ptrOffset1st));
>>
>
> everything looks good except I'd try changing the above to something like:
>
> DPDPTR->fld[i].ptr = dma_map_single(NULL, ...ptrOffset1st,
> 		...lenOffset1st, DMA_TO_DEVICE);
>
> and change the DMA_BIDIRECTIONAL to DMA_TO_DEVICE in the DPD's address
> assignment.
>
> btw, a BSP upgrade (based on 2.6.11) for your platform should be available
> in a couple of weeks.  I'll let you know the status of the SEC driver for
> it.
>
> Kim
>

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: mpc8248  SEC -- interrupt handler 'is' invoked
  2005-08-03 18:33               ` Vikas Aggarwal
@ 2005-08-03 20:35                 ` Kim Phillips
  2005-08-09 13:38                   ` Vikas Aggarwal
  2005-08-09 20:52                   ` Vikas Aggarwal
  0 siblings, 2 replies; 16+ messages in thread
From: Kim Phillips @ 2005-08-03 20:35 UTC (permalink / raw)
  To: Vikas Aggarwal; +Cc: linuxppc-embedded

On Wed, 3 Aug 2005 14:33:26 -0400 (EDT)
"Vikas Aggarwal" <va824363@albany.edu> wrote:

> I will try the new BSP but meanwhile like to debug my ported driver.
> 
> Is there a way , like kernel level single-stepping to know why the
> "interrupt status register"  gets a value of "0x0000000000000040" which
> means TEA , transfer error acknowledge.

afaik, TEA usually means memory was unable to be accessed by the sec (somewhat along the same lines as a SIGBUS or SIGSEGV).

It's a long shot, but you may want to increase the 4-byte alignment of the rng buffer (0x009ffc5c in your trace?) to at least 8-byte.

as for debugging, you can printk sec status registers every time you write one, e.g. in a sec register write wrapper fn.  Be sure to check the RNG interrupt status register, and the RNG status register, and the RNG interrupt control register.

and if all else fails, you can bypass the channel infrastructure altogether, and use the RNG EU in slave mode.  Reset the SEC, write the RNG Reset Control Register SR bit, write <anyvalue> to the RNG Data size register, and pull data off the RNG FIFO at will.

Kim

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: mpc8248  SEC -- interrupt handler 'is' invoked
  2005-08-03 20:35                 ` Kim Phillips
@ 2005-08-09 13:38                   ` Vikas Aggarwal
  2005-08-09 15:13                     ` Kim Phillips
  2005-08-09 20:52                   ` Vikas Aggarwal
  1 sibling, 1 reply; 16+ messages in thread
From: Vikas Aggarwal @ 2005-08-09 13:38 UTC (permalink / raw)
  To: Kim Phillips; +Cc: linuxppc-embedded

Does that still use the DMA if i bypass channel infrastructure.?
Do i have to  implement channel-infrastructure in software driver.
-vikas

> On Wed, 3 Aug 2005 14:33:26 -0400 (EDT)
> "Vikas Aggarwal" <va824363@albany.edu> wrote:
>
>> I will try the new BSP but meanwhile like to debug my ported driver.
>>
>> Is there a way , like kernel level single-stepping to know why the
>> "interrupt status register"  gets a value of "0x0000000000000040" which
>> means TEA , transfer error acknowledge.
>
> afaik, TEA usually means memory was unable to be accessed by the sec
> (somewhat along the same lines as a SIGBUS or SIGSEGV).
>
> It's a long shot, but you may want to increase the 4-byte alignment of the
> rng buffer (0x009ffc5c in your trace?) to at least 8-byte.
>
> as for debugging, you can printk sec status registers every time you write
> one, e.g. in a sec register write wrapper fn.  Be sure to check the RNG
> interrupt status register, and the RNG status register, and the RNG
> interrupt control register.
>
> and if all else fails, you can bypass the channel infrastructure
> altogether, and use the RNG EU in slave mode.  Reset the SEC, write the
> RNG Reset Control Register SR bit, write <anyvalue> to the RNG Data size
> register, and pull data off the RNG FIFO at will.
>
> Kim
>

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: mpc8248  SEC -- interrupt handler 'is' invoked
  2005-08-09 13:38                   ` Vikas Aggarwal
@ 2005-08-09 15:13                     ` Kim Phillips
  0 siblings, 0 replies; 16+ messages in thread
From: Kim Phillips @ 2005-08-09 15:13 UTC (permalink / raw)
  To: Vikas Aggarwal; +Cc: linuxppc-embedded

On Tue, 9 Aug 2005 09:38:41 -0400 (EDT)
"Vikas Aggarwal" <va824363@albany.edu> wrote:

> Does that still use the DMA if i bypass channel infrastructure.?

no.

> Do i have to  implement channel-infrastructure in software driver.

it depends on what you want the SEC to do.  If you only want RNG, then no, but if you want to use all the EU's at the same time, then you're probably better off fixing the channel error.

Have you been able to trace the register writes with a wrapper function?  No zero pointers being written to the SEC?  Also, on the 82xx, some bus errors get reported in the PQ2 SUI registers, so you might want to check them, too.

-- 
Kim

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: mpc8248  SEC -- interrupt handler 'is' invoked
  2005-08-03 20:35                 ` Kim Phillips
  2005-08-09 13:38                   ` Vikas Aggarwal
@ 2005-08-09 20:52                   ` Vikas Aggarwal
  2005-08-10 15:37                     ` Kim Phillips
  1 sibling, 1 reply; 16+ messages in thread
From: Vikas Aggarwal @ 2005-08-09 20:52 UTC (permalink / raw)
  To: Kim Phillips; +Cc: linuxppc-embedded

The address returned by kmalloc=0x009ffc5c  is 4 byte aligned.
Are u advicing that dma_map_single() should return 8 byte aligned ,
becuase thats what gets written into the Data-Paclet_descriptor later.

 regards
-vikas

> On Wed, 3 Aug 2005 14:33:26 -0400 (EDT)
> "Vikas Aggarwal" <va824363@albany.edu> wrote:
>
>> I will try the new BSP but meanwhile like to debug my ported driver.
>>
>> Is there a way , like kernel level single-stepping to know why the
>> "interrupt status register"  gets a value of "0x0000000000000040" which
>> means TEA , transfer error acknowledge.
>
> afaik, TEA usually means memory was unable to be accessed by the sec
> (somewhat along the same lines as a SIGBUS or SIGSEGV).
>
> It's a long shot, but you may want to increase the 4-byte alignment of the
> rng buffer (0x009ffc5c in your trace?) to at least 8-byte.
>
> as for debugging, you can printk sec status registers every time you write
> one, e.g. in a sec register write wrapper fn.  Be sure to check the RNG
> interrupt status register, and the RNG status register, and the RNG
> interrupt control register.
>
> and if all else fails, you can bypass the channel infrastructure
> altogether, and use the RNG EU in slave mode.  Reset the SEC, write the
> RNG Reset Control Register SR bit, write <anyvalue> to the RNG Data size
> register, and pull data off the RNG FIFO at will.
>
> Kim
>

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: mpc8248  SEC -- interrupt handler 'is' invoked
  2005-08-09 20:52                   ` Vikas Aggarwal
@ 2005-08-10 15:37                     ` Kim Phillips
  2005-08-11 18:48                       ` Vikas Aggarwal
  0 siblings, 1 reply; 16+ messages in thread
From: Kim Phillips @ 2005-08-10 15:37 UTC (permalink / raw)
  To: Vikas Aggarwal; +Cc: linuxppc-embedded

On Tue, 9 Aug 2005 16:52:04 -0400 (EDT)
"Vikas Aggarwal" <va824363@albany.edu> wrote:

> The address returned by kmalloc=0x009ffc5c  is 4 byte aligned.
> Are u advicing that dma_map_single() should return 8 byte aligned ,
> becuase thats what gets written into the Data-Paclet_descriptor later.
> 
I wouldn't worry about alignment as much as the register write trace and checking the System Interface Unit and individual eu status registers.

-- 
Kim

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: mpc8248  SEC -- interrupt handler 'is' invoked
  2005-08-10 15:37                     ` Kim Phillips
@ 2005-08-11 18:48                       ` Vikas Aggarwal
  0 siblings, 0 replies; 16+ messages in thread
From: Vikas Aggarwal @ 2005-08-11 18:48 UTC (permalink / raw)
  To: Kim Phillips; +Cc: linuxppc-embedded

Hi Kim,
  While browsing the SIU came across TESCR1(0x10040) & TESTCR2(0x10044). I
dumped it during module_init (00000000::00000000)  and also in the ISR
after RNG was submitted to SEC core, this time I got
(0x814a0000::00000000).

TESCR1 after RNG descriptor submitted and SEC-ISR invoked=0x814a0000
bit 0 set -- 60x bus monitor timeout
bit 7-9=  101 --- SEC transaction
bit 11-15=01010 -- TT -- Single-beat-read or burst.

Now looking more into SIU -- SIU-BCR(bus Configuration register=0x10024)
has EBM bit , i set that. Did'nt make any difference. :(

I want to ask -- To make SEC 1.0 as master do i have to do several other
modifications to the SIU configurations so that 60x bus mode is enabled
for internal master. Like PPC_ACR(0x10028)  has 4-7 bits as PRKM-parking
master and PPC_ACR=0100 stands for SEC engine.

-vikas


> On Tue, 9 Aug 2005 16:52:04 -0400 (EDT)
> "Vikas Aggarwal" <va824363@albany.edu> wrote:
>
>> The address returned by kmalloc=0x009ffc5c  is 4 byte aligned.
>> Are u advicing that dma_map_single() should return 8 byte aligned ,
>> becuase thats what gets written into the Data-Paclet_descriptor later.
>>
> I wouldn't worry about alignment as much as the register write trace and
> checking the System Interface Unit and individual eu status registers.
>
> --
> Kim
>

^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2005-08-11 18:48 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-07-29 15:40 mpc8248 SEC -- interrupt handler not invoked Vikas Aggarwal
2005-07-29 20:33 ` Kim Phillips
2005-07-30  3:39   ` Vikas Aggarwal
2005-07-30 23:32     ` Kim Phillips
2005-08-01  0:48       ` mpc8248 SEC -- interrupt handler "is" invoked Vikas Aggarwal
2005-08-01 17:37         ` Kim Phillips
2005-08-01 18:50           ` mpc8248 SEC -- interrupt handler 'is' invoked Vikas Aggarwal
2005-08-02 15:45           ` Vikas Aggarwal
2005-08-03 16:47             ` Kim Phillips
2005-08-03 18:33               ` Vikas Aggarwal
2005-08-03 20:35                 ` Kim Phillips
2005-08-09 13:38                   ` Vikas Aggarwal
2005-08-09 15:13                     ` Kim Phillips
2005-08-09 20:52                   ` Vikas Aggarwal
2005-08-10 15:37                     ` Kim Phillips
2005-08-11 18:48                       ` Vikas Aggarwal

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).