Re: Freescale UCC_GETH Half Duplex Patch
On Fri, 11 Jul 2008 12:46:04 -0500 Kim Phillips <[EMAIL PROTECTED]> wrote: > It needs to be sent to the netdev mailing list, and see if you can get > rid of the MIME-encoding (see linux-2.6/Documentation/email-clients.txt). > > And don't forget to add a signed-off-by line, too. Hi Russell, may I have your signed-off-by so that I may submit this to netdev to be applied on your behalf? I'll keep the attributions intact, of course. Kim ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Freescale UCC_GETH Half Duplex Patch
On Thu, 10 Jul 2008 17:23:31 -0700 "Russell McGuire" <[EMAIL PROTECTED]> wrote: Hi Russel, > Here is a fix up for the UCC_GETH driver supporting half duplex mode for > some specific modes. > > I have tested this quiet extensively and the link now comes up and works, > however not sure if there are other issues that need to be looked at, since > 10BaseT connectivity provides VERY ERRATIC throughput, but at least it works > now with RGMII and GMII modes. good > There was a lot more in my patch, but I removed a lot of the code for > submission. Let me know if for any reason this patch file is improperly > formatted. It needs to be sent to the netdev mailing list, and see if you can get rid of the MIME-encoding (see linux-2.6/Documentation/email-clients.txt). And don't forget to add a signed-off-by line, too. Kim ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 8360 custom board, ucc_geth TX errors on longer(?) packets
On Fri, 01 Feb 2008 16:06:15 -0600 Steven Hein <[EMAIL PROTECTED]> wrote: > Steven Hein wrote: > > But we're using GMII to the switchand that workaround > > code wasn't in active in my old kernel (it was there, but > > commented out). > > > > Any other thoughts?Has anyone seen this symptom before? > > > > Steve > > > OkayI found it!Started poking at the UCCE registers > and found that the FIFO sizes weren't right. This led me > to find a bug in my ucc_geth interface to the fixed-link > PHY driver: the code to reconfigure the MURAM FIFO's for > Gigabit operation wasn't being executed for no-phy configs! > All is well once I changed this. > > Sorry for the noise. (glad I found this before > submitting my patch! ;-) > yeah ucc_geth should be made aware of fixed-links on startup; UCCs aren't like TSECs that know what MII type they're on. setting phy-connection-type to certain strings containing a 'g' in the device tree should do the trick, too..:) Kim ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 8360 custom board, ucc_geth TX errors on longer(?) packets
On Fri, 01 Feb 2008 12:52:25 -0600 Steven Hein <[EMAIL PROTECTED]> wrote: > The one main difference in this board is how eth0 is wired. > We have a Broadcom GbE switch part, and UCC1 eth is wired > directly to that switch (no PHY). (This where I needed to sounds like you ran into some h/w errata. if on rgmii, you might want to find a way to program the switch for rgmii with internal delay (8360 rev.2 rgmii-id rx & tx; 8360rev2.1 rgmii-rxid (i.e. for rx only)). If not, I'd contact fsl tech support directly. Kim ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Configuring Freecale ucc_geth without a PHY
On Tue, 29 Jan 2008 11:08:43 -0600 Steven Hein <[EMAIL PROTECTED]> wrote: > Hi all, > > I have a custom board with an MPC8358 (our board is based > off of the MPC8360E-MDS development board) that has its eth's > directly connected (GMII) to a Broadcom network switch > part on the same board, with no PHYs between them. > We've have been using a 2.6.16.18 kernel (from TimeSys) up > until now, and I hacked in some crude support for no-phy > configs forced to 100Mbit and 1Gbit speeds. Now I'm > moving to 2.6.22 (with 8360 the patches from bitshrine.org), > and I'm trying to understand how I should do this with > device trees, the new PHY infrastructure, etc. Has anyone > else needed this support? Does anyone have any suggestions > as to how to tackle it? check out the "fixed-link" property and associated code. This implementation came about after 2.6.22 though (it's commit-ish v2.6.23-10096-ga21e282). Kim ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: The ds1337 chip on fsl_mp8313E RDB REVA 3 doesn't work properly
On Thu, 20 Sep 2007 17:09:15 +0800 Andrew Liu <[EMAIL PROTECTED]> wrote: > Hello All, > The same u-boot/kernel/rootfs on fsl_mp8313E RDB REVA 2, DS1337 RTC > chip can work, > but on sl_mp8313E RDB REVA 3, it doesn't work, its time don't change. > > This RTC chip specific bad behavior on sl_mp8313E RDB REVA 3 as follows: > (1) On U-Boot (from Freescale), run command: > => i2c md 0x68 0x0 > : 32 33 10 04 20 89 08 84 00 20 53 00 42 16 18 8023.. S.B... looks like your oscillator is turned off (80 in status reg). There are many reasons this can happen - google for 'dallas 1337 rtc' for the chip's documentation to help you diagnose. Kim ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] NET: add MAINTAINERS entry for ucc_geth driver
On Fri, 25 May 2007 13:54:02 +0800 Li Yang <[EMAIL PROTECTED]> wrote: > Signed-off-by: Li Yang <[EMAIL PROTECTED]> Acked-by: Kim Phillips <[EMAIL PROTECTED]> Kim ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Anyone using mpc832x_mds & freescale's GIT repo?
On Tue, 01 May 2007 15:05:44 +0100 Alex Zeffertt <[EMAIL PROTECTED]> wrote: > > Would you recommend using powerpc.git v2.6.21 in preference to the 2.6.11 > kernel that comes with the latest Freescale BSP > (MPC832xE_MDS_K26_20070130-LTIB.iso)? personally, and in general, yes. But it really depends on your application, device driver requirements, etc.. Kim ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Anyone using mpc832x_mds & freescale's GIT repo?
On Tue, 01 May 2007 10:34:09 +0100 Alex Zeffertt <[EMAIL PROTECTED]> wrote: > > mention above. Do you know which *linux* repository is the most > current for the MPC8323E-MDS-PB board? yes, linux..normally I'd say paulus' powerpc.git tree on kernel.org, but today, 832x-MDS is broken there. You might want to checkout the v2.6.21 tag until the pending patches (to support the ucc phylib) are applied and merged. Kim ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Anyone using mpc832x_mds & freescale's GIT repo?
On Mon, 30 Apr 2007 16:15:41 +0100
Alex Zeffertt <[EMAIL PROTECTED]> wrote:
> Hi list,
>
> I've got an MPC8323E-MDS-PB development board, which is
> running a year-old BSP from freescale. I wanted to track
> the most current developments so I cloned
>
> http://opensource.freescale.com/pub/scm/linux-2.6-83xx.git
>
that tree is obsolete; I'll label it so to avoid confusion.
> and rebuilt with ARCH=powerpc and using the mpc832x_mds_defconfig.
>
> I now don't get any serial console output after u-boot has
> started the kernel.
>
> My questions are:
>
> 1.Is anyone else using this GIT repo with this board?
>
please use the mpc83xx custodian tree on denx.de:
{git-,cg-}{clone,pull} git://www.denx.de/git/u-boot-mpc83xx.git
> 2.Is there an example u-boot environment for starting the latest kernels
> on this board?
the nfsboot and ramboot commands found in that board's default
environment specify the fdt address with the new bootm syntax.
>
> 3.Am I using the right ARCH. (I chose ARCH=powerpc because there's
> no defconfig file for this board under arch/ppc!)
>
yup.
Kim
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: U-boot with flat device tree
On Wed, 14 Mar 2007 16:42:49 -0500 "Benedict, Michael" <[EMAIL PROTECTED]> wrote: >Uncompressing Kernel Image ... OK >Booting using flat device tree at 0x100 > > > > are you setting console=ttyS0,115200? Kim ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Who's the maintainer for the freescale MPC8349ITX board?
On Thu, 18 Jan 2007 10:33:55 -0800 [EMAIL PROTECTED] wrote: > Per Grant's suggestion I changed it to: > 'dtc -I dts -O dtb -V 0x10 mpc8349emitx.dts > 8349.blob' > I get a 0 length 8349.blob file using the above. Have you tried -f? Kim ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 8541E and RNG
On Wed, 17 Jan 2007 08:47:01 -0800 "Steve Iribarne (GMail)" <[EMAIL PROTECTED]> wrote: > Anyone ever tried to use the Random Number Generator on the MPC8541E? > I can't get it to behave, so if you've used it and there were any > tricks, I'd appreciate some insite. > the only problem I ran into was I needed to make sure the accesses to the pool were in 64 bits (two sequential 32bit ioreads), after of course resetting the device properly. Feel free to reference talitos_rng_init() and talitos_read_random() from here: http://git.openswan.org/cgi-bin/gitweb.cgi?p=klips;a=blob;h=ec8ccfdb5873e0c583cc50cf23a3521df6834ccd;hb=ocf_v2.6.18;f=crypto/ocf/talitos/talitos.c > I'm using in Linux 2.4.xx. > yeah..the talitos ocf driver needs some modding to work with 2.4, sorry 'bout that. Kim ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Perl
On Mon, 13 Nov 2006 17:56:28 -0500 Lee Revell <[EMAIL PROTECTED]> wrote: > I've been trying to cross compile Perl for a PPC440 board and it just > Is there any easy solution? Can someone send me a binary? > ltib works for me: http://savannah.nongnu.org/projects/ltib/ Kim ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
How to move from /ppc/ to /powerpc/
On Tue, 12 Sep 2006 17:33:16 +0200
Fredrik Roubert wrote:
> Hi!
>
> I have a custom board on which I currently run Linux 2.6.18-rc6
> configured for MPC834x_SYS in the /ppc/ tree, which just a few minor
> changes. Now I'm interested to move to using the /powerpc/ source tree
> instead, but I can't figure out exactly what steps are necessary to do
> this.
>
> Does anyone run a MPC834x_SYS built with ARCH=powerpc?
>
yes
> I boot the board with U-Boot (version 1.1.4, customized), and I assume
> that I need to add some stuff for this new device tree thing, but I
> can't figure out exactly what the kernel will expect.
the kernel expects a pointer to a device tree instead of a bd_t. The 8349EMDS
device tree source is now in linux/arch/powerpc/boot/dts. You'll need the
device tree compiler (dtc) from jdl.com to build your flat device tree binary
(dtb; what the kernel expects).
>
> Does anyone have some pointers on how to do this?
>
Matt's u-boot patches address the issue well for 85xx, they are straightforward
to adapt to 83xx:
http://sourceforge.net/mailarchive/forum.php?thread_id=15518792&forum_id=12898
they allow you to tftp the dtb into mem, and "bootm ${loadaddr} - ${oftaddr}"
to start an ARCH=powerpc kernel.
> Cheers // Fredrik Roubert
Kim
Re: How to move from /ppc/ to /powerpc/
On Tue, 12 Sep 2006 17:33:16 +0200
Fredrik Roubert <[EMAIL PROTECTED]> wrote:
> Hi!
>
> I have a custom board on which I currently run Linux 2.6.18-rc6
> configured for MPC834x_SYS in the /ppc/ tree, which just a few minor
> changes. Now I'm interested to move to using the /powerpc/ source tree
> instead, but I can't figure out exactly what steps are necessary to do
> this.
>
> Does anyone run a MPC834x_SYS built with ARCH=powerpc?
>
yes
> I boot the board with U-Boot (version 1.1.4, customized), and I assume
> that I need to add some stuff for this new device tree thing, but I
> can't figure out exactly what the kernel will expect.
the kernel expects a pointer to a device tree instead of a bd_t. The 8349EMDS
device tree source is now in linux/arch/powerpc/boot/dts. You'll need the
device tree compiler (dtc) from jdl.com to build your flat device tree binary
(dtb; what the kernel expects).
>
> Does anyone have some pointers on how to do this?
>
Matt's u-boot patches address the issue well for 85xx, they are straightforward
to adapt to 83xx:
http://sourceforge.net/mailarchive/forum.php?thread_id=15518792&forum_id=12898
they allow you to tftp the dtb into mem, and "bootm ${loadaddr} - ${oftaddr}"
to start an ARCH=powerpc kernel.
> Cheers // Fredrik Roubert
Kim
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Realtime preemption patch on PPC
On Fri, 11 Aug 2006 09:38:45 -0500 Brent Cook wrote: > On Thursday 10 August 2006 18:04, Ben Weintraub wrote: > I have gotten them to work with MPC7448 boards, but it has hardware floating > point, so no math-emu problems. > > > Anyhow, when I boot on an MPC8555 with my hack, I get an endless stream > > of: if you can, you might want to rebuild your binaries with -msoft-float Kim
GNU and Freescale MPC83xx / e300 core support?
according to one of our architects, the 81xx, 82xx, 83xx, 52xx, and 51xx (all G2/e300 based parts) all share the same 603 pipeline: o dispatch 2 instructions, plus 1 branch per cycle, o up to 5 instructions in the pipeline at any given time, o a maximum of 2 instructions are completed per cycle. the changes are: o multiple HID0, HID1, HID3 bits for optimizing system, o icbt o PLL options so, the answer is no, modifying the compiler's scheduler won't do anything for you. as Kumar says, the caches and adding icbt to your code does improve performance. Kim On Tue, 7 Mar 2006 10:03:53 -0600 Kumar Gala wrote: > > On Mar 7, 2006, at 9:54 AM, Russell McGuire wrote: > > > Thanks all... > > > > The author of that comment humbly apologizes for his ineptitude on > > the FPU. > > > > It would appear both cores have the same number of execution units, > > i.e. 5 > > So David, I guess in all this the only real difference seems to be > > the bus > > architecture, raw clock speed, and perhaps a few new instructions. > > I checked > > both manuals this morning and they do differ in some small ways. > > > > * 603e, up to 4 instructions in the pipeline, only 3 being complete > > per > > clock > > * e300, up to 5 instructions in the pipeline, still only 3 being > > completed > > or start per clock. > > * Add/compare instructions are now executed in the IU unit instead > > of the > > load/store unit. May be the same, but wasn't specific in earlier 603e > > manuals. > > * One more HID0 bit than G2, ability to interrupt based on cache > > parity > > error > > * new icbt instruction, instruction cache initialization > > > > So there is a section inside the 8360E manual that outlines the > > specific > > enhancements. "Features specific to the e300 core not present on > > the G2 > > processors follow:" Page 1-5. > > > > So I guess my question is back up, does anyone know if an optimized > > compiler > > would offer any noticeable performance enhancements in regards to > > these > > changes? Other than the obvious instruction being added? > > If you are asking about relative performance between the same > compiler tuned for a 603 vs e300, the there would most likely be a > small improvement. > > However, a few things to note. The new icbt instruction is really > intended for hand written assemble code and its highly unlikely that > a compiler will ever generate it. Second, the other improvements > from the base 603e/G2LE in 8280, like doubling of the L1 caches has a > significant improvement in performance. > > - kumar > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded at ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded --
8248 SEC
On Thu, 20 Oct 2005 03:58:00 -0700 "Wojciech Kromer" wrote: > Is there any driver for security-engine on mpc8248? > If yes, what can it do? where can I found it? > follow the mpc8272 links at: http://www.metrowerks.com/MW/Develop/Embedded/Linux/DownloadBSP.htm Kim --
ads8272 SEC problem on 2.4.18
okay, the devtech team has ported the 2.4 SEC driver to 2.6 (and finally fixed this issue). It is a direct port from the 2.4 driver - so whatever limitations exist in the 2.4 version will exist in this. It's available on the Codewarrior BSP site: http://www.metrowerks.com/MW/Develop/Embedded/Linux/DownloadBSP.htm Use the MPC8272ADS 2.6 Kernel link. Kim On Wed, 7 Sep 2005 05:56:11 -0400 (EDT) "Vikas Aggarwal" wrote: > I had the similar error with SEC1 for 8248. My RNG DPD could not generate > desired result. After DPD address written my ISR was invoked but all i had > is TEA error, or bus error etc when i checked the Status Registers. > > regards > -vikas > > > HiHo! > > > > I am trying to get the SEC engine running on a ads8272 > > but i am completely stuck now. (It feels like the problem > > we saw on this list last month, but there is still no solution > > to that issue yet. > > > > Quick Problem description: > > initialize seems, ok, yet when i feed a single > > dpd (for DES EU) into channel 0, the engine > > seems to stuck during fetch. Nothing happens. > > > > Questions: > > - Can someone help me out? (Not sure if this is the right list for this?) > > - Do (open) sources for the SEC1 (motorola/freescale) engine exist for > > vanilla linux? > > (I know of Arabella, but they are neither open nor for vanilla linux) > > > > ciao > > Markus > > > > P.S. some more details below > > > > more info: > > - i hopefully initialized it correctly > > - prepared a dpd > > - wrote it into fetch register > > - see that something happens: CurrentDescriptorPR changes > > - boing, that's it... no more > > > > some dumps: > > Before writing the fetch register: > > CryptoChannelConfigRegister (f0042008), 0x 0x071c > > CryptoChannelPointerStatusRegister (f0042010), 0x 0x0007 > > CryptoChannelCurrentDescriptorPointerRegister (f0042040), 0x > > 0x > > CryptoChannelFetchDescriptorRegister (f0042048), 0x 0x > > CryptoChannelDescriptorBufferRegister 0 (f0042080), 0x > > > > after writing to fetch register > > CryptoChannelConfigRegister (f0042008), 0x 0x071c > > CryptoChannelPointerStatusRegister (f0042010), 0x0002 0x0007 > > CryptoChannelCurrentDescriptorPointerRegister (f0042040), 0x > > 0x002e9a98 > > CryptoChannelFetchDescriptorRegister (f0042048), 0x 0x > > CryptoChannelDescriptorBufferRegister 0 (f0042080), 0x > > > > CCPSR changes to 2 (error), but i don't know why? > > Nothing else (at least nothing i can see) happens. > > -- > > markus schaefer --- software engineer > > epygi labs de gmbh > > herrenstrasse 23 > > d-76133 karlsruhe, germany > > tel: +49 (721) 205 96 30 -- fax: +49 (721) 205 96 59 > > sip: 20444 at sip.epygi.com > > *email removed, but it is easy to guess* > > http://www.epygi.de > > > > ___ > > Linuxppc-embedded mailing list > > Linuxppc-embedded at ozlabs.org > > https://ozlabs.org/mailman/listinfo/linuxppc-embedded > > > > > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded at ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded --
mpc8248 SEC -- interrupt handler 'is' invoked
On Tue, 9 Aug 2005 16:52:04 -0400 (EDT) "Vikas Aggarwal" 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
MPC8555CDS & CCSRBAR
or this...
static int sec_probe(struct device *device)
{
struct platform_device *pdev = to_platform_device(device);
struct resource *r;
sec_irq = platform_get_irq(pdev, 0);
rc = request_irq(sc->sc_irq, talitos_intr, 0, "talitos", sc);
if (rc) {
printk("failed to hook irq %d\n", sec_irq);
sec_irq = -1;
goto out;
}
/* we read its hardware registers as memory */
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
sec_base_addr = (ocf_iomem_t) ioremap(r->start, (r->end - r->start));
if (!sec_base_addr) {
printk("failed to ioremap 0x%x-0x%x\n",
(u32)r->start, (u32)r->end - (u32)r->start);
goto out;
}
...
}
Kim
On Tue, 09 Aug 2005 17:53:42 +0200
Clemens Koller wrote:
> Hi!
>
> You might want to try that:
>
> #include
> #include/* see mail archives for complete
> mpc8540 version */
> ...
>
> void foo(void)
> {
> volatile ccsr_t *immap;
> phys_addr_t ccsrbar;
>
> ccsrbar=get_ccsrbar();
> immap=ioremap(ccsrbar,sizeof(ccsr_t));/* is
> ioremap_nochache() the same on mpc85xx? */
> if (!immap) {
> printk(KERN_ALERT "Failed to ioremap CCSRBAR!\n");
> err = -EIO;
> goto out;
> }
>
> /* examples */
> printk(KERN_INFO "CCSRBAR addr%.8lx\n",ccsrbar);
> printk(KERN_INFO "IMMAP addr %p\n",immap);
> printk(KERN_INFO "BR0%.8x\n",immap->im_lbc.br0);
> printk(KERN_INFO "OR0%.8x\n",immap->im_lbc.or0);
>
> /* unmap the ccsr*/
> iounmap(immap);
> out:
> }
>
> I hope that's all current code.
> Comments are welcome.
>
> Greets,
>
> Clemens Koller
> ___
> R&D Imaging Devices
> Anagramm GmbH
> Rupert-Mayer-Str. 45/1
> 81379 Muenchen
> Germany
>
> http://www.anagramm.de
> Phone: +49-89-741518-50
> Fax: +49-89-741518-19
>
>
> Gerhard Jaeger wrote:
> > On Tuesday 09 August 2005 16:04, Eric Kampman wrote:
> >
> >>Trying to port an SEC driver to Linux/PPC8555. Reading
> >>the default CCSRBAR @ 0xFF70 I read 0x
> >>which is wrong. Looking at Metrowerks init files and
> >>uboot code (1.1.2) I see it's likely been moved to
> >>0xE000, but I get a seg fault when I try to read
> >>there.
> >>
> >>So, what am I doing wrong, and even better, how do I
> >>at runtime find out where CCSRBAR is? Thanks in
> >>advance, and please forgive the likely ignorance,
> >>
> >>Eric
> >>
> >
> >
> > use the get_ccsrbar() function to get the address, then ioremap()
> > will be your friend ;)
> >
> > HTH
> > Gerhard
>
> ___
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
--
Kim
mpc8248 SEC -- interrupt handler 'is' invoked
On Tue, 9 Aug 2005 09:38:41 -0400 (EDT) "Vikas Aggarwal" 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
mpc8248 SEC -- interrupt handler 'is' invoked
On Wed, 3 Aug 2005 14:33:26 -0400 (EDT) "Vikas Aggarwal" 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 "0x0040" 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 to the RNG Data size register, and pull data off the RNG FIFO at will. Kim
mpc8248 SEC -- interrupt handler 'is' invoked
On Tue, 2 Aug 2005 11:45:15 -0400 (EDT) "Vikas Aggarwal" 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
mpc8248 SEC -- interrupt handler "is" invoked
On Sun, 31 Jul 2005 20:48:16 -0400 (EDT) "Vikas Aggarwal" 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
mpc8248 SEC -- interrupt handler not invoked
On Fri, 29 Jul 2005 23:39:32 -0400 (EDT) "Vikas Aggarwal" 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
mpc8248 SEC -- interrupt handler not invoked
On Fri, 29 Jul 2005 11:40:27 -0400 (EDT) "Vikas Aggarwal" 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
