No L2 Cache on PReP Machine
Hi I am usign Linux on the Motorola MVME3604 Board. This Board complies to the PReP standard. So I configured the linux machine type to CHRP/PowerMac/PReP. The kernel starts without showing any errors, but the problem is, that the L2 cache of the board is not recognized by the kernel. Does the linux not support L2 caches on PReP machines or is it another problem? Best regards, Johannes ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
No L2 Cache on PReP Machine
On Thu, 2004-08-19 at 08:43, Hager, Johannes, HRD/AB wrote: I am usign Linux on the Motorola MVME3604 Board. This Board complies to the PReP standard. So I configured the linux machine type to CHRP/PowerMac/PReP. The kernel starts without showing any errors, but the problem is, that the L2 cache of the board is not recognized by the kernel. Does the linux not support L2 caches on PReP machines or is it another problem? Generally Linux expects the boot firmware to set up the L2 and L3 caches on PowerPC machines. Are you quite sure (from benchmark timings) that the L2 cache is not working? The MVME3604 has an L2 cache outside the processor, and it should work transparently. - Adrian Cox Humboldt Solutions Ltd ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
No L2 Cache on PReP Machine
Hi, Generally Linux expects the boot firmware to set up the L2 and L3 caches on PowerPC machines. Are you quite sure (from benchmark timings) that the L2 cache is not working? The MVME3604 has an L2 cache outside the processor, and it should work transparently. First the /proc/cpuinfo file contains the following informations: processor : 0 cpu : 604r clock : 400MHz revision : 49.2 (pvr 0009 3102) bogomips: 399.76 machine : PReP MVME 3600 with MVME761 l2 cache: none simms : I did the following test on this machine afte which I decided that the L2 cache is not used. I have a test program on VxWorks which takes about 110 ms for execution on the MVME3604 with enable L2 cache I ported this application to a RTAI module and did the test on linux and it took about 420ms So i disabled the L2 cache in VxWorks and did the test again and then it took with VxWorks about 417ms. After this and because of the content from /proc/cpuinfo I decided that the L2 cache is not used. BTW I am using kernel 2.4.25 Best regards, Johannes ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
inline assembly code in MPC8245...
hello all, we need some example programs on inline assembly code for MPC8245 powerpc processor... please can anybody send it Regards Madhukar ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
No L2 Cache on PReP Machine
On Thu, 2004-08-19 at 10:04, Hager, Johannes, HRD/AB wrote: I have a test program on VxWorks which takes about 110 ms for execution on the MVME3604 with enable L2 cache I ported this application to a RTAI module and did the test on linux and it took about 420ms So i disabled the L2 cache in VxWorks and did the test again and then it took with VxWorks about 417ms. After this and because of the content from /proc/cpuinfo I decided that the L2 cache is not used. That's very convincing. If you have the source of your VxWorks BSP it may be worth looking for code where VxWorks enables the L2 cache. You'll need to add a MVME3604 specific patch to your kernel to turn the cache on. I've just looked at prep_setup.c, and there are already lots of board specific L2 handling routines, but none for MVME3604. - Adrian Cox Humboldt Solutions Ltd. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[RFC] Test patch for Sandpoint X2
The attached patch puts support for Sandpoint X2 back into Linux 2.6. Unlike my previous attempts, this patch detects the Sandpoint model at runtime. I only have an X2 here, so I would appreciate reports of the code being unbroken on the X3. The patch causes EPIC_SERIAL_MODE to be a runtime rather than compile time decision. It also changes the UART interrupts from level to edge, which on my X2 is required in order to work with the serial driver in 2.6. I'd also like to know if this breaks the X3. Any comments? - Adrian Cox Humboldt Solutions Ltd. -- next part -- A non-text attachment was scrubbed... Name: sandpoint-1.patch Type: text/x-patch Size: 8558 bytes Desc: Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20040819/96ef2d3a/attachment.bin
[RFC] Test patch for Sandpoint X2
On Aug 19, 2004, at 10:35 AM, Adrian Cox wrote: Any comments? Thank you :-) I have both X2 and X3 systems. I will test them as time permits. -- Dan ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
405EP and pci_alloc_consistent()
Hi Folks, I've got a wlan driver I'm running on a 405EP target with the 2.4.27 rsynch'd from the mvista site last week (my customer did that, I don't have the exact details). This device/driver relies on a dma'd 'control block' where all the queues (heads,tails,metadata etc.) are managed. We allocate that block with pci_alloc_consistent(). I had some trouble with stale values until I wrapped all the accesses of the block with invalidate_dcache_range() before reads and flush_dcache_range() after writes. I don't have a problem with the necessity to do all that, but it does leave me a little uncomfortable. I thought the pci_alloc_consistent call should mark the tlb entrie(s) for that memory as non-cacheable. Am I missing something? Thanks, -Mark -- Mark S. Mathews AbsoluteValue Systems Web:http://www.linux-wlan.com 721-D North Drive e-mail: mark at linux-wlan.com Melbourne, FL 32934Phone: 321.259.0737 USAFax:321.259.0286 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
PCI problem on MPC8250 target
I am trying to debug a problem I have with a custom MPC8250 target board. This board uses the 8250 host-pci bridge. Off the pci bus there is a three-port pci-pci bridge. Hanging off one port of this bridge are a number of DSP chips. I am using kernel 2.6.8.1. I had been debugging this on 2.4.24 from ELDK, but 2.6 appears to have resolved some of the problems I had identified. The pci bios appears to see both functions of the bridge and three devices on bus 1. The problem is in allocating resources for the devices. I hope that someone here can save me some time and indicate where I should be looking for the problem. The hardware is first prototype and therefore no guarantees as to how it is behaving. A possible issue is that the bios only sees three out of four DSPs. The first DSP (device number zero) is not seen. I have been ignoring this problem for the moment, assuming that this is some simple issue like device zero being special. We can easily change the hardware to move this device number if that is the case. PCI: Probing PCI hardware PCI: bridge rsrc 0..ff (100), parent c0185008 PCI: bridge rsrc 8000..9fff (1200), parent c0185024 PCI: bridge rsrc a000..afff (200), parent c0185024 PCI: bridge rsrc 0..fff (101), parent c01e6038 PCI: bridge rsrc 0..f (200), parent c01e6070 PCI: Cannot allocate resource region 1 of PCI bridge 1 PCI: bridge 1 resource 1 moved to aff0..afff PCI: bridge rsrc 0..f (1201), parent c01e6054 PCI: Cannot allocate resource region 2 of PCI bridge 1 PCI: bridge 1 resource 2 moved to 9ff0..9fff PCI: bridge rsrc 0..fff (101), parent c01e6038 PCI: reparented PCI Bus #01 [0..fff] under PCI Bus #02 PCI: bridge rsrc 0..f (200), parent c01e6070 PCI: Cannot allocate resource region 1 of PCI bridge 2 PCI: bridge 2 resource 1 moved to afe0..afef PCI: bridge rsrc 0..f (1201), parent c01e6054 PCI: Cannot allocate resource region 2 of PCI bridge 2 PCI: bridge 2 resource 2 moved to 9fe0..9fef PCI::00:00.0: Resource 0: -0001 (f=200) PCI: Cannot allocate resource region 0 of device :00:00.0 PCI: parent is c01e6070: a000-afff (f=200) PCI::00:00.0: Resource 1: -01ff (f=1208) PCI: Cannot allocate resource region 1 of device :00:00.0 PCI: parent is c01e6054: 8000-9fff (f=1200) PCI::01:01.0: Resource 0: -003f (f=1208) PCI: Cannot allocate resource region 0 of device :01:01.0 PCI: parent is c1fd2604: 9ff0-9fff (f=1201) PCI::01:01.0: Resource 1: -007f (f=200) PCI: Cannot allocate resource region 1 of device :01:01.0 PCI: parent is c1fd25e8: aff0-afff (f=200) PCI::01:01.0: Resource 2: -000f (f=101) PCI::01:02.0: Resource 0: -003f (f=1208) PCI: Cannot allocate resource region 0 of device :01:02.0 PCI: parent is c1fd2604: 9ff0-9fff (f=1201) PCI::01:02.0: Resource 1: -007f (f=200) PCI: Cannot allocate resource region 1 of device :01:02.0 PCI: parent is c1fd25e8: aff0-afff (f=200) PCI::01:02.0: Resource 2: -000f (f=101) PCI: Cannot allocate resource region 2 of device :01:02.0 PCI: parent is c1fd25cc: -0fff (f=101) PCI::01:03.0: Resource 0: -003f (f=1208) PCI: Cannot allocate resource region 0 of device :01:03.0 PCI: parent is c1fd2604: 9ff0-9fff (f=1201) PCI::01:03.0: Resource 1: -007f (f=200) PCI: Cannot allocate resource region 1 of device :01:03.0 PCI: parent is c1fd25e8: aff0-afff (f=200) PCI::01:03.0: Resource 2: -000f (f=101) PCI: Cannot allocate resource region 2 of device :01:03.0 PCI: parent is c1fd25cc: -0fff (f=101) PCI: Failed to allocate mem resource #0:40 at a000 for :01:01.0 PCI: Failed to allocate mem resource #1:80 at b000 for :01:01.0 PCI: Failed to allocate mem resource #0:40 at a000 for :01:02.0 PCI: Failed to allocate mem resource #1:80 at b000 for :01:02.0 PCI: Failed to allocate I/O resource #2:10 at 1000 for :01:02.0 PCI: Failed to allocate mem resource #0:40 at a000 for :01:03.0 PCI: Failed to allocate mem resource #1:80 at b000 for :01:03.0 PCI: Failed to allocate I/O resource #2:10 at 1000 for :01:03.0 Conor ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
405EP and pci_alloc_consistent()
On Thu, Aug 19, 2004 at 01:11:30PM -0400, Mark S. Mathews wrote: This device/driver relies on a dma'd 'control block' where all the queues (heads,tails,metadata etc.) are managed. We allocate that block with pci_alloc_consistent(). I had some trouble with stale values Could you elaborate a little on what stale means? until I wrapped all the accesses of the block with invalidate_dcache_range() before reads and flush_dcache_range() after writes. I don't have a problem with the necessity to do all that, but it does leave me a little uncomfortable. I thought the pci_alloc_consistent call should mark the tlb entrie(s) for that memory as non-cacheable. Am I missing something? Yes, your expectations are correct. I'd check PCI bridge behavior here. Maybe your problem is caused by the bridge doing its own caching (prefetching and/or write posting). -- Eugene ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
405EP and pci_alloc_consistent()
On Thu, 19 Aug 2004, Eugene Surovegin wrote: On Thu, Aug 19, 2004 at 01:11:30PM -0400, Mark S. Mathews wrote: This device/driver relies on a dma'd 'control block' where all the queues (heads,tails,metadata etc.) are managed. We allocate that block with pci_alloc_consistent(). I had some trouble with stale values Could you elaborate a little on what stale means? Occasionally (can't be any more specific than that) the code that reads out the queue head index for our receive queue hands me a value corresponding to a frame that that was just previously handled. until I wrapped all the accesses of the block with invalidate_dcache_range() before reads and flush_dcache_range() after writes. I don't have a problem with the necessity to do all that, but it does leave me a little uncomfortable. I thought the pci_alloc_consistent call should mark the tlb entrie(s) for that memory as non-cacheable. Am I missing something? Yes, your expectations are correct. I'd check PCI bridge behavior here. Maybe your problem is caused by the bridge doing its own caching (prefetching and/or write posting). Agreed. One of the hw engineers responsible for the board design pointed me at some text in the 405 manual. Haven't had the opportunity to check it out yet. If this turns out to be the case, it'll be interesting to ponder how my current 'fix' is altering the behavior. Thanks for the input, -Mark -- Mark S. Mathews AbsoluteValue Systems Web:http://www.linux-wlan.com 721-D North Drive e-mail: mark at linux-wlan.com Melbourne, FL 32934Phone: 321.259.0737 USAFax:321.259.0286 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
405GPr PCI target/host
I am trying to get an IBM 405GPr processor to work as a target/host on a PCI bus. A PCI target can temporarily become a host on the PCI bus. Basically this means it needs to do everything the host currently does except assigning PCI memory space, the dedicated host is responsible for this. I saw a message concerning this on Tue 12/23/2003 4:20 PM, the questions was for MPC7447(Dual CPU) + MV64360 based Processor PMC boards I only saw one response to this and it did not seem to be correct. I was wondering if anyone has done something like this, not necessarily with a 405, any processor experience will do. I appreciate any help or advice. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
405GPr PCI target/host
On Thu, 2004-08-19 at 19:28, Steven Blakeslee wrote: I am trying to get an IBM 405GPr processor to work as a target/host on a PCI bus. A PCI target can temporarily become a host on the PCI bus. Basically this means it needs to do everything the host currently does except assigning PCI memory space, the dedicated host is responsible for this. [snip] I was wondering if anyone has done something like this, not necessarily with a 405, any processor experience will do. I appreciate any help or advice. I've written drivers for several systems of this form. Generally people are trying to do one of the following: 1) Communicate between the PCI root (running Linux, Windows, or anything else) and embedded Linux on a non-root processor. This requires a custom driver, but is essentially straightforward. Eugene Surovegin has described this elsewhere in the thread. 2) Communicate between embedded Linux on a non-root processor and custom electronics on another non-root device. This also requires a straightforward custom driver. 3) Use a standard Linux device driver running on a non-root processor to control a standard PCI device elsewhere on the bus. This is usually unsolvable without a custom motherboard to provide the required interrupt routing. Most people give up and use a non-transparent PCI bridge instead. Does your requirement fit one of those? - Adrian Cox http://www.humboldt.co.uk/ ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
