* All-ones problem with FCC1 on MPC8541 @ 2004-10-28 17:20 Stefan Nickl 2004-10-28 18:02 ` Mark Chambers 2004-11-18 10:13 ` Stefan Nickl 0 siblings, 2 replies; 7+ messages in thread From: Stefan Nickl @ 2004-10-28 17:20 UTC (permalink / raw) To: linuxppc-embedded Hi all, I'm trying to port my version of linuxppc-2.4 from 8540 to 8541. The point I'm stuck at right now is the FCC that replaces the FEC. I checked port configuration and clock routing registers in cpm2_io/fcc_enet.c again and again, but all I get in and out is ones. The packet sizes I receive look reasonable, but the buffers are filled only with 0xff. The same goes for sending, the contents of the buffers are OK (dhcp discover...), but when capturing the output on the other side with ethereal, the packet is again all 0xff. We just discovered that apparently preamble, frame delimiter and FCS go out over the MII (at least TxD[0:3] change state), so I don't suspect a hardware bug. Any ideas? -- Stefan Nickl Kontron Modular Computers ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: All-ones problem with FCC1 on MPC8541 2004-10-28 17:20 All-ones problem with FCC1 on MPC8541 Stefan Nickl @ 2004-10-28 18:02 ` Mark Chambers 2004-10-29 12:50 ` Stefan Nickl 2004-11-18 10:13 ` Stefan Nickl 1 sibling, 1 reply; 7+ messages in thread From: Mark Chambers @ 2004-10-28 18:02 UTC (permalink / raw) To: Stefan Nickl; +Cc: linuxppc-embedded > I checked port configuration and clock routing registers in > cpm2_io/fcc_enet.c again and again, but all I get in and out is ones. > > The packet sizes I receive look reasonable, but the buffers are > filled only with 0xff. The same goes for sending, the contents > of the buffers are OK (dhcp discover...), but when capturing > the output on the other side with ethereal, the packet is again > all 0xff. > > We just discovered that apparently preamble, frame delimiter and FCS go > out over the MII (at least TxD[0:3] change state), so I don't suspect a > hardware bug. > I would guess the problem is at the DMA level, that the FCC is reading/writing ffs to/from memory for some reason. The preamble and FCS come from the FCC itself, not memory, so that's why you see them. I'd guess some kind of mismatch with the kind of cycles generated by the FCC DMA and the memory controllers. Mark Chambers ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: All-ones problem with FCC1 on MPC8541 2004-10-28 18:02 ` Mark Chambers @ 2004-10-29 12:50 ` Stefan Nickl 2004-10-29 13:29 ` Mark Chambers 2004-10-29 14:22 ` Kumar Gala 0 siblings, 2 replies; 7+ messages in thread From: Stefan Nickl @ 2004-10-29 12:50 UTC (permalink / raw) To: Mark Chambers; +Cc: linuxppc-embedded On Thu, 2004-10-28 at 14:02 -0400, Mark Chambers wrote: > > The packet sizes I receive look reasonable, but the buffers are > > filled only with 0xff. The same goes for sending, the contents > > of the buffers are OK (dhcp discover...), but when capturing > > the output on the other side with ethereal, the packet is again > > all 0xff. > > > > We just discovered that apparently preamble, frame delimiter and FCS go > > out over the MII (at least TxD[0:3] change state), so I don't suspect a > > hardware bug. > > > > I would guess the problem is at the DMA level, that the FCC is > reading/writing > ffs to/from memory for some reason. The preamble and FCS come from the > FCC itself, not memory, so that's why you see them. I'd guess some kind > of mismatch with the kind of cycles generated by the FCC DMA and the > memory controllers. I've tried loopback mode today, and it's the same story: only 0xff on the receiving end. We looked hard at the manuals for anything that could cause the kind of DMA problems you describe, but yet to no avail. The chapter about SDMA seems to mainly describe some error status registers, and they remain at their default value when running the FCC. We'll try to get hold of CDS eval board schematics to check more on the hardware side, in the meantime, do you have an idea of which registers to look at in particular? -- Stefan Nickl Kontron Modular Computers ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: All-ones problem with FCC1 on MPC8541 2004-10-29 12:50 ` Stefan Nickl @ 2004-10-29 13:29 ` Mark Chambers 2004-10-29 14:22 ` Kumar Gala 1 sibling, 0 replies; 7+ messages in thread From: Mark Chambers @ 2004-10-29 13:29 UTC (permalink / raw) To: Stefan Nickl; +Cc: linuxppc-embedded > On Thu, 2004-10-28 at 14:02 -0400, Mark Chambers wrote: > > > The packet sizes I receive look reasonable, but the buffers are > > > filled only with 0xff. The same goes for sending, the contents > > > of the buffers are OK (dhcp discover...), but when capturing > > > the output on the other side with ethereal, the packet is again > > > all 0xff. > > > > > > We just discovered that apparently preamble, frame delimiter and FCS go > > > out over the MII (at least TxD[0:3] change state), so I don't suspect a > > > hardware bug. > > > > > > > I would guess the problem is at the DMA level, that the FCC is > > reading/writing > > ffs to/from memory for some reason. The preamble and FCS come from the > > FCC itself, not memory, so that's why you see them. I'd guess some kind > > of mismatch with the kind of cycles generated by the FCC DMA and the > > memory controllers. > > I've tried loopback mode today, and it's the same story: > only 0xff on the receiving end. That would still be consistent with a memory access problem. > We looked hard at the manuals for anything that could cause the > kind of DMA problems you describe, but yet to no avail. > The chapter about SDMA seems to mainly describe some error status > registers, and they remain at their default value when running the FCC. > > We'll try to get hold of CDS eval board schematics to check more on the > hardware side, in the meantime, do you have an idea of which registers > to look at in particular? > Unfortunately, I don't know anything specific about the 8541 [so why the &^%* are you saying anything?] What I do know is that we had a similar problem back in the 68360 days. My memory of the exact solution is a bit vague, but I clearly remember the 'all-ffs' packets. So I hope this isn't a red herring. But what do we know - we know the FCC is correctly generating and receiving ethernet packets. There has to be a legitimate premable and FCS or ethereal wouldn't see the packets at all. And on receive you see a correct length packet, just bad data. So the question is, where is FCC getting data from and saving to? Is the 8541 cache-coherent like the 82xx family? Maybe try flushing/ invalidating cache to make sure program data is getting to/from physical memory? Maybe it's an MMU translation problem - code and the FCC are not really accessing the same physical addresses? Perhaps you can try manually disabling cache and/or MMU, or trying to send a packet from ROM (I know it would be garbage, but if it's not FF you know you're on to something). This is all assuming you are using a debugger and can break into the driver and play with things... Mark Chambers ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: All-ones problem with FCC1 on MPC8541 2004-10-29 12:50 ` Stefan Nickl 2004-10-29 13:29 ` Mark Chambers @ 2004-10-29 14:22 ` Kumar Gala 2004-10-29 14:47 ` Stefan Nickl 1 sibling, 1 reply; 7+ messages in thread From: Kumar Gala @ 2004-10-29 14:22 UTC (permalink / raw) To: Stefan Nickl; +Cc: linuxppc-embedded [snip] > We'll try to get hold of CDS eval board schematics to check more on the > hardware side, in the meantime, do you have an idea of which registers > to look at in particular? Did not realize you were using a CDS, but physical ethernet port on the board do you believe the FCC is hooked up to? While, some of the issues you are having in internal loopback seem to mean other problems, I believe the FCCs are only available for ethernet over some additional adapter add on cards. - kumar ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: All-ones problem with FCC1 on MPC8541 2004-10-29 14:22 ` Kumar Gala @ 2004-10-29 14:47 ` Stefan Nickl 0 siblings, 0 replies; 7+ messages in thread From: Stefan Nickl @ 2004-10-29 14:47 UTC (permalink / raw) To: Kumar Gala; +Cc: linuxppc-embedded On Fri, 2004-10-29 at 09:22 -0500, Kumar Gala wrote: > [snip] > > We'll try to get hold of CDS eval board schematics to check more on the > > hardware side, in the meantime, do you have an idea of which registers > > to look at in particular? > > Did not realize you were using a CDS, but physical ethernet port on the > board do you believe the FCC is hooked up to? While, some of the No, sorry you got me wrong on that. I don't have access to a CDS, we have swapped processors on some of our EB8540 (EEBrain) modules. The board supports 8540 and 8541 since as our hardware guy tells me, the MII lines from the 8540's FEC are N/C on the 8541 BGA balls, as are the 8541's FCC1 lines in respect to the 8540 BGA balls. I just assume the 8541 works on the CDS ;-), so we might spot a helpful difference to our board's schematics. > issues you are having in internal loopback seem to mean other problems, > I believe the FCCs are only available for ethernet over some additional > adapter add on cards. Can you please confirm the CDS setup you describe does actually work with linuxppc-2.4 v2.4.27_linuxppc and U-Boot built from the public CVS? Regards, -- Stefan Nickl Kontron Modular Computers ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: All-ones problem with FCC1 on MPC8541 2004-10-28 17:20 All-ones problem with FCC1 on MPC8541 Stefan Nickl 2004-10-28 18:02 ` Mark Chambers @ 2004-11-18 10:13 ` Stefan Nickl 1 sibling, 0 replies; 7+ messages in thread From: Stefan Nickl @ 2004-11-18 10:13 UTC (permalink / raw) To: linuxppc-embedded On Thu, 2004-10-28 at 19:20 +0200, Stefan Nickl wrote: > The packet sizes I receive look reasonable, but the buffers are > filled only with 0xff. The same goes for sending, the contents > of the buffers are OK (dhcp discover...), but when capturing > the output on the other side with ethereal, the packet is again > all 0xff. To whom it may concern: We finally solved it! >From what I can tell, it's a bug in both linuxppc-2.4 AND the manual. It's all about the values of RIPTR and TIPTR in the FCC parameter RAM, to work on the MPC8541/MPC8555 they must not assume the values that the current public kernel sets them to, and what is suggested by the manual. First the manual bug: "For best performance, it should be located in the following address ranges: 0x3000-0x4000 or 0xB000-0xC000." However, the "Internal Dual-Port Data RAM Memory Map" shows both of these ranges as "Reserved" in the MPC8555 manual (different from the MPC8560 manual). This is also not mentioned in the latest errata. Next the linux bug: This is from cpm.h in the public kernel: #ifdef CONFIG_8272 #define CPM_DATAONLY_SIZE ((uint)(8 * 1024) - CPM_DATAONLY_BASE) #define CPM_FCC_SPECIAL_BASE ((uint)0x00009000) #else #define CPM_DATAONLY_SIZE ((uint)(16 * 1024) - CPM_DATAONLY_BASE) #define CPM_FCC_SPECIAL_BASE ((uint)0x0000b000) #endif and this is from cpm.h in the metrowerks 8555 kernel: #if (defined(CONFIG_8272) || defined(CONFIG_8555)) #define CPM_DATAONLY_SIZE ((uint)(8 * 1024) - CPM_DATAONLY_BASE) #define CPM_FCC_SPECIAL_BASE ((uint)0x00009000) #else #define CPM_DATAONLY_SIZE ((uint)(16 * 1024) - CPM_DATAONLY_BASE) #define CPM_FCC_SPECIAL_BASE ((uint)0x0000b000) #endif Note that little difference? :) When the internal buffers are placed in the non-reserved region, it just works. Greetings, -- Stefan Nickl Kontron Modular Computers ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2004-11-18 10:14 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2004-10-28 17:20 All-ones problem with FCC1 on MPC8541 Stefan Nickl 2004-10-28 18:02 ` Mark Chambers 2004-10-29 12:50 ` Stefan Nickl 2004-10-29 13:29 ` Mark Chambers 2004-10-29 14:22 ` Kumar Gala 2004-10-29 14:47 ` Stefan Nickl 2004-11-18 10:13 ` Stefan Nickl
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox