QMC driver for 860?
Joakim Tjernlund wrote: Hi all Does anyone know of a QMC driver for the PPC860? It does not have to be perfect, I will take anything since I have not been in this area before. Thanks Jocke I have something that works for the MPC850. Unfortunately it is kinda complex and too much tied to my custom hardware to be of any use directly. I.e. be prepared to hack it a bit. Email me if you are interested... Pantelis Antoniou INTRACOM S.A. Greece ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
QMC driver for 860?
Hi all Does anyone know of a QMC driver for the PPC860? It does not have to be perfect, I will take anything since I have not been in this area before. Thanks Jocke I have something that works for the MPC850. Unfortunately it is kinda complex and too much tied to my custom hardware to be of any use directly. I.e. be prepared to hack it a bit. Email me if you are interested... Pantelis Antoniou INTRACOM S.A. Greece Yes, please sent it. I am interested in any driver I can get my hands on. Even if it's not directly usable, I can always learn from it. Anybody else that have a QMC driver, please don't hesitate to send me a copy. Thanks Jocke ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Frozen ! any idea ?
Do you have the watch dog timer enabled? This could be the problem. -Original Message- From: Stefano Bodini [mailto:[EMAIL PROTECTED] Sent: Monday, November 25, 2002 2:45 PM To: linuxppc-embedded at lists.linuxppc.org Subject: Frozen ! any idea ? Hi all ! I have (for me) a curious problem. I have an Embedded Planet RXP Classic credit card (ppc860) loaded with a 2.4.17 kernel (compiled with MontaVista Pro 2.1). I'm able to load correctly the kernel and the filesystem .. all is working just fine, but after 1 minute since the last command issued, the system just freeze. 1 minute without any command issued and the system is gone .. no errors, no messages, no logs, nothing. Just doesn't accept anymore commands .. even the echo on the tty port is gone. About the 1 minute value, I did some tests to figure out the timing and is more or less 1 minute. Up to 30-45 secs. and the system still react, after (50-70 secs) the system freeze. If you continue to issue commands the system doesn't freeze .. but it do it as long as you stop to issue commands. I tried to load also the default kernel image for that board .. same result. It seems a kind of watch dog or timer .. but I don't understand why all is frozen ! Any idea ? Thanks in advance C'ya Steve ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Frozen ! any idea ?
At 09:00 AM 12/02/2002 -0500, Steven Blakeslee wrote: Do you have the watch dog timer enabled? This could be the problem. On the kernel or on the board ? On the board is disabled and on the kernel I didn't find any option about the watchdog. Thanks Steve ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
QMC driver for 860?
OK You asked for it ;). The file netvia_tsa.c is the actual QMC + stuff driver. The file netvia_bri.c is an example driver. The header files are the QMC definitions. Linux kernel version is 2.4.20. Don't hesitate to ask for any explanations. Pantelis Thanks a lot! I have just browsed the driver and I noticed that there is room for performance improvements in netvia_tsa.c w.r.t memcpy(). You can avoid the memcpy() call for received packets by using invalidate_dcache_range(). I did this for the 8xx_io/enet.c driver a few weeks ago(it's not in BK yet). See http://lists.linuxppc.org/linuxppc-embedded/200210/msg00317.html and http://lists.linuxppc.org/linuxppc-embedded/200210/msg00272.html Jocke ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
QMC driver for 860?
Joakim Tjernlund wrote: OK You asked for it ;). The file netvia_tsa.c is the actual QMC + stuff driver. The file netvia_bri.c is an example driver. The header files are the QMC definitions. Linux kernel version is 2.4.20. Don't hesitate to ask for any explanations. Pantelis Thanks a lot! I have just browsed the driver and I noticed that there is room for performance improvements in netvia_tsa.c w.r.t memcpy(). You can avoid the memcpy() call for received packets by using invalidate_dcache_range(). I did this for the 8xx_io/enet.c driver a few weeks ago(it's not in BK yet). See http://lists.linuxppc.org/linuxppc-embedded/200210/msg00317.html and http://lists.linuxppc.org/linuxppc-embedded/200210/msg00272.html Jocke Yes, I know the trick. I'm looking forward to see your changes make it in. As it stands I'm not tracking the BK PPC tree, but the Linus tree. Being behind the company firewall, BK is not very useful. In this driver case since I'm reading the packet in a non-cachable area, and not directly in a skb, I'm not convinced that the invalidate_dcache_range will be a great win. If you do any performance testing I'm very interested in your results. Pantelis P.S. Is there anyone in the list interested in this? Should I clean it up, and submit it? ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Device Accessing Problem in 440GP
Hi All, I am working on IBM 440GP based proprietry board using MVL 2.1 linux. I have a device siiting on the EBC at 0x10010 and I want to access it from the user space. I use mmap call of my driver to do that. I have not initialized the device. I have set the access parameters and controller registers of EBC appropriately to access the device. But when I make ioremap() call using, ioremap64(0x10010, 0x2000), the function returns a valid pointer. But when I do a sample write and read, I am not getting correct values. While I was debigging, I couldn't find the TLB entry for the real address. When I try to access the returned mmap() pointer, kernel says , do_wp_page: bogus page at address (page ) VM: killing process xxx Does anyone know what could be the reason? 1. Do I have to initialize the device in setup_arch function ? 2. Do I have to explicitly create a TLB entry for the device ? Hoping to get a response. I am stuck in the middle. Thanks and regards, Vishwa ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
QMC driver (list limit breached).
I'm sorry for the confusion but the size limits of the list did not allow the attatchment to go through. I will resend tomorrow, split in smaller patches. Sorry for the inconvinience... Pantelis ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
QMC driver (list limit breached).
In message 3DEB7F17.1020209 at intracom.gr you wrote: I'm sorry for the confusion but the size limits of the list did not allow the attatchment to go through. I will resend tomorrow, split in smaller patches. Sorry for the inconvinience... You might put it on a FTP server, and just post the URL. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de There is a time in the tides of men, Which, taken at its flood, leads on to success. On the other hand, don't count on it. - T. K. Lawson ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
QMC driver for 860?
Joakim Tjernlund wrote: OK You asked for it ;). The file netvia_tsa.c is the actual QMC + stuff driver. The file netvia_bri.c is an example driver. The header files are the QMC definitions. Linux kernel version is 2.4.20. Don't hesitate to ask for any explanations. Pantelis Thanks a lot! I have just browsed the driver and I noticed that there is room for performance improvements in netvia_tsa.c w.r.t memcpy(). You can avoid the memcpy() call for received packets by using invalidate_dcache_range(). I did this for the 8xx_io/enet.c driver a few weeks ago(it's not in BK yet). See http://lists.linuxppc.org/linuxppc-embedded/200210/msg00317.html and http://lists.linuxppc.org/linuxppc-embedded/200210/msg00272.html Jocke Yes, I know the trick. I'm looking forward to see your changes make it in. As it stands I'm not tracking the BK PPC tree, but the Linus tree. Being behind the company firewall, BK is not very useful. The patch should apply to linus tree as well. There is just a small bug in my second version(the invalidate_dcache_range() call must be moved). In this driver case since I'm reading the packet in a non-cachable area, and not directly in a skb, I'm not convinced that the invalidate_dcache_range will be a great win. It should be a win since the patch removes the need for non-cachable memory and a memcpy()(only add a invalidate_dcache_range call for non cache coherent CPUs like the 8xx). Jocke If you do any performance testing I'm very interested in your results. Pantelis P.S. Is there anyone in the list interested in this? Should I clean it up, and submit it? Is QMC supported on other families than 8xx? If so I think it would be a good idea. The 862 even has the QMC built in so there must be a need for this. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
can newlib be a shared library on ppc platform?
Liu Fred-a18596 wrote: Hi, I need a small libc in our embedded system, so I compiled newlib. But it seems that newlib only support static library on ppc platform. Is it true? I believe newlib is barely a C library, (it was the last time I looked at it) I would suggest you investigate uclibc and see if that will do what you need. (There is a version of uclibc that will do shared libs, but I do not know how advanced the dynamic loader is on PPC.) --Mark ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
QMC driver for 860?
Hi all Does anyone know of a QMC driver for the PPC860? It does not have to be perfect, I will take anything since I have not been in this area before. Thanks Jocke ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
