* 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).