Re: MPC5121 CAN and USB

nds of things that make it crash. If you know the limitations of this and can live with it, it might be bearable... I don't have any other option :-( Best regards, -- David Jander Protonic Holland. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Best hardware platform for native compiling...

On Tuesday 21 July 2009 14:00:07 you wrote: > On Tue, Jul 21, 2009 at 12:31:36PM +0200, David Jander wrote: > > On Tuesday 21 July 2009 11:52:51 you wrote: > > > On Tue, Jul 21, 2009 at 11:16:52AM +0200, David Jander wrote: > > > > For bigger systems we often run a

Re: Best hardware platform for native compiling...

On Tuesday 21 July 2009 11:52:51 you wrote: > On Tue, Jul 21, 2009 at 11:16:52AM +0200, David Jander wrote: > > For bigger systems we often run a debian-derived OS like Ubuntu, and many > > pieces are compiled natively on the target... just because it is easy and > > q

Best hardware platform for native compiling...

-xfbdev" from ubuntu 9.04 on a MPC5121e it will take 40 minutes ;-) -- David Jander Protonic Holland. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 02/12] fs_enet: Add MPC5121 FEC support.

egister-I/O the driver does, overall performance impact _may_ still be negligible. I suggest testing this (benchmarks) before and after the change. Best regsards, -- David Jander Protonic Holland. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: MPC5121 new board constantly resetting after u-boot passes control to Linux

s that do special things for the ADS, that will probably break things for you. Please also fix your u-boot BSP... Best regards, -- David Jander Protonic Holland. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 02/12] fs_enet: Add MPC5121 FEC support.

on 512x. > > Actually, I *am* asking for one image that runs on 83xx, 52xx and > 521x. I already can and do build and test a single image which boots > on all my 52xx boards, on my 8349 board, and on my G4 Mac. Cool! I also want that! We have different boards with 5200 and 5121e'

Re: [PATCH 06/12] mpc5121: Added NAND Flash Controller driver.

c_write_buf; > + chip->verify_buf = mpc5121_nfc_verify_buf; > + chip->select_chip = mpc5121_nfc_select_chip; > + chip->options = NAND_NO_AUTOINCR | NAND_USE_FLASH_BBT; > + chip->ecc.mode = NAND_ECC_SOFT; > + > + /* Support external chip-select logic on ADS5121 board

MPC5200 FEC driver crashing on 2.6.30-rc1....

80be0098 [ 1319.633037] 41920104 813c0264 7d200034 5400d97e <0f00> 801a5218 3c854000 7f63db78 [ 1319.649160] ---[ end trace a3057d5e6d98e2c6 ]--- Best regards, -- David Jander Protonic Holland. ___ Linuxppc-dev mailing list Linuxppc-dev@

Re: Issue with UART driver on MPC5121e Platform

own hardware, or are you using the ADS5121? What version of the MPC5121e processor do you have? M34K, 2M34K or M36P? Regards, -- David Jander Protonic Holland. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [RFC][PATCH v5] MPC5121 TLB errata workaround

On Monday 16 March 2009 19:05:00 Kumar Gala wrote: > On Mar 16, 2009, at 10:52 AM, David Jander wrote: > > Complete workaround for DTLB errata in e300c2/c3/c4 processors. > > > > Due to the bug, the hardware-implemented LRU algorythm always goes > > to way > > 1 of

Re: [RFC][PATCH v5] MPC5121 TLB errata workaround

79 MByte/s (180 Mbyte/s previous patch) Conclusion: difference not measurable between v4 and v5. Best regards, -- David Jander Protonic Holland. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev

[RFC][PATCH v5] MPC5121 TLB errata workaround

: David Jander --- diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_32.S index 0f4fac5..3971ee4 100644 --- a/arch/powerpc/kernel/head_32.S +++ b/arch/powerpc/kernel/head_32.S @@ -578,9 +578,21 @@ DataLoadTLBMiss: andcr1,r3,r1/* PP = user? (rw&dirt

Re: [RFC][PATCH v4] powerpc/mm: e300c2/c3/c4 TLB errata workaround

3 is trashed. > - mfspr r3,SPRN_SRR1/* Need to restore CR0 */ > - mtcrf 0x80,r3 > rfi > > + .balign L1_CACHE_BYTES > +sw_way_lru: > + .long 0 > + Ok, I'll try to do it like this, but with lru stored in SPRG6 Best regards, -- David Jander Protonic Holland. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [RFC][PATCH v4] MPC5121 TLB errata workaround

ch v4, lrw in SPRG6): 180 MByte/s Best regards, -- David Jander Protonic Holland. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev

