Xilinx git tree at source.mvista.com
Hello, My Xilinx Virtex Development tree is now alive again. Please use the dev branch (master is just the ko copy): http://source.mvista.com/git/gitweb.cgi?p=linux-xilinx-26.git;a=shortlog;h=dev Currently it has a patch to enable the framebuffer on ML403 and ML300 plus TEMAC driver that uses the PHY lib (FIFO mode support only). The TEMAC driver is work in progress. In the queue are SGDMA TEMAC support, and SPI driver (master only). My concern is that the TEMAC driver uses the level 1 drivers from EDK 9.1. The comments / opinions on how to get this driver (not the current incomplete version of course) accepted into the ko tree are very welcomed. I am not quite satisfied with how the current git repository is structured, and may rework it completely later. Thanks, Andrei ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Xilinx git tree at source.mvista.com
Andrei Konovalov wrote: Hello, My Xilinx Virtex Development tree is now alive again. Please use the dev branch (master is just the ko copy): http://source.mvista.com/git/gitweb.cgi?p=linux-xilinx-26.git;a=shortlog;h=dev Currently it has a patch to enable the framebuffer on ML403 and ML300 plus TEMAC driver that uses the PHY lib (FIFO mode support only). The TEMAC driver is work in progress. In the queue are SGDMA TEMAC support, and SPI driver (master only). My concern is that the TEMAC driver uses the level 1 drivers from EDK 9.1. The comments / opinions on how to get this driver (not the current incomplete version of course) accepted into the ko tree are very welcomed. I have an almost working FIFO TEMAC driver. It is similarly based. it started out based on the Trek webserver sample I spent probably 3-4 days de-EDKing it into something that fit into a single source and was closer to ko norms. It is based on approximately the EDK 8.1 stuff. You are welcome to it, if it could be helpful in anyway. I am all for getting an acceptable driver into the ko tree. I am not quite satisfied with how the current git repository is structured, and may rework it completely later. Thanks, Andrei ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Xilinx git tree at source.mvista.com
Hi David, David H. Lynch Jr. wrote: Andrei Konovalov wrote: Hello, My Xilinx Virtex Development tree is now alive again. Please use the dev branch (master is just the ko copy): http://source.mvista.com/git/gitweb.cgi?p=linux-xilinx-26.git;a=shortlog;h=dev Currently it has a patch to enable the framebuffer on ML403 and ML300 plus TEMAC driver that uses the PHY lib (FIFO mode support only). The TEMAC driver is work in progress. In the queue are SGDMA TEMAC support, and SPI driver (master only). My concern is that the TEMAC driver uses the level 1 drivers from EDK 9.1. The comments / opinions on how to get this driver (not the current incomplete version of course) accepted into the ko tree are very welcomed. I have an almost working FIFO TEMAC driver. It is similarly based. it started out based on the Trek webserver sample Is this a reference design by Xilinx? Linux based or standalone? I spent probably 3-4 days de-EDKing it into something that fit into a single source and was closer to ko norms. It is based on approximately the EDK 8.1 stuff. You are welcome to it, if it could be helpful in anyway. I am all for getting an acceptable driver into the ko tree. You could post your driver to the list when you think it is in good enough shape. If your driver is based on the linux TEMAC driver from EDK, it shouldn't be very different from my version (my added value is mostly replacing the custom PHY code with the PHY lib stuff). Then we could merge our drivers (or whatever would make sense). I would be interested to have a look at your current code just to see how much has it cost to de-EDK the FIFO part. You could email me your (even not quite working) driver privately if you want. Thanks, Andrei ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Xilinx git tree at source.mvista.com
Hi Andrei, David, It's great to hear that Andrei's git tree is active again. As you might have heard, Xilinx is in the process of setting up a git tree as well. Right now we are waiting for the new hosting machines to be installed. We should get those machines up and running shortly (within a couple weeks). Currently the tree is based on mainline and adds support for MicroBlaze. I also intent to merge Grant Likely's virtex-dev branch, the framebuffer patch and the various other contributions that are out there. We are also in the process of changing our internal coding guidelines to match the common Linux style (e.g. u32, u16 types, 8 char wide (tab) indentation, curly brace location etc) to make it easier to integrate code into the kernel and push it upstream. I'll send an update once we have the server up and running. Thanks, Wolfgang Andrei Konovalov wrote: Hi David, David H. Lynch Jr. wrote: Andrei Konovalov wrote: Hello, My Xilinx Virtex Development tree is now alive again. Please use the dev branch (master is just the ko copy): http://source.mvista.com/git/gitweb.cgi?p=linux-xilinx-26.git;a=shortlog;h=dev Currently it has a patch to enable the framebuffer on ML403 and ML300 plus TEMAC driver that uses the PHY lib (FIFO mode support only). The TEMAC driver is work in progress. In the queue are SGDMA TEMAC support, and SPI driver (master only). My concern is that the TEMAC driver uses the level 1 drivers from EDK 9.1. The comments / opinions on how to get this driver (not the current incomplete version of course) accepted into the ko tree are very welcomed. I have an almost working FIFO TEMAC driver. It is similarly based. it started out based on the Trek webserver sample Is this a reference design by Xilinx? Linux based or standalone? I spent probably 3-4 days de-EDKing it into something that fit into a single source and was closer to ko norms. It is based on approximately the EDK 8.1 stuff. You are welcome to it, if it could be helpful in anyway. I am all for getting an acceptable driver into the ko tree. You could post your driver to the list when you think it is in good enough shape. If your driver is based on the linux TEMAC driver from EDK, it shouldn't be very different from my version (my added value is mostly replacing the custom PHY code with the PHY lib stuff). Then we could merge our drivers (or whatever would make sense). I would be interested to have a look at your current code just to see how much has it cost to de-EDK the FIFO part. You could email me your (even not quite working) driver privately if you want. Thanks, Andrei ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH] mpc52xx: Correct calculation of FEC RX errors.
'ifconfig eth0' command for mpc5200B-based cards shows error for RX. However none of RX MIB counters is set to value greater than zero. Number of errors is equal to number of multicast packet. In linux 2.4 calculation of RX errors is slightly different and takes into account number of multicast packet. This change is a port of calculation method of RX errors for FEC controller from linux 2.4 to 2.6. Signed-off-by: Grzegorz Bernacki [EMAIL PROTECTED] --- drivers/net/fec_mpc52xx/fec.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/net/fec_mpc52xx/fec.c b/drivers/net/fec_mpc52xx/fec.c index f0ce87e..d2087f6 100644 --- a/drivers/net/fec_mpc52xx/fec.c +++ b/drivers/net/fec_mpc52xx/fec.c @@ -395,7 +395,9 @@ static struct net_device_stats *fec_get_stats(struct net_device *dev) stats-rx_bytes = in_be32(fec-rmon_r_octets); stats-rx_packets = in_be32(fec-rmon_r_packets); - stats-rx_errors = stats-rx_packets - in_be32(fec-ieee_r_frame_ok); + stats-rx_errors = stats-rx_packets - ( + in_be32(fec-ieee_r_frame_ok) + + in_be32(fec-rmon_r_mc_pkt)); stats-tx_bytes = in_be32(fec-rmon_t_octets); stats-tx_packets = in_be32(fec-rmon_t_packets); stats-tx_errors = stats-tx_packets - ( ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Latest GCC/GLIBC working combo for a Linux 2.4.x kernel?
Hi! We are using a RHEL/386 machine to cross-compile for Debian/PowerPC (8260) target, a few year old embedded system that we inherited. The kernel is 2.4.9. Using crosstools, and following Dan Kegel's notes, the combo we have is gcc-2.95-3/glibc-2.2.5. Does anybody have any working version using newer versions of the 2.4 kernel and newer GCC versions for a powerpc-603e target? One motivation is to use BusyBox-1.5.1, but I am told on that list that GCC 2/x is too old (I tried before I asked, it doesn't compile). Any help, pointers, example config files for crosstools, etc. would be really appreciated! Thanks in advance, Shash ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Xilinx git tree at source.mvista.com
Andrei Konovalov wrote: Hi David, David H. Lynch Jr. wrote: I have an almost working FIFO TEMAC driver. It is similarly based. it started out based on the Trek webserver sample Is this a reference design by Xilinx? Linux based or standalone? I did a Local Link hard TEMAC driver - that I eventually got working. However, I could not find anyway to enable interrupts in the Local Link TEMAC so the driver was strictly polled and between that and other issues, perfomances was abysmal almost 50% of all inbound packets were dropped, we switched to the PLB FIFO TEMAC I stripped out all the SG and DMA stuff (as it is not in our hardware) and converted it to a fairly normal Linux ethernet driver. It sends, it receives, but I beleive it is not properly confirming to Linux that packets were successfully sent. In the interim I have been using the posted driver that uses the EDK. Until more recently that has lacked features like autonegotiation. I beleive its current flaw is primarily massive violations of kernel code style guidelines. I spent probably 3-4 days de-EDKing it into something that fit into a single source and was closer to ko norms. It is based on approximately the EDK 8.1 stuff. You are welcome to it, if it could be helpful in anyway. I am all for getting an acceptable driver into the ko tree. You could post your driver to the list when you think it is in good enough shape. If your driver is based on the linux TEMAC driver from EDK, it shouldn't be very different from my version (my added value is mostly replacing the custom PHY code with the PHY lib stuff). Then we could merge our drivers (or whatever would make sense). I would be interested to have a look at your current code just to see how much has it cost to de-EDK the FIFO part. You could email me your (even not quite working) driver privately if you want. I will email you a copy separately. I do not care what you choose to do with it. At the moment I have no time to take it further - something about asses, alligators and clearing swamps. Mostly I would just like to see a Linux friendly driver make its way into the kernel. I have almost exactly the same code working as a GHS integrity driver. In fact I sort of ported a mini shim layer to GHS to implement Linux SKB's under GHS. I did trip over something with GHS. If I was able to 64bit align the data part of the skb the send/receive code code be vastly simplified. I have not but I have not done that yet. Thanks, Andrei -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Xilinx git tree at source.mvista.com
Wolfgang Reissnegger wrote: Hi Andrei, David, It's great to hear that Andrei's git tree is active again. As you might have heard, Xilinx is in the process of setting up a git tree as well. Right now we are waiting for the new hosting machines to be installed. We should get those machines up and running shortly (within a couple weeks). Absolutely fantastic - however I think kernel.org would be happy to host your git tree for you as well as a few other places. Those are locations people would look for public git trees. I beleive you can still excecise some control. I beleive they are free - though I suspect kernel.org would not mind contributions from xilinx. Currently the tree is based on mainline and adds support for MicroBlaze. I also intent to merge Grant Likely's virtex-dev branch, the framebuffer patch and the various other contributions that are out there. You might want to look at the Microbalze-uClinux mailing list as well as petalogix. They are not using git yet, but they are puching the microblaze towards kernel org inclusion. We are also in the process of changing our internal coding guidelines to match the common Linux style (e.g. u32, u16 types, 8 char wide (tab) indentation, curly brace location etc) to make it easier to integrate code into the kernel and push it upstream. For me the most significant issue is the bazillion layers of nested macro's and includes. The kernel style guides atleast to me are primarily about the readability and understandability of the code. not where the curly brackets are. I'll send an update once we have the server up and running. Thanks, Wolfgang -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
MPC8560 Gianfar driver hangs after soft reboot
Hi, The Gianfar driver is hanging during boot-up after a soft reboot. It works fine when the board is power cycled. Any hints on where to look further on this issue? Here are the details (cut and pasted from my colleague's email): 1. Load the kernel from the Flash and the rootfs from a NFS server. 2. Issue the reboot command. This runs the Busybox reboot producing the following output: The system is going down NOW! Sending SIGTERM to all processes Sending SIGKILL to all processes Requesting system reboot 3. After rebooting, the system starts up Linux and it hangs after: eth0: Gianfar Ethernet Controller Version 1.2, 00:40:42:01:00:00 eth0: Running with NAPI enabled eth0: 256/256 RX/TX BD ring size When stepped through, the kernel endlessly loops in the function: gfar_probe(struct platform_device *pdev) File: gianfar.c Line 233: while (!(gfar_read(priv-regs-ievent) (IEVENT_GRSC | IEVENT_GTSC))) cpu_relax(); The soft reset procedure in the MPC8560RM.pdf was followed by separating out the GTS and GRS completion polling with a delay between these. The kernel seems to get stuck at waiting for the GTS to complete. Tried not doing this Graceful stop procedure by commenting out the relevant driver code. In this case the Kernel seems to continue on and gets stuck at mounting the rootfs from NFS, indicating that the network cannot be accessed. Also tried soft rebooting without the network cable and the kernel boots without hanging, but the network does not work when the re-connected. The PHY seems to be working because when we plug the cable back in it detects the link and writes this console message: [ 1557.465085] PHY: 0:01 - Link is Up - 100/Full Note that there are two Ethernet controllers on the board (eth0 and eth1). Only eth1 is connected to the network. Background info: Kernel version 2.6.20.4 PPC Uboot version 1.2.0 Busybox version 1.5.0 ELDK: 4.1 JTAG: BDI-2000 Board : Microsys PM856 - with MPC8560 processor. Bill -- Bill Farrow Phone : +61 3 9538-3386 http://www.optiscan.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Xilinx git tree at source.mvista.com
David H. Lynch Jr. wrote: Wolfgang Reissnegger wrote: Hi Andrei, David, It's great to hear that Andrei's git tree is active again. As you might have heard, Xilinx is in the process of setting up a git tree as well. Right now we are waiting for the new hosting machines to be installed. We should get those machines up and running shortly (within a couple weeks). Absolutely fantastic - however I think kernel.org would be happy to host your git tree for you as well as a few other places. Those are locations people would look for public git trees. I beleive you can still excecise some control. I beleive they are free - though I suspect kernel.org would not mind contributions from xilinx. I agree, and I already requested kernel.org site hosting a while back, but I did not get a response yet. [snip] For me the most significant issue is the bazillion layers of nested macro's and includes. I don't see the macros as an issue, just look at the implementation of, for example, spin_lock_irq() and Xilinx's macros seem like child's play :-) As for includes, yes, there are a few too many header files. But, as time progresses and the need arises they can be merged into fewer files. The kernel style guides atleast to me are primarily about the readability and understandability of the code. not where the curly brackets are. I'll send an update once we have the server up and running. Thanks, Wolfgang ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH] NET: add MAINTAINERS entry for ucc_geth driver
Signed-off-by: Li Yang [EMAIL PROTECTED] --- MAINTAINERS |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 4c3277c..3faed72 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1463,6 +1463,13 @@ L: [EMAIL PROTECTED] L: linuxppc-embedded@ozlabs.org S: Maintained +FREESCALE QUICC ENGINE UCC ETHERNET DRIVER +P: Li Yang +M: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] +L: linuxppc-embedded@ozlabs.org +S: Maintained + FILE LOCKING (flock() and fcntl()/lockf()) P: Matthew Wilcox M: [EMAIL PROTECTED] ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
