cache control functions

cache control functions

[Eric Seppanen]

I'm writing a driver module, for a pci device that lives in a 405GPr
based system.  I notice that the 405 doesn't seem to have a consistent
cache after the pci device busmasters a bunch of data into SDRAM (or
before it pulls data out), so I think the thing I'm supposed to do is
call (depending on direction) one of these:
 invalidate_dcache_range
 clean_dcache_range
 flush_dcache_range
or what seems to be the equivalent, but cross-platform names
 dma_cache_inv
 dma_cache_wback
 dma_cache_wback_inv
 (these are just macros calling the first three; include/asm-ppc/io.h)

But invalidate_dcache_range and clean_dcache_range are never exported,
so they're unavailable to modules.  (and means that dma_cache_inv and
dma_cache_wback are unavailable as well.)

Is this intentional or an oversight?  I can't see how I can write a
driver for a busmaster device (that will work on a 405) without them.

Eric

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

Re: cache control functions

[Matt Porter]

On Wed, Mar 12, 2003 at 01:02:14PM -0600, Eric Seppanen wrote:
>
> I'm writing a driver module, for a pci device that lives in a 405GPr
> based system.  I notice that the 405 doesn't seem to have a consistent
> cache after the pci device busmasters a bunch of data into SDRAM (or
> before it pulls data out), so I think the thing I'm supposed to do is
> call (depending on direction) one of these:

<snip>

> Is this intentional or an oversight?  I can't see how I can write a
> driver for a busmaster device (that will work on a 405) without them.

Use the standard API described in Documentation/DMA-mapping.txt
You will find that there are PPC-specific (sort of, ARM has the same
names) versions of generic PCI DMA API defined in include/asm-ppc/io.h
Those can be used on on-chip or other non-PCI type device (stuff on
the EBC for 4xx).

Regards,
--
Matt Porter
porter@cox.net
This is Linux Country. On a quiet night, you can hear Windows reboot.

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

ramdisk source

[Prakash kanthi]

Folks,

I would like to get source code for creating some
basic libraries like ld, libc, libnsl, libutil to
create ramdisk and apps.

Which is the best place to get all these?

Thanks,
Prakash


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

Re: ramdisk source

[Wolfgang Denk]

In message <20030312211249.47531.qmail@web41202.mail.yahoo.com> you wrote:
>
> I would like to get source code for creating some
> basic libraries like ld, libc, libnsl, libutil to
> create ramdisk and apps.
>
> Which is the best place to get all these?

See for example the ELDK (http://www.denx.de/re/ELDK.html) or the
(slightly older) standalone version of the SELF
(ftp://ftp.denx.de/pub/LinuxPPC/usr/src/SELF/)


Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
As in certain cults it is possible to kill a process if you know  its
true name.                      -- Ken Thompson and Dennis M. Ritchie

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

Kenal Panic

[Kamaraj P]

Hi All,

I am getting this Kernel Panic message when I invoke ping flood from MPC8xx
.
How can I troubleshoot this message.

Oops: Kernel Mode Software FPU Emulation, sig: 8
NIP: C00292BC XER: C0001D7F LR: C00292BC SP: C3A07BC0 REGS: c3a07b10 TRAP:
1000
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK = c3a06000[114] 'ping' Last syscall: 102
last math 00000000 last altivec 00000000
GPR00: C00292BC C3A07BC0 C3A06000 0000001B 00001032 00000001 00000001
00000000
GPR08: 00000000 C0130000 0000001F C3A07B00 55F33F93 1001B8DC 00000000
100AE410
GPR16: 10010000 10010000 10010000 10010000 00001032 03A07D00 00000000
C012A1A0
GPR24: 00000120 C3A07D10 C012A1A0 00000007 00000007 C3A07C08 C012A1A0
C01790C0
Call backtrace:
C00292BC C00297A0 C5645BDC C564555C C5643524 C563E21C C0003904
C0003A30 C0002810 C00151D0 C0018B48 C0015028 C0014ED4 C0014C54
C000285C 10010000 7FFFFCE8 10001664 0FED9DBC 00000000
Kernel panic: Aiee, killing interrupt handler

In interrupt handler - not syncing
Rebooting in 180 seconds..


Can any one knows ??

Thanks in advance
Kamaraj.


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