[RFC][PATCH v4] MPC5121 TLB errata workaround

bits of SPRG6 for chosing the TLB-way. Signed-off-by: David Jander --- diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_32.S index 0f4fac5..6cc0cd3 100644 --- a/arch/powerpc/kernel/head_32.S +++ b/arch/powerpc/kernel/head_32.S @@ -540,9 +540,13 @@ DataLoadTLBMiss: * r2: ptr

Re: [RFC] [PATCH v2] MPC5121 TLB errata workaround

odify my own patch (with ifdef's instead of CPU_FTR...) to give you feedback on performance impacts, while you implement it as CPU_FTR afterwards for mainline? That way I can avoid doing double work, and spend more time on testing it actually If you agree, I'll start hacking away on the SPRG version immediately :-) Best regards, -- David Jander Protonic Holland. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [RFC] [PATCH v2] MPC5121 TLB errata workaround

s interesting. I am just learning my first steps in powerpc-assembly, so please forgive if this is a little inefficient still. I'll try again next week. Greetings, -- David Jander Protonic Holland. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [RFC] [PATCH v2] MPC5121 TLB errata workaround

On Friday 13 March 2009 14:22:22 Kumar Gala wrote: > > On Mar 13, 2009, at 5:26 AM, David Jander wrote: > > > > > Forgot to mention: The patch is based on denx git tree head > > 'ads5121', but > > it should apply without problem (some offset

Re: [RFC] [PATCH v2] MPC5121 TLB errata workaround

Forgot to mention: The patch is based on denx git tree head 'ads5121', but it should apply without problem (some offset at most) to mainline. Best regards, -- David Jander Protonic Holland. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs

[RFC] [PATCH v2] MPC5121 TLB errata workaround

the TLB-way. Signed-off-by: David Jander --- arch/powerpc/kernel/head_32.S | 65 1 files changed, 65 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_32.S index 0f4fac5..a88b3aa 100644 --- a/arch/powerpc

Re: Proposal: [PATCH] Workaround for MPC5121 DTLB errata

/s for memory-2-memory cases. Greetings, -- David Jander Protonic Holland. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev

Proposal: [PATCH] Workaround for MPC5121 DTLB errata

bits 15...19 of source and destination address are the same. Signed-off-by: David Jander --- arch/powerpc/kernel/head_32.S |8 1 files changed, 8 insertions(+), 0 deletions(-) --- a/arch/powerpc/kernel/head_32.S +++ b/arch/powerpc/kernel/head_32.S @@ -614,6 +614,14

Re: MPC5121e, MBX driver, pvr.ko ...

IANAL), but what if there was a driver like NVidia's video drivers (i.e. binary object with a re-compileable shell around it to adapt it to other kernels)? Otherwise, I guess Freescale can just as well stop making the MPC5121e and just make MPC5123's instead

Re: MPC5121e, MBX driver, pvr.ko ...

eek at least *grrr*. Btw, it has nothing to do with the prio-manager or the DRAM controller whatsoever. Best regards, -- David Jander Protonic Holland. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev

MPC5121e, MBX driver, pvr.ko ...

k binary compatibility for the drivers :-( Any hint is appreciated... Best regards, -- David Jander Protonic Holland. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Efficient memcpy()/memmove() for G2/G3 cores...

g the DRAM controller and prio-manager for example) or a silicon-errata (John?) Thanks a lot for your help so far. -- David Jander ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Efficient memcpy()/memmove() for G2/G3 cores...

cases for length and alignment. > > You can always do better if you know exactly what processor you are on > and what specific sizes and alignment your application uses. Yes, I know that's a problem. Thanks for the information for "average siz

Re: Efficient memcpy()/memmove() for G2/G3 cores...

concern, especially for other processors, as the MPC5200B, where there doesn't seem to be so much to gain anyway. > Of course, I could be totally wrong. I haven't had my coffee yet this > morning after all. You're doing quite good regardless of your lack of caffeine ;-) Greetings, -- David Jander ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Efficient memcpy()/memmove() for G2/G3 cores...

ly size where the additional overhead has some impact (which is negligible). Another thing is that performance probably matters most to the end-user when applications need to copy big amounts of data (e.g. video frames or bitmap data), which is most probably done using big blocks of memcpy(

Re: Efficient memcpy()/memmove() for G2/G3 cores...

fpu instructions. Does anybody have any suggestion about where to start searching for an explaination of these results? I have the impression that there is something wrong with my setup, or with the e300c4-core, or both, but what Greetings, -- David Jander ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Efficient memcpy()/memmove() for G2/G3 cores...

; > only very limited time to dedicate to this and I am looking for others > > who have > > Well this will be a good learning experience for you. We will try to > answer questions. Excellent. I love learning new stuff ;-) Thanks a lot for the guidance so far... Regards, --

