USB working on 823..?
Well, the host mode is somewhat workable, BUT it is my understanding that you have to write software for specific devices. That is to say, you will need to have an "approved slave list", and write code to talk to each slave specifically. Please let me know if I am incorrect, as we are about to finish a board layout with extra USB host chips just to do host. If we could get it working reliably and so any USB device can be attached with the generic USB drivers, it would be a Good Thing(tm) and very much appreciated! Thanks for the info & correction! I reserve the right to be wrong. -Jason -Original Message- From: Dan Malek [mailto:[EMAIL PROTECTED] Sent: Thursday, May 16, 2002 12:34 PM To: Hihn Jason Cc: 'navinb'; linuxppc-embedded at lists.linuxppc.org Subject: Re: USB working on 823..? Hihn Jason wrote: > Well, at least with the 832e, you can't. With the 823e, you _can_ :-) > The 823e was made for Kodak in the dawn of USB, You are getting your 823 and 823e mixed up. The original 823 was produced as you said, and to only support a slave USB interface. In limited cases, the 823 could support a host interface, but it was tricky with lots of software timing issues to solve. The 823e, and newer 850 (Rev. B) processors have some modifications to better allow USB host support. These require some external support (looping a clock back to the I/O pin) and the downloading of a microcode patch for properly generating SOF timing. The 823e has other nice features, like bigger caches and more control over the LCD DMA. -- Dan ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
USB working on 823..?
Well, at least with the 832e, you can't. The 823e was made for Kodak in the dawn of USB, before there was the standard that we have today. As a result, there is a bug in the host mode of the chip. Slave works fine though. You'll need another chip to do USB host. I reserve the right to be wrong. -Jason -Original Message- From: navinb [mailto:[EMAIL PROTECTED] Sent: Thursday, May 16, 2002 9:56 AM To: linuxppc-embedded at lists.linuxppc.org Subject: USB working on 823..? Hello , Has anybody got usb working successfully on mpc823. I am trying hard to get the usb host controller properly working on 823.. are there any know issue or patches available..? Best Regards, ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
USB working on 823..?
An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20020516/c983b696/attachment.txt
USB working on 823..?
Hihn Jason wrote: > Well, at least with the 832e, you can't. With the 823e, you _can_ :-) > The 823e was made for Kodak in the dawn of USB, You are getting your 823 and 823e mixed up. The original 823 was produced as you said, and to only support a slave USB interface. In limited cases, the 823 could support a host interface, but it was tricky with lots of software timing issues to solve. The 823e, and newer 850 (Rev. B) processors have some modifications to better allow USB host support. These require some external support (looping a clock back to the I/O pin) and the downloading of a microcode patch for properly generating SOF timing. The 823e has other nice features, like bigger caches and more control over the LCD DMA. -- Dan ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] Several patches agains linuxppc_devel-2.4.19-pre8
Tom Rini schrieb: > On Wed, May 15, 2002 at 01:35:55PM +0200, "David M?ller (ELSOFT AG)" wrote: > > >>The attached patch fixes the following issues: > > > Looks good, except: > Don't #ifdef externs, if they aren't used it's OK. > Since this code only has to work in recent'ish kernels (in reality only > 'current' kernels) don't bother with the > #ifdef MODULE_LICENSE > ... > #endif > > Just use it. > I have copied the MODULE_LICENSE stuff from another driver. Does anybody knows if this feature is tagged to be a remove candiate in future kernels and/or in the modutils? Another question: I've noticed that (at least) the following files have their executable bit set, although they are simple C source files. ./include/asm-ppc/ppc405_dma.h ./arch/ppc/kernel/ppc405_dma.c ./arch/ppc/kernel/ppc405_pci.c ./arch/ppc/kernel/ppc4xx_setup.c ./arch/ppc/platforms/walnut.c ./arch/ppc/platforms/cpc700_pic.c On the other hand, the PPCBoot kernel packer script in ./arch/ppc/boot/utils/mkimage.wrapper have the exec bit cleared. Is it a bit task to fix this? Dave ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
network issues with fec on 860
Hello, I have linux booting a ramdisk file system on an 860 processor. I am using the fec for ethernet. I send these bootargs to the linux kernel. root=/dev/ram ip=off I start up the network using ifconfig and everything works just fine. Now, if I bring the eth0 down using ifconfig and try bringing it up again, everything looks right. I see the eth0 interface up and running. But, my network is not really working. I cant ping or do anything else. In summary, my ethernet connection works only the first time. I cant take it down and bring it back up. Any suggestions? Thank you, Navin. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] Several patches agains linuxppc_devel-2.4.19-pre8
On Thu, May 16, 2002 at 11:26:33AM +0200, "David M?ller (ELSOFT AG)" wrote: > Tom Rini schrieb: > >On Wed, May 15, 2002 at 01:35:55PM +0200, "David M?ller (ELSOFT AG)" wrote: > > > > > >>The attached patch fixes the following issues: > > > > > >Looks good, except: > >Don't #ifdef externs, if they aren't used it's OK. > >Since this code only has to work in recent'ish kernels (in reality only > >'current' kernels) don't bother with the > >#ifdef MODULE_LICENSE > >... > >#endif > > > >Just use it. > > > > I have copied the MODULE_LICENSE stuff from another driver. > Does anybody knows if this feature is tagged to be a remove candidate in > future kernels and/or in the modutils? Unfortunately, no. I think other drivers do it for backwards compatibility, which we don't have to worry about. > Another question: > > I've noticed that (at least) the following files have their executable > bit set, although they are simple C source files. > ./include/asm-ppc/ppc405_dma.h > ./arch/ppc/kernel/ppc405_dma.c > ./arch/ppc/kernel/ppc405_pci.c > ./arch/ppc/kernel/ppc4xx_setup.c > ./arch/ppc/platforms/walnut.c > ./arch/ppc/platforms/cpc700_pic.c > > On the other hand, the PPCBoot kernel packer script in > ./arch/ppc/boot/utils/mkimage.wrapper have the exec bit cleared. > > Is it a bit task to fix this? I assume you ment big. And no, I've just fixed these. Thanks. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
