MPC860 CP / CPM Misbehaving
but I chose to stick with Fix #2 Fix #2 as well gives you a 100% performance boost regards Harald
MPC860 CP / CPM Misbehaving
An update (and solution) to the problem I was having...Thanks to everyone who sent me suggestions! I'm using a custom MPC860 based embedded board and having problems with SCC1 and SMC1 reception. I have SCC1 setup in ethernet mode, and SMC1 setup in UART mode. The general problem manifests itself as getting receive buffer descriptors (BDs) from the CPM with the OV bit set (bit 14 of the RxBD status/control field, Overrun. Set when a receiver overrun occurs during reception). I was apparently the victim of errata in the MPC860, possibly related to a published errata CPU5 - Instruction MMU bug at page boundaries in show-all mode. Either one of the following fixed the problem, but I chose to stick with Fix #2 since Fix #1 has some other errata associated with it for various MPC860 silicon versions. Fix #1) Enable SIUMCR[DSHW] - Show address and data of all internal data cycles. Not entirely clear why this would have helped, and there's errata saying NOT to do this (e.g. SIU2) Fix #2) Disable show all mode (per CPU5), in my case set ICTRL[ISCT_SER]=011 Core is fully serialized/no show cycles is performed for fetched instructions. Tim
MPC860 CP / CPM Misbehaving
descriptors (BDs) from the CPM with the OV bit set (bit 14 of the RxBD status/control field, Overrun. Set when a receiver overrun occurs during reception). Check the following: - SDRAM setup. If ORx(BIH)=1 makes the problem go away, your burst setup or the /TA pullup is broken. NB: Neither the SCC nor the SMC do bursts. - Check pullups as per UM recommendation. I tend to recommend 1k. - Did you by accident happen to enable any IDMA lines? - Did you happen to misconfigure RCCR(DRxM)? - Did you happen to misconfigure the SDCR? One other thing. If you have an old BDM debugger *and* if the problem occurs *only* with the BDM debugger hooked up, you may want to check for an update or replacement. Old debuggers sometimes used a method to do BDM which could stall the DMAs in the machine and cause this kind of overrun/underrun effect. Heinz
MPC860 CP / CPM Misbehaving
descriptors (BDs) from the CPM with the OV bit set (bit 14 of the RxBD status/control field, Overrun. Set when a receiver overrun occurs during reception). - SDRAM setup. If ORx(BIH)=1 makes the problem go away, your burst setup or the /TA pullup is broken. NB: Neither the SCC nor the SMC do bursts. I checked my SDRAM setup. SDRAM is the only device configured with UPMA and it's on cs1, so I checked UPMA, OR1, BR1, MAMR configuration along with MCR/MAR process for issuing precharge, refresh, and SDRAM mode register config per the datasheet for the parts. This board is a few years old, so I wasn't able to find the datasheet the original timings were made from - instead I looked at the datasheet for the parts we're using now, and (since the parts we're using now are faster) our memory timings are somewhat conservative. I did try disabling bursts, with no luck. Not sure what NB means. - Did you by accident happen to enable any IDMA lines? No - Did you happen to misconfigure RCCR(DRxM)? RCCR is all zero's except RCCR[ERAM]=b11 since I have the SCC/SMC microcode patch. Even though IDMA is disabled, I have tried setting RCCR[DRPQ]=b10 to make IDMA requests have the lowest priority (didn't help/hurt). The DRxM bits are edge sensitive. - Did you happen to misconfigure the SDCR? SDCR[FRZ] = 0 (ignore the freeze signal) SDCR[FAID] = 0 (highest priority default, although I'm not using FEC). SDCR[RAID] = b01 (priority level 5) One other thing. If you have an old BDM debugger *and* if the problem occurs *only* with the BDM debugger hooked up, you may want to check for an update or replacement. Old debuggers sometimes used a method to do BDM which could stall the DMAs in the machine and cause this kind of overrun/underrun effect. Hmm...interesting. How old? Does this happen when actively debugging (setting breakpoints, etc) or just running with no breakpoints set? I have two different debuggers, a OCD raven wiggler and a BDM module for my HP16702A logic analyzer. I have to run different debugger software on each for licensing reasons (SingleStep 7.5 on the raven and GHS MULTI4.0.5 on the HP). The problem occurs on both. Heinz
MPC860 CP / CPM Misbehaving
In message 846BA3AF7C8A2048937F1801FD3129C902DB5942 at messenger.viasat.com you wrote: I'm using a custom MPC860 based embedded board and having problems with SCC1 and SMC1 reception. I have SCC1 setup in ethernet mode, and SMC1 setup in UART mode. The general problem manifests itself as getting receive buffer descriptors (BDs) from the CPM with the OV bit set (bit 14 of the RxBD status/control field, Overrun. Set when a receiver overrun occurs during reception). ... This isn't a board hardware problem, the board runs fine with other software (different operating system, etc). It's most likely a configuration problem on my end. speculation Are you 100% sure that your SDRAM is working fine when stressed with burst mode accesses? See http://www.denx.de/twiki/bin/view/DULG/UBootCrashAfterRelocation /speculation My thoughts are that it's almost as if the CP (CPM RISC processor) or SDMA is being occasionally frozen out while the core PowerPC MPC860 processor is You may see funny problems when your SDRAM is not working right. And yes, this may happen especially on DMA transfers which will use burst mode. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de ... Hiroshima 45 ... Chernobyl 86 ... Windows 95 ...
MPC860 CP / CPM Misbehaving
In message 846BA3AF7C8A2048937F1801FD3129C902DB5944 at messenger.viasat.com you wrote: The SDRAM timings (UPM registers) are setup by a BDM/JTAG debugger script. The UPM setup is only half of the story. Please check with your SDRAM manufacturer's manual for the _complete_ initialization sequence that is necessary on your chips. The same script is run when I download the other software, which works. This is no indication that the setup is right. We have seen pSOS+ and VxWorks running fine on some systems, and Linux constantly crashing on the same hardware because of bad SDRAM initialization. See the FAQ section in the DULG. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Old programmers never die, they just become managers.
MPC860 CP / CPM Misbehaving
Not so much a linux question, as a general MPC860 question, but maybe someone out there can help. I'm using a custom MPC860 based embedded board and having problems with SCC1 and SMC1 reception. I have SCC1 setup in ethernet mode, and SMC1 setup in UART mode. The general problem manifests itself as getting receive buffer descriptors (BDs) from the CPM with the OV bit set (bit 14 of the RxBD status/control field, Overrun. Set when a receiver overrun occurs during reception). For example, when receiving an ICMP ping over SCC1, I typically get the first 40-64 bytes of the standard 78 byte ICMP message. For another example, with no activity on SCC1, receive activity on SMC1 can also result in receive RxBDs with the OV bit set. There is also some weirdness where activity on SCC1 results in CPM interrupts (and RxBDs filled) for SMC1. I am testing my code by running from a BDM/JTAG debugger. To throw a wrench in things, the above weirdness does not occur if the core processor is halted at a breakpoint (e.g. if the core is halted at a breakpoint, the CPM continues to run and the entire 78 byte ICMP message shows up in an SCC1 RxBD). This isn't a board hardware problem, the board runs fine with other software (different operating system, etc). It's most likely a configuration problem on my end. I have verified that: * Clocks are setup for correct frequency and routing (SCC1 getting CLK1/CLK2, SMC1 getting BRG1). * Low power mode (MSR[POW] and PLPRCR[LPM]) is not being entered. * I/O ports (PA, PB, PC, PD) configured correctly. * I'm using the Motorola/Frescale microcode patch (MPC860MC05.zip) that allows SMC1 and SCC3 to be used at the same time. SMC1 dual port ram parameter area is remapped correctly. Not that this matters in this configuration, since I'm not even enabling SCC3 for this test. I've also tried it without the microcode patch and get the same results. My thoughts are that it's almost as if the CP (CPM RISC processor) or SDMA is being occasionally frozen out while the core PowerPC MPC860 processor is running. The FIFO internal to the CPM between SCC1 and the CP is 32 bytes, so the fact that I'm getting a little more than 32 bytes makes me think that the CP is being kicked off, and someone gets slowed down/stopped, then the FIFO overflows. So I'm getting however many bytes the CP can process at the start of a transmissions plus the 32 bytes in the FIFO before the overflow occurs. So if this is true, what could stop the CP from running? Tim
MPC860 CP / CPM Misbehaving
Wolfgang, The SDRAM timings (UPM registers) are setup by a BDM/JTAG debugger script. The same script is run when I download the other software, which works. That being said, I wasn't the one who wrote the UPM portion of the script and it is one of the few things I haven't verified, so it does sound like a likely candidate. Thanks for the tip. Tim -Original Message- From: wd at denx.de [mailto:[EMAIL PROTECTED] Sent: Friday, May 13, 2005 4:42 PM To: Martin, Tim Cc: 'linuxppc-embedded at ozlabs.org' Subject: Re: MPC860 CP / CPM Misbehaving In message 846BA3AF7C8A2048937F1801FD3129C902DB5942 at messenger.viasat.com you wrote: I'm using a custom MPC860 based embedded board and having problems with SCC1 and SMC1 reception. I have SCC1 setup in ethernet mode, and SMC1 setup in UART mode. The general problem manifests itself as getting receive buffer descriptors (BDs) from the CPM with the OV bit set (bit 14 of the RxBD status/control field, Overrun. Set when a receiver overrun occurs during reception). ... This isn't a board hardware problem, the board runs fine with other software (different operating system, etc). It's most likely a configuration problem on my end. speculation Are you 100% sure that your SDRAM is working fine when stressed with burst mode accesses? See http://www.denx.de/twiki/bin/view/DULG/UBootCrashAfterRelocation /speculation My thoughts are that it's almost as if the CP (CPM RISC processor) or SDMA is being occasionally frozen out while the core PowerPC MPC860 processor is You may see funny problems when your SDRAM is not working right. And yes, this may happen especially on DMA transfers which will use burst mode. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de ... Hiroshima 45 ... Chernobyl 86 ... Windows 95 ...