Re: Efficient memcpy()/memmove() for G2/G3 cores...

> 22 Mbyte/s), but still far from the 71.5 Mbyte/s achieved when using bigger strides of 16 registers load/store at a time. Note, that this is copy performance, one-way througput should be double these figures. I'll try to learn how cache manipulating instructions work, to see if I ca

Re: Efficient memcpy()/memmove() for G2/G3 cores...

loading via > > LD_PRELOAD or /etc/ld_preload... > > > > Maybe once this collection is more stable (in terms of that heavy > > tweaking has stopped) one could try the pilgrimage towards glibc > > inclusion > > I believe that's the wrong approach as it leads to never-merged out-of > tree code. Hmm... you mean, it'll be easier to keep patching (improving) things once they are already in glibc? Interesting. Thanks a lot for your comments. Best regards, -- David Jander ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Efficient memcpy()/memmove() for G2/G3 cores...

On Wednesday 27 August 2008 23:04:39 Steven Munroe wrote: > On Tue, 2008-08-26 at 08:28 +1000, Benjamin Herrenschmidt wrote: > > On Mon, 2008-08-25 at 15:06 +0200, David Jander wrote: > > > Hi Matt, > > > > > > On Monday 25 August 2008 13:00:10 Matt Sealey wro

Re: Efficient memcpy()/memmove() for G2/G3 cores...

is a lot of scope I think for optimizing several points (glibc, > kernel, some applications) for embedded processors which nobody is > really taking on. But, not many people want to do this kind of work.. They should! It makes a HUGE difference. I surely will of course. Greetings,

Efficient memcpy()/memmove() for G2/G3 cores...

Now I am certain that most of the G2/G3 users on this list _must_ have a better solution for this. Any suggestions? Btw, the tests are done on Ubuntu/PowerPC 7.10, don't know if that matters though... Best regards, -- David Jander ___ Linuxppc-dev

Re: [PATCH 2/8][Version 2] MPC5121 clock driver

(rate == 0) { > + printk(KERN_WARNING > + "No bus-frequency in dev tree using 66MHz\n"); Just nit-picking, but there should be a comma after "tree". Greetings, -- David Jander Protonic Holland.

Re: [PATCH] Added support for PRTLVT based boards (MPC5121)

fix our DT and resubmit that one. Greetings, -- David Jander Protonic Holland. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] Added support for PRTLVT based boards (MPC5121)

rms/512x/mpc5121_generic.c similarity index 73% > > rename from arch/powerpc/platforms/512x/mpc5121_ads.c > > rename to arch/powerpc/platforms/512x/mpc5121_generic.c > > index 50bd3a3..824ddbb 100644 > > --- a/arch/powerpc/platforms/512x/mpc5121_ads.c > > +++ b/arch/powerpc/platforms/512x/mpc5121_generic.c >[...] The idea is to make it as simple as possible to add new platforms that are basically just derivatives of the same. Greetings, -- David Jander Protonic Holland. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 2/2] Re-added support for FEC on MPC5121 from Freescale LTIB to current head

On Thursday 12 June 2008 14:12:15 you wrote: > On Jun 12, 2008, at 6:45 AM, David Jander wrote: > > Your commit message isn't exactly helpful as most people dont know > what LTIB is and its not terribly relevant. It just seems like you > are adding support for the FEC on MP

[PATCH] Added support for PRTLVT based boards (MPC5121)

Made MPC5121_ADS board support generic: Renamed arch/powerpc/platforms/512x/mpc5121_ads.c and added list of supported boards. For both MPC5121 ADS or PRTLVT support, just select "MPC5121_GENERIC" and use the corresponding device-tree. Signed-off-by: David Jander <[EMAIL PROTECTE

[PATCH 2/2] Re-added support for FEC on MPC5121 from Freescale LTIB to current head

Signed-off-by: David Jander <[EMAIL PROTECTED]> --- arch/powerpc/platforms/Kconfig |2 +- drivers/net/fec.h | 43 drivers/net/fs_enet/Kconfig| 22 +- drivers/net/fs_enet/fs_enet-main.c

[PATCH 1/2] Added support for PRTLVT based boards (MPC5121)

Made MPC5121_ADS board support generic: Renamed arch/powerpc/platforms/512x/mpc5121_ads.c and added list of supported boards. For both MPC5121 ADS or PRTLVT support, just select "MPC5121_GENERIC" and use the corresponding device-tree. Signed-off-by: David Jander <[EMAIL PROTECTE