[PATCH] Insight Memec Virtex-II Pro Development Board support
Mind is making available a set of Linux kernel patches adding support for the Insight Memec Virtex-II Pro Development Board using Memec's reference design for Linux on ftp://ftp.mind.be/Virtex2Pro/patch-v2.4.23_linuxppc_2_4_devel/. This version of the patches is against kernel version 2.4.23 in the linuxppc_2_4_devel tree, BitKeeper tag v2.4.23_linuxppc_2_4_devel. If needed, we can also submit the diff against the linuxppc_2_4 tree. We commit to maintaining this port on an ongoing basis against the linuxppc_2_4 tree. The patches should be applied in the following order: ftp://ftp.mind.be/Virtex2Pro/patch-v2.4.23_linuxppc_2_4_devel/patch-platform-insightv2pro board-specific platform support patch for the 405D5X[12] CPU_212 bug (see http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=14052) ftp://ftp.mind.be/Virtex2Pro/patch-v2.4.23_linuxppc_2_4_devel/patch-uartlite Xilinx UART Lite support (not board-specific) ftp://ftp.mind.be/Virtex2Pro/patch-v2.4.23_linuxppc_2_4_devel/patch-memec-emac MemecCore Ethernet MAC support (not board-specific) ftp://ftp.mind.be/Virtex2Pro/patch-v2.4.23_linuxppc_2_4_devel/patch-mtd MTD support for the NOR flash on the P160 comm module ftp://ftp.mind.be/Virtex2Pro/patch-v2.4.23_linuxppc_2_4_devel/patch-defconfig board default configuration -- There are 10 types of people in the world: Those who understand binary, and those who don't. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
tcp retrans timeout!!!
Hello, I have a question about TCP packet retrans timeout. (1) How to know TCP packet retrans timeout(how long)? (2) How to change TCP packet retrans timeout? Thanks in advance. Brijesh -Original Message- From: [EMAIL PROTECTED] [mailto:owner-linuxppc-embedded at lists.linuxppc.org]On Behalf Of Matt Porter Sent: Friday, December 12, 2003 8:16 PM To: Stefan Roese Cc: 'DaveyWu'; 'Linuxppc-Embedded'; benh at kernel.crashing.org; akuster at mvista.com Subject: Re: PPC4xx enet driver problem (version 2.0) On Fri, Dec 12, 2003 at 11:56:09AM +0100, Stefan Roese wrote: > > Davey! > > No, we didn't solve this problem so far. Eugene did some tests on an > ppc440 board and had no problems with the multiple enet devices. So it > seems to be 405ep related! I still have to send some debug output to > Eugene (hopefully today)! [I haven't followed the thread but new EMAC driver and 405EP rings a bell] It's possible that the new method in which OCP code handles OCP device dependencies has a bug. 405ep is a special case since it requires a particular EMAC device to provide MDIO operations for both EMACs. 440gp/gx don't follow this code path. -Matt ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
close to porting success.....
Hi Qsyang: On Friday 12 December 2003 04:36, Qsyang wrote: > dear all, > I am porting U-boot-1.0.0 to my custom MPC8xx board and success is > being expectted coming soon(maybe too conceited^&^). Now i have a > question which describes below. > So far it is working fine when i am using BDI2000 and runing 'BDI>go > 0x02800100' in Telnet console,and then all the U-boot commands are > working very well. > But when i disconnected BDI and power on board directly ,U-Boot > crasheed after relocation to RAM. FAQ say that SDRAM initialization is > bad ,if this is the case why it is OK when using BDI to boot it. What's > the difference between the two conditions? Maybe some hardware problem? Maybe there's some SDRAM controller initialization in BDI2000 configuration file that's missing in your U-boot code. You should check this first. Have fun, -Scop. > > Any help would be highly appreciated ! > > > Qsyang > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
PCI display adapter / MPC5200
Hello, I am using the latest CVS version from the Denx LinuxPPC_2_4_devel tree. Apparently the PCI bridge on the MPC5200 should be fully supported in the linux kernel, but I am having varying results with PCI adapters on the Lite5200 eval board. A Belkin USB-4 port adapter (PCI 3.3V/5V) is successfully detected and can be accessed. However, an ATI Radeon 7000 PCI (also 3.3V/5V) adapter is simply not detected (when doing a scan through PCI config space). As I would like to be able to have graphical output on the Lite5200, I would like to know if anybody has been successful in using a PCI display adapter on the Lite5200 with a recent LinuxPPC_2_4_devel tree ? Thanks. Best Regards, David Mazur ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
MPC852T with SCC3 and SMC1
Hi Torsten, I did all my tests in PPCBoot bootloader since I don't expect any additional problems in Linux. Attached you can find a patch for cup/mpc8xx/serial.c in PPCBoot. Regards, Stephan > -Original Message- > From: Demke, Torsten [mailto:Torsten.Demke at fci.com] > Sent: Donnerstag, 11. Dezember 2003 10:57 > To: Stephan Linke > Subject: RE: MPC852T with SCC3 and SMC1 > > > Hello Stephan, > > thanks for your help. > Do you made changes in the Linux uart.c driver > to work with the relocated data structures? > > Regards, > Torsten > > > -Original Message- > > From: Stephan Linke [mailto:Stephan.Linke at epygi.de] > > Sent: Donnerstag, 11. Dezember 2003 08:02 > > To: Demke, Torsten > > Subject: RE: MPC852T with SCC3 and SMC1 > > > > > > Hi Thorsten, > > > > you should look for a 860 microcode. It's a microcode that > > allowes relocating SMC, I2C and SMC. I already did some tests > > with it on > > a 852T and it finaly worked fine. But I had a lot of trouble > > getting PPCBoot running on it but that was due to some a giant array > > allocated on the stack (console buffer). > > > > > > Regards, Stephan > > > > > -Original Message- > > > From: owner-linuxppc-embedded at lists.linuxppc.org > > > [mailto:owner-linuxppc-embedded at lists.linuxppc.org]On > > Behalf Of Demke, > > > Torsten > > > Sent: Mittwoch, 10. Dezember 2003 18:24 > > > To: linuxppc-embedded at lists.linuxppc.org > > > Subject: MPC852T with SCC3 and SMC1 > > > > > > > > > > > > Hello all, > > > > > > At one of our boards were using the MPC852T. > > > It will use the SMC1 as UART _and_ SCC3 with ethernet. > > > (SCC4 will also run ethernet.) > > > I know that SCC3 will overlap the Parameter RAM of SMC1 and > > > I guess that there is a microcode patch to relocate the SMC1. > > > > > > There is already a microcode patch mentioned in the 8xx_io/ > > directory > > > but it doesnt work at my board. Somebody uses this > > microcode to relocate > > > SMC1? (to which address?) > > > > > > I also tried to find a microcode patch for MPC852T > > > at the motorola web-site but without success. > > > Can anybody give me a hint where to find this microcode? > > > > > > Thanks for your help. > > > > > > Best regards, > > > > > > Torsten Demke > > > > > > > > > > > -- next part -- A non-text attachment was scrubbed... Name: serial.c.patch Type: application/octet-stream Size: 1467 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20031212/a9d7a032/attachment.obj
MPC7410
I wrote: > > Is anybody out there working with the MPC7410. It is similar to the > MPC7450. > > I am wondering what, if any, --with-cpu or -mcpu switch is appropriate > for this CPU. Sorry to follow-up on my own post, but I discovered some information. I contacted somebody in our semiconductor group and he was able to tell me that the 7400, which does have a gcc command line switch, and the 7410 are essentially the same from a register point of view. The 7410 has an additional register that allows one to use the L2 cache, which is larger than that on the 7400, as SRAM. Or something like that anyway. The --with-cpu=7400 or -mcpu=7400 is the best option to use with the 7410. For those interested, there is plenty of information available here: http://e-www.motorola.com/webapp/sps/site/prod_summary.jsp?code=MPC7410&node Id=03C1TR046708718653 Regards, Aron ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
MPC7410
Hello, Is anybody out there working with the MPC7410. It is similar to the MPC7450. I am wondering what, if any, --with-cpu or -mcpu switch is appropriate for this CPU. Thanks, Aron ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
PPC4xx enet driver problem (version 2.0)
Davey! No, we didn't solve this problem so far. Eugene did some tests on an ppc440 board and had no problems with the multiple enet devices. So it seems to be 405ep related! I still have to send some debug output to Eugene (hopefully today)! By the way: Did you notice that your MAC-address of the 2nd ethernet channel (eth1) is 00:00:00:00:00:00? This is wrong and probably a problem in passing MAC-addresses from your bootloader to linux. What bootloader are you using? U-Boot/OpenBios? Best regards, Stefan. > -Original Message- > From: DaveyWu [mailto:daveywu at transengines.com] > Sent: Friday, December 12, 2003 3:40 AM > To: Stefan Roese; Linuxppc-Embedded; > benh at kernel.crashing.org; akuster at mvista.com > Subject: Re: PPC4xx enet driver problem (version 2.0) > > > Hi Stefan, > I have suffered the same problem when I am trying swtich > to 2.4.22 from 2.4.18 on IBM405ep board. Following is the > output on my board: > > # ifconfig eth0 down > # ifconfig eth1 down > # ifconfig eth0 192.168.1.1 > eth0: adjust to link, speed: 100, duplex: 1, opened: 1 > eth0: Speed: 100, Full duplex. > # ping 192.168.1.123 > PING 192.168.1.123 (192.168.1.123): 56 data bytes > 64 bytes from 192.168.1.123: icmp_seq=0 ttl=128 time=5.2 ms > 64 bytes from 192.168.1.123: icmp_seq=1 ttl=128 time=2.8 ms > 64 bytes from 192.168.1.123: icmp_seq=2 ttl=128 time=2.7 ms > 64 bytes from 192.168.1.123: icmp_seq=3 ttl=128 time=2.6 ms > 64 bytes from 192.168.1.123: icmp_seq=4 ttl=128 time=2.7 ms > 64 bytes from 192.168.1.123: icmp_seq=5 ttl=128 time=2.7 ms > > --- 192.168.1.123 ping statistics --- > 6 packets transmitted, 6 packets received, 0% packet loss > round-trip min/avg/max = 2.6/3.1/5.2 ms # ifconfig eth1 192.168.2.1 > eth1: adjust to link, speed: 100, duplex: 1, opened: 1 > eth1: Speed: 100, Full duplex. > SIOCSIFFLAGS: Device or resource busy > # ifconfig > eth0 Link encap:Ethernet HWaddr 00:04:AC:E3:15:5E > inet addr:192.168.1.1 Bcast:192.168.1.255 > Mask:255.255.255.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:104 errors:0 dropped:0 overruns:0 frame:0 > TX packets:7 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:100 > RX bytes:10027 (9.7 kiB) TX bytes:630 (630.0 iB) > Interrupt:15 > > loLink encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > UP LOOPBACK RUNNING MTU:16436 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:0 (0.0 iB) TX bytes:0 (0.0 iB) > > # ping 192.168.1.123 > PING 192.168.1.123 (192.168.1.123): 56 data bytes > > --- 192.168.1.123 ping statistics --- > 25 packets transmitted, 0 packets received, 100% packet loss > # ifconfig -a > eth0 Link encap:Ethernet HWaddr 00:04:AC:E3:15:5E > inet addr:192.168.1.1 Bcast:192.168.1.255 > Mask:255.255.255.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:104 errors:0 dropped:0 overruns:0 frame:0 > TX packets:15 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:100 > RX bytes:10027 (9.7 kiB) TX bytes:966 (966.0 iB) > Interrupt:15 > > eth1 Link encap:Ethernet HWaddr 00:00:00:00:00:00 > inet addr:192.168.2.1 Bcast:192.168.2.255 > Mask:255.255.255.0 > BROADCAST MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:100 > RX bytes:0 (0.0 iB) TX bytes:0 (0.0 iB) > Interrupt:17 > > loLink encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > UP LOOPBACK RUNNING MTU:16436 Metric:1 > RX packets:25 errors:0 dropped:0 overruns:0 frame:0 > TX packets:25 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:2800 (2.7 kiB) TX bytes:2800 (2.7 kiB) > > # > Have you already solved the problem? > > - Original Message - > From: "Stefan Roese" > To: "Linuxppc-Embedded" > ; > ; > Sent: Wednesday, December 03, 2003 7:29 PM > Subject: PPC4xx enet driver problem (version 2.0) > > > > > > Hello! > > > > We are trying to switch to the 2.4.23 linuxppc_2_4_devel > kernel (from > > 2.4.21) and experience a problem with the "new" ethernet driver for > > the ibm ppc4xx (version 2.0 from Benjamin Herrenschmidt). On our > > boards with only one active enet interface we have no problems. But > > our PPC405EP boards with 2 active enet devices, the traffic stops > > completely upon initializing the 2nd devices (emac_reset_configure). > > > > Has anybody experienced similar problems? Has anybody seen > this driver > > working properly with more than one ppc4xx enet devices (especially > > pp
405 TLB miss reduction
On 12/11/2003 06:45 PM Matt Porter wrote: > On Thu, Dec 11, 2003 at 10:06:32AM +0100, Wolfgang Grandegger wrote: >> >> On 12/10/2003 05:03 PM Matt Porter wrote: >> > David Gibson and Paul M. implemented large TLB kernel lowmem >> > support in 2.5/2.6 for 405. It allows for large TLB entries >> > to be loaded on kernel lowmem TLB misses. This is better than >> > the CONFIG_PIN_TLB since it works for all of your kernel lowmem >> > system memory rather than the fixed amount of memory that >> > CONFIG_PIN_TLB covers. >> >> Ah, I will have a look to 2.5/2.6. Is there a backport for 2.4? > > No. > >> > I've been thinking about enabling a variant of Andi Kleen's patch >> > to allow modules to be loaded into kernel lowmem space instead of >> > vmalloc space (to avoid the performance penalty of modular drivers). >> > This takes advantage of the large kernel lowmem 405 support above >> > and on 440 all kernel lowmem is in a pinned tlb for architectural >> > reasons. >> >> Is this patch available somewhere? It would be interesting to measure >> the improvement for our application. > > Google is your friend. > http://seclists.org/lists/linux-kernel/2002/Oct/6522.html > IIRC, there's a later version with some minor differences. > >> > I've also been thinking about dynamically using large TLB/PTE mappings >> > for ioremap on 405/440. >> >> OK, I expect not so much benefit from this measure but it depends on the >> application, of course. > > Yes, I've seen a lot of apps with huge shared memory areas across PCI > that can benefit from this...they used BATs on classic PPCs. > >> > In 2.6, there is hugetlb userspace infrastructure that could be enabled >> > for the large page sizes on 4xx. >> >> But this sounds more promising. Same questing as above. Is there a >> backport for 2.4? > > No. > >> > Allowing a compile time choice of default page size would also be useful. >> >> Increasing the page size from 4 to 8 kB should, in theory, halve the >> page misses (if no large TLB pages are used). Unfortunately, increasing >> the page size seem not straight forward as it's statically used in >> various places and maybe the GLIBC needs to be rebuild as well. > > Possibly, as Dan mentions, there are other arches already doing this > type of thing. I know ia64 does and sounds like MIPS is another. > >> > Basically, all of these cases can provide a performance advantage >> > depending on your embedded application...it all depends on what your >> > application is doing. >> >> Of course, and tweaking the kernel for a dedicated application might not >> been worth the effort. Anyhow, I have now a better idea what else can be >> done. > > When I used to do apps work we were very performance sensitive (depends > on you project, of course) and we were very willing to make kernel > tweaks (proprietary RTOS) to me our requirements. It all depends on > your requirements, constraints, budget, etc. :) Well, time and money is usually a scarce resource :-(. Anyhow, this thread showed me that it might be worth tweaking the kernel and that there are already various implementations which could be followed after a more detailed analysis of the TLB misses. Thank you and Dan very much for the valuable input. Wolfgang. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
PPC4xx enet driver problem (version 2.0)
Hi Stefan, I have suffered the same problem when I am trying swtich to 2.4.22 from 2.4.18 on IBM405ep board. Following is the output on my board: # ifconfig eth0 down # ifconfig eth1 down # ifconfig eth0 192.168.1.1 eth0: adjust to link, speed: 100, duplex: 1, opened: 1 eth0: Speed: 100, Full duplex. # ping 192.168.1.123 PING 192.168.1.123 (192.168.1.123): 56 data bytes 64 bytes from 192.168.1.123: icmp_seq=0 ttl=128 time=5.2 ms 64 bytes from 192.168.1.123: icmp_seq=1 ttl=128 time=2.8 ms 64 bytes from 192.168.1.123: icmp_seq=2 ttl=128 time=2.7 ms 64 bytes from 192.168.1.123: icmp_seq=3 ttl=128 time=2.6 ms 64 bytes from 192.168.1.123: icmp_seq=4 ttl=128 time=2.7 ms 64 bytes from 192.168.1.123: icmp_seq=5 ttl=128 time=2.7 ms --- 192.168.1.123 ping statistics --- 6 packets transmitted, 6 packets received, 0% packet loss round-trip min/avg/max = 2.6/3.1/5.2 ms # ifconfig eth1 192.168.2.1 eth1: adjust to link, speed: 100, duplex: 1, opened: 1 eth1: Speed: 100, Full duplex. SIOCSIFFLAGS: Device or resource busy # ifconfig eth0 Link encap:Ethernet HWaddr 00:04:AC:E3:15:5E inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:104 errors:0 dropped:0 overruns:0 frame:0 TX packets:7 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:10027 (9.7 kiB) TX bytes:630 (630.0 iB) Interrupt:15 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 iB) TX bytes:0 (0.0 iB) # ping 192.168.1.123 PING 192.168.1.123 (192.168.1.123): 56 data bytes --- 192.168.1.123 ping statistics --- 25 packets transmitted, 0 packets received, 100% packet loss # ifconfig -a eth0 Link encap:Ethernet HWaddr 00:04:AC:E3:15:5E inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:104 errors:0 dropped:0 overruns:0 frame:0 TX packets:15 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:10027 (9.7 kiB) TX bytes:966 (966.0 iB) Interrupt:15 eth1 Link encap:Ethernet HWaddr 00:00:00:00:00:00 inet addr:192.168.2.1 Bcast:192.168.2.255 Mask:255.255.255.0 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 iB) TX bytes:0 (0.0 iB) Interrupt:17 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:25 errors:0 dropped:0 overruns:0 frame:0 TX packets:25 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:2800 (2.7 kiB) TX bytes:2800 (2.7 kiB) # Have you already solved the problem? - Original Message - From: "Stefan Roese" <[EMAIL PROTECTED]> To: "Linuxppc-Embedded" ; ; Sent: Wednesday, December 03, 2003 7:29 PM Subject: PPC4xx enet driver problem (version 2.0) > > Hello! > > We are trying to switch to the 2.4.23 linuxppc_2_4_devel kernel (from > 2.4.21) and experience a problem with the "new" ethernet driver for the > ibm ppc4xx (version 2.0 from Benjamin Herrenschmidt). On our boards with > only one active enet interface we have no problems. But our PPC405EP > boards with 2 active enet devices, the traffic stops completely upon > initializing the 2nd devices (emac_reset_configure). > > Has anybody experienced similar problems? Has anybody seen this driver > working properly with more than one ppc4xx enet devices (especially > ppc405ep)? > > With the previous driver (from linuxppc_2_4_devel 2.4.21 maintained by > mvista) we had no problems with 2 enet interfaces on the ppc405ep so > far! > > By the way: What is the future of the ppc4xx enet driver. I found that > the 2.5 kernel has a newer mvista driver included (modifications for > 440gx, etc.). Is the driver from 2.4.23 a dead end? > > Thanks and best regards, > Stefan. > > > > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
PPC4xx enet driver problem (version 2.0)
On Fri, Dec 12, 2003 at 11:56:09AM +0100, Stefan Roese wrote: > > Davey! > > No, we didn't solve this problem so far. Eugene did some tests on an > ppc440 board and had no problems with the multiple enet devices. So it > seems to be 405ep related! I still have to send some debug output to > Eugene (hopefully today)! [I haven't followed the thread but new EMAC driver and 405EP rings a bell] It's possible that the new method in which OCP code handles OCP device dependencies has a bug. 405ep is a special case since it requires a particular EMAC device to provide MDIO operations for both EMACs. 440gp/gx don't follow this code path. -Matt ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
