USB driver for MPC850/823

The driver is developed under Malek's 2.2.5 for embedded PPC.
Since the documentation has been a bit poor for the USB host mode, much
had to be done with trial and error. Some of which is left in the
source.
Most changes are in new source files but some changes has been done in
commproc.c and .h to support RISC timers and more DPRAM (microcode
alert).
For some reason I couldn't use USB buffers in SDRAM, only DPRAM!?
As stated earlier on the list it's developed on an 850, but I haven't
found anything that says it won't work on an 823.

The USB-driver is a replacement for the UHCI or OHCI in the standard usb
stack.
It still needs to be URBified, so it's not up to date with the latest
developments
in the standard stack. It has been tested with the ACM driver (which is
included in the tar) and is running chat, ppp and mgetty. Also included
are the versions of usb.c usb-debug.c and usb.h used.

I did a tar (all changes are in arch/ppc/8xx_io) since I don't know how
useful a diff against 2.2.5 is when most are working on later versions.

Enjoy
  Bjorn

PS.
If You use chat, You'll find a bug in terminate(). Don't call fatal(),
it'll call terminate()....

PPS.
The mail was to big to be accepted to this list but you can find it
and the tar at

http://lists.suse.com/archives/linux-usb/2000-Mar/0234.html

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

At 10:35 AM 3/8/00 +0100, Björn Lundberg wrote:

The driver is developed under Malek's 2.2.5 for embedded PPC.
Since the documentation has been a bit poor for the USB host mode, much
had to be done with trial and error. Some of which is left in the
source.
Most changes are in new source files but some changes has been done in
commproc.c and .h to support RISC timers and more DPRAM (microcode
alert).
For some reason I couldn't use USB buffers in SDRAM, only DPRAM!?
As stated earlier on the list it's developed on an 850, but I haven't
found anything that says it won't work on an 823.

I have started looking at your code to try understand some of the
roadblocks that I have hit. I have ISOC in/out working on the 823 USB. My
IN and OUT packets are from main system Dram. You dont say what the problem
was, but if the problem is; the data sent was garbage, not what you
prepared, the problem may be memory mapping. The CPM wants to access
physical memory addresses. You use a macro __pa for this, but I dont think
that works for all cases of user and kernel memory. I grepped and found:

#define PAGE_OFFSET     0xc0000000
#define __pa(x)                 ((unsigned long)(x)-PAGE_OFFSET)

Look at virt_to_phys(x); but that only does kmalloc'ed memory. There seems
to be many mapping macros/routines but I don't know if one works for ANY
virtual address to its physical address.

Does anyone have a pointer to a document that thoroughly describes memory
mapping, both for the x86 and the ppc?



Steve Calfee	--	embedded systems consultant
calfee@home.com
cell phone: (510) 468-5837
Kerbango phone: (408) 517-3355
home office ph: (510) 657-6039


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Steve Calfee wrote:

.... The CPM wants to access
physical memory addresses. You use a macro __pa for this, but I dont think
that works for all cases of user and kernel memory.

It will certainly never work for user memory, you should only copyin/out
user addresses for a variety of reasons.

Look at virt_to_phys(x); but that only does kmalloc'ed memory.

The virt_to_phys() and __pa() do the same thing.  Both work on kmalloc'ed
memory.  Neither will work with vmalloc'ed memory.

When using the CPM on the 8xx, you have to be careful about the cache
attributes on the pages as the 8xx doesn't have bus snooping to ensure
coherency.  I use a couple of different methods to get memory allocated
in the kernel for the CPM, sometimes they are cached and require software
management, other times not cached.  Depends upon how it is used.

You can use kmalloc() or __get_free_pages() to allocate memory for the
CPM.  Just make sure kmalloc() gives you something that is properly
aligned, as some CPM functions have rather large alignment boundaries.
When allocated in this way, you have to chase down the pte's and modify
the cache attributes yourself if desired.

Does anyone have a pointer to a document that thoroughly describes memory
mapping, both for the x86 and the ppc?

It would probably be correct only until the next source update.  While
trying to keep up with the 2.3.xx source tree, I have changed the CPM
memory interfaces at least three times.  I think we are back where we
started, at least this week.



	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

The simple reason (makes me blush) why buffers in SDRAM didn't work was
beacuse I omitted to flush the cache. (Thanks Brad and Malek)

I did a quick change and an even quicker test.
Patch attached.

Cheers
 Bjorn

Dan Malek wrote:

snip

When using the CPM on the 8xx, you have to be careful about the cache
attributes on the pages as the 8xx doesn't have bus snooping to ensure
coherency.  I use a couple of different methods to get memory allocated
in the kernel for the CPM, sometimes they are cached and require software
management, other times not cached.  Depends upon how it is used.

Dan Malek wrote:

Just make sure kmalloc() gives you something that is properly
aligned, as some CPM functions have rather large alignment boundaries.
When allocated in this way, you have to chase down the pte's and modify
the cache attributes yourself if desired.

The most famous case of this is the IDMA buffer descriptors.  Unlike
everything elses buffer descriptors, the IDMA buffer descriptors must be
16 byte aligned, not 8.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Richard Hendricks wrote:

The most famous case of this is the IDMA buffer descriptors.

I don't know about those, but DSP and ATM have 32 and 64 byte alignment
for various structures.



	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Yep.  I don't do ATM, but the majority of IDMA related questions
can be traced to misalignment issues.  Come to think of it, I
can count the number of DSP function related questions one hand.

Dan Malek wrote:

Richard Hendricks wrote:

quoted

The most famous case of this is the IDMA buffer descriptors.

I don't know about those, but DSP and ATM have 32 and 64 byte alignment
for various structures.

        -- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/