* Re: [PATCH] ppc32: handle Book E debug exceptions on kernel stack
From: Dale Farnsworth @ 2006-02-14 22:36 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <Pine.LNX.4.44.0602141556200.2609-100000@gate.crashing.org>
On Tue, Feb 14, 2006 at 03:57:58PM -0600, Kumar Gala wrote:
> Let me look at this a little, however, I'm amused by the
Thanks.
> smp_processor_id() usage on 8548. Its a single core SoC, so any reason
> SMP is turned on in your kernel?
I haven't turned on SMP in my 8548 kernel.
The kgdb singlestep code calls smp_processor_id() even on UP.
It doesn't really need to call it on UP, but smp_processor_id()
still should work. I would have preferred seeing #ifdef
CONFIG_SMP scattered throughout that code, but it's not my code.
Anyway, the smp_processor_id() calls happen to return the
correct value on UP, even on the critical exception stack,
since that stack area is initialized to 0.
The issue I actually hit is that for CONFIG_PREEMPT, the calls
to spin_lock() and spin_unlock() increment and decrement
current_thread_info()->preempt_count. This breaks things
when the preempt_count goes negative.
> Not, that your patch, isn't needed for a SMP Book-E, just wondering.
Yes, I'm looking forward to trying out a dual-core processor.
-Dale
> On Tue, 14 Feb 2006, Dale Farnsworth wrote:
>
> > From: Dale Farnsworth <dale@farnsworth.org>
> >
> > On PPC Book E processsors, we currently handle debug
> > exceptions on the critical exception stack (debug stack
> > for E200). This causes problems with the kgdb single
> > step handler, which calls smp_processor_id() and spin_lock(),
> > which reference current_thread_info(), which only works when
> > we are on the kernel stack.
> >
> > We address this by switching to the kernel stack early while
> > handling debug exceptions. Note that the entry values of r10
> > and r11 are still saved on the critical exception (or debug) stack.
> >
> > Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
^ permalink raw reply
* RE: 440gx GPIO
From: Howard, Marc @ 2006-02-15 0:01 UTC (permalink / raw)
To: Ed Goforth, linuxppc-embedded
> -----Original Message-----
> From:=20
> linuxppc-embedded-bounces+marc.howard=3Dkla-tencor.com@ozlabs.or
> g=20
> [mailto:linuxppc-embedded-bounces+marc.howard=3Dkla-tencor.com@o
> zlabs.org] On Behalf Of Ed Goforth
> Sent: Tuesday, February 14, 2006 1:47 PM
> To: linuxppc-embedded@ozlabs.org
> Subject: Re: 440gx GPIO
> .....=20
> Well, I was able to manipulate GPIO9, GPIO10 and GPIO12. It's time to
> turn it over to the hardware people.
>=20
It's AMCC's fault. They aren't listing the latest errata on their
website. I downloaded their rev 3.1 ver 1.03 errata last August.
However if you look today you get the rev 3.1 ver 1.02 release.
In the 1.03 errata there is the following bug listed:
*************
GPIO_1:SDR0_PFC[G11E] has no effect.
Category: 6
Overview:
The SDR0_PFC[G11E] bit does not control GPIO11, thus meaning that GPIO11
is always active (unless EMAC group 4 is selected and both GPHYs are in
modes 0 or 1).
=20
Impact:No impact.
Workaround:
None.
**************
Thus the PFC bit doesn't do anything. If you're using group 4 "modes 0
or 1" (which mode field are they talking about here?) you're screwed,
you can't use GPIO11.
Curious how they think this has "No impact". If you're running RGMII
you don't need that pin and it should be available for GPIO11 but
apparently it isn't.
Marc
^ permalink raw reply
* Gigabit ethernet support of ppc440gx in 2.6 and 2.4
From: 廖荣生 @ 2006-02-15 6:08 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
We want to get a data rate of 600Mbits/s over gigabit ethernet of ppc440gx.
How about the status of support to ppc440gx GigE in Linux kernel?
Which kernel version should we select? 2.6 or 2.4?
Thanks a lot!
Lonsn
^ permalink raw reply
* mpc8260sar linux-2.6 and PQ2FADS support
From: Alex Zeffertt @ 2006-02-15 12:38 UTC (permalink / raw)
To: linuxppc-embedded, linux-atm-general@lists.sourceforge.net
Hi all,
This email is just to announce that I've added linux-2.6 and PQ2FADS
support to the ATM driver on http://mpc8260sar.sourceforge.net/ .
This new support was submitted by Fabien Clement, to whom I am very
grateful.
I have not tested linux-2.6 or the PQ2FADS myself, but the code
looks good and is still working on linux-2.4 and the other platforms
supported by the driver(PM828 and MPC8272ADS).
Alex
^ permalink raw reply
* 8272ads:PCI prefetchable mem access problem
From: Anil Dhonde @ 2006-02-15 14:58 UTC (permalink / raw)
To: linuxppc-embedded
Hi all:
We have plugged an ATI Radeon video card into a PCI
slot on our powerpc 8272ads evaluation board. The
linux kernel (v2.6.15) comes up, detects the card on
the bus, rolls in the ATI Radeon framebuffer driver as
it should. All register/PCI config space access is
fine.
The trouble starts when I try to access the 128MByte
video memory on the card. As you can see below, there
are three regions for this card - one pre-fetchable,
one non-prefetchable and one io. The 128MByte region
is flagged prefetchable.
I can:
- mmap (in userland) or ioremap (in kernel space) the
non-prefetchable region and do what I want to with it
(read/write). User space I use either /proc or /sys
handles and in the kernel my driver does the remapping
I cannot:
- mmap or remap the prefetchable region though the
calls to ioremap and mmap return success.
- Kernel ioremap returns success but the powerpc
crashes as soon as I read or write to space that has
just been remapped.
- mmap using either /proc or /sys based pci resource
access from user space fails the same way. mmap call
returns success but access cases a bus error.
something that looks suspicious:
cat /proc/iomem below shows that the ATI cards
prefetchable memory does not land up in the
prefetchable region of the PCI map. It lands in the
PCI memory (non-prefetchable region).
what I have tried:
- forcing PREFETCH flags to be NONPREFETCH by hacking
the kernel - this hack didnt work though /proc/pci
reports all pre-fetchables as non-prefetchables
meaning that flags were set properly.
- changing the PCI map to make all memory fall under
PCI prefetchable. Hence /proc/iomem now shows all
memory under the prefetch region. Even then accesses
fail. I have tried vice-versa i.e. make all memory
fall under non-prefetchable and that didnt make a
difference as well
- enable prefetch flag in POCMR1 to make the cpu think
it is prefetchable. this doesn't make a difference.
any help/pointers from you guys will be great,
thanks a ton,
a
Platform details:
- powerpc 8272ads board, 64MByte eval board with
kernel 2.6.15
- ATI Radeon 7000 PCI based card with 128MByte mem
================== log ==============================
~ # cat /proc/pci
PCI devices found:
Bus 0, device 0, function 0:
Class 0600: PCI device 1057:18c1 (rev 16).
Master Capable. Latency=248.
Non-prefetchable 32 bit memory at 0x0 [0x1ffff].
Prefetchable 32 bit memory at 0x0 [0xfffffff].
Bus 0, device 24, function 0:
Class 0300: PCI device 1002:5159 (rev 0).
IRQ 66.
Master Capable. Latency=128. Min Gnt=8.
Prefetchable 32 bit memory at 0xa8000000
[0xafffffff].
I/O at 0x1ffff00 [0x1ffffff].
Non-prefetchable 32 bit memory at 0xa7ff0000
[0xa7ffffff].
~ # ls -l /sys/devices/pci0000\:00/0000\:00\:18.0/
lrwxrwxrwx 1 root root 0 Jan 1
00:03 bus ->
../../../bus/pci
-r--r--r-- 1 root root 4096 Jan 1
00:03 class
-rw-r--r-- 1 root root 256 Jan 1
00:03 config
-r--r--r-- 1 root root 4096 Jan 1
00:03 device
-r--r--r-- 1 root root 4096 Jan 1
00:03 irq
-r--r--r-- 1 root root 4096 Jan 1
00:03 local_cpus
-r--r--r-- 1 root root 4096 Jan 1
00:03 modalias
-r--r--r-- 1 root root 4096 Jan 1
00:03 resource
-rw------- 1 root root 134217728 Jan 1
00:03 resource0
-rw------- 1 root root 256 Jan 1
00:03 resource1
-rw------- 1 root root 65536 Jan 1
00:03 resource2
-r-------- 1 root root 131072 Jan 1
00:03 rom
-r--r--r-- 1 root root 4096 Jan 1
00:03 subsystem_device
-r--r--r-- 1 root root 4096 Jan 1
00:03 subsystem_vendor
--w------- 1 root root 4096 Jan 1
00:03 uevent
-r--r--r-- 1 root root 4096 Jan 1
00:03 vendor
~ # cat /proc/iomem
80000000-9fffffff : PCI prefetchable memory
a0000000-afffffff : PCI memory
a7ff0000-a7ffffff : 0000:00:18.0
a8000000-afffffff : 0000:00:18.0
~ # cat /proc/ioports
00000000-01ffffff : PCI I/O
01ffff00-01ffffff : 0000:00:18.0
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* 8272ads:PCI prefetchable mem access problem
From: Anil Dhonde @ 2006-02-15 14:59 UTC (permalink / raw)
To: linuxppc-dev
Hi all:
We have plugged an ATI Radeon video card into a PCI
slot on our powerpc 8272ads evaluation board. The
linux kernel 2.6.15 comes up, detects the card on the
bus, rolls in the ATI Radeon framebuffer driver as it
should. All register/PCI config space access is fine.
The trouble starts when I try to access the 128MByte
video memory on the card. As you can see below, there
are three regions for this card - one pre-fetchable,
one non-prefetchable and one io. The 128MByte region
is flagged prefetchable.
I can:
- mmap (in userland) or ioremap (in kernel space) the
non-prefetchable region and do what I want to with it
(read/write). User space I use either /proc or /sys
handles and in the kernel my driver does the remapping
I cannot:
- mmap or remap the prefetchable region though the
calls to ioremap and mmap return success.
- Kernel ioremap returns success but the powerpc
crashes as soon as I read or write to space that has
just been remapped.
- mmap using either /proc or /sys based pci resource
access from user space fails the same way. mmap call
returns success but access cases a bus error.
something that looks suspicious:
cat /proc/iomem below shows that the ATI cards
prefetchable memory does not land up in the
prefetchable region of the PCI map. It lands in the
PCI memory (non-prefetchable region).
what I have tried:
- forcing PREFETCH flags to be NONPREFETCH by hacking
the kernel - this hack didnt work though /proc/pci
reports all pre-fetchables as non-prefetchables
meaning that flags were set properly.
any help/pointers from you guys will be great,
thanks a ton,
a
Platform details:
- powerpc 8272ads board, 64MByte eval board with
kernel 2.6.15
- ATI Radeon 7000 PCI based card with 128MByte mem
================== log ==============================
~ # cat /proc/pci
PCI devices found:
Bus 0, device 0, function 0:
Class 0600: PCI device 1057:18c1 (rev 16).
Master Capable. Latency=248.
Non-prefetchable 32 bit memory at 0x0 [0x1ffff].
Prefetchable 32 bit memory at 0x0 [0xfffffff].
Bus 0, device 24, function 0:
Class 0300: PCI device 1002:5159 (rev 0).
IRQ 66.
Master Capable. Latency=128. Min Gnt=8.
Prefetchable 32 bit memory at 0xa8000000
[0xafffffff].
I/O at 0x1ffff00 [0x1ffffff].
Non-prefetchable 32 bit memory at 0xa7ff0000
[0xa7ffffff].
~ # ls -l /sys/devices/pci0000\:00/0000\:00\:18.0/
lrwxrwxrwx 1 root root 0 Jan 1
00:03 bus ->
../../../bus/pci
-r--r--r-- 1 root root 4096 Jan 1
00:03 class
-rw-r--r-- 1 root root 256 Jan 1
00:03 config
-r--r--r-- 1 root root 4096 Jan 1
00:03 device
-r--r--r-- 1 root root 4096 Jan 1
00:03 irq
-r--r--r-- 1 root root 4096 Jan 1
00:03 local_cpus
-r--r--r-- 1 root root 4096 Jan 1
00:03 modalias
-r--r--r-- 1 root root 4096 Jan 1
00:03 resource
-rw------- 1 root root 134217728 Jan 1
00:03 resource0
-rw------- 1 root root 256 Jan 1
00:03 resource1
-rw------- 1 root root 65536 Jan 1
00:03 resource2
-r-------- 1 root root 131072 Jan 1
00:03 rom
-r--r--r-- 1 root root 4096 Jan 1
00:03 subsystem_device
-r--r--r-- 1 root root 4096 Jan 1
00:03 subsystem_vendor
--w------- 1 root root 4096 Jan 1
00:03 uevent
-r--r--r-- 1 root root 4096 Jan 1
00:03 vendor
~ # cat /proc/iomem
80000000-9fffffff : PCI prefetchable memory
a0000000-afffffff : PCI memory
a7ff0000-a7ffffff : 0000:00:18.0
a8000000-afffffff : 0000:00:18.0
~ # cat /proc/ioports
00000000-01ffffff : PCI I/O
01ffff00-01ffffff : 0000:00:18.0
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: yaboot 1.3.14 release candidate 1
From: Paul Nasrat @ 2006-02-15 16:43 UTC (permalink / raw)
To: Ben Collins; +Cc: linuxppc-dev list
In-Reply-To: <1139581305.5851.7.camel@grayson>
On Fri, 2006-02-10 at 09:21 -0500, Ben Collins wrote:
> Not sure if you have anything like this in your tree at the moment, but
> here's a patch we use for Ubuntu. It's based in part on code in silo (I
> maintain silo upstream). Since the two are very close in code, this made
> sense :). Silo allows you to add an arch in the image stanza like:
No, thanks for passing this on to me it looks sane, I'll test a little
then probably commit. Currently I've been doing this on macs with an
ofboot script checking 64-bit, but this is probably better.
Paul
^ permalink raw reply
* Re: 8272ads:PCI prefetchable mem access problem
From: Michel Dänzer @ 2006-02-15 17:04 UTC (permalink / raw)
To: Anil Dhonde; +Cc: linuxppc-dev
In-Reply-To: <20060215145954.43697.qmail@web30711.mail.mud.yahoo.com>
On Wed, 2006-02-15 at 06:59 -0800, Anil Dhonde wrote:
>=20
> We have plugged an ATI Radeon video card into a PCI
> slot on our powerpc 8272ads evaluation board. The
> linux kernel 2.6.15 comes up, detects the card on the
> bus, rolls in the ATI Radeon framebuffer driver as it
> should. All register/PCI config space access is fine.
So does radeonfb work, or is that part of the problem?
Note that radeonfb doesn't do the low-level card initialization normally
done by the on-card ROM, (how?) does your evaluation board do that?
--=20
Earthling Michel D=C3=A4nzer | Debian (powerpc), X and DRI develop=
er
Libre software enthusiast | http://svcs.affero.net/rm.php?r=3Ddaenzer
^ permalink raw reply
* Re: Gigabit ethernet support of ppc440gx in 2.6 and 2.4
From: Eugene Surovegin @ 2006-02-15 18:36 UTC (permalink / raw)
To: ?????????; +Cc: linuxppc-embedded
In-Reply-To: <43F2CF5D.2AFC8D.22998>
On Wed, Feb 15, 2006 at 02:08:52PM +0800, ????????? wrote:
> We want to get a data rate of 600Mbits/s over gigabit ethernet of ppc440gx.
> How about the status of support to ppc440gx GigE in Linux kernel?
> Which kernel version should we select? 2.6 or 2.4?
GigE support for 440GX is in official 2.6. Patch for 2.4 is available
at http://kernel.ebshome.net. If you don't feel comfortable dealing
with kernel patches, I'd recommend 2.6
Effective Ethernet throughput highly depends on packet size. For some
small packet sizes 600Mb/s is theoretically impossible over GigE.
I achieved 900+ Mb/s TCP throughput with my driver (packets around 4K
long) and using sendfile(2) based test application.
--
Eugene
^ permalink raw reply
* Re: no sys folder under /proc
From: dibacco @ 2006-02-15 20:28 UTC (permalink / raw)
To: galak, linuxppc-embedded
I discovered that "klogd" is not running. This could be a problem. Is it =
mandatorty to run it to see kernel messages?
Thank you for your help,
bye.
---------- Initial Header -----------
>From : "Kumar Gala" galak@kernel.crashing.org
To : "dibacco@inwind.it" dibacco@inwind.it
Cc :
Date : Wed, 15 Feb 2006 12:39:12 -0600 (CST)
Subject : Re: no sys folder under /proc
> On Wed, 15 Feb 2006, dibacco@inwind.it wrote:
>
> > Syslogd is running and it is logging things like the start of busybox=
for example. The printk doesn't appear in the "messages" file.
> >
>
> Does it appear in dmesg?
>
> You may need to config syslogd to capture the data.
>
> - kumar
>
>
^ permalink raw reply
* no printk messages in /var/log/messages
From: dibacco @ 2006-02-15 21:38 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I'm running klogd and syslogd from BusyBox 1.1.0. Some messages are logge=
d to /var/log/messages but no kernel messages. I'm printing KERN_ERR but =
also KERN_EMERG and nothing seen!?!?! If I do cat /proc/kmsg it hangs but=
nothing print.
Bye,
Antonio.
^ permalink raw reply
* IMAP_ADDR is virtual or physical address?
From: dibacco @ 2006-02-15 21:41 UTC (permalink / raw)
To: linuxppc-embedded
I'm wondering if IMAP_ADDR is a virtual address or a physical one. Normal=
ly I see things like this in drivers:
static volatile immap_t *immr =3D (immap_t *) IMAP_ADDR;
It seems therefore a virtual address.
But I can see the same also in some u-boot code where I imagine we are ac=
cessing physical addresses.
Clear my doubt please!!
Bye,
^ permalink raw reply
* Re: IMAP_ADDR is virtual or physical address?
From: Kumar Gala @ 2006-02-15 21:36 UTC (permalink / raw)
To: dibacco@inwind.it; +Cc: linuxppc-embedded
In-Reply-To: <IUR08Q$EA50D33FB87244406C6EB74722F8E71C@libero.it>
On Wed, 15 Feb 2006, dibacco@inwind.it wrote:
> I'm wondering if IMAP_ADDR is a virtual address or a physical one. Normally I see things like this in drivers:
>
> static volatile immap_t *immr = (immap_t *) IMAP_ADDR;
>
> It seems therefore a virtual address.
IMAP_ADDR tends to be a physical address, however its mapped 1:1 in the
kernel via io_block_mapping() on a number of systems to get the 1:1
mapping.
This is somewhat frowned upon, and drivers should really do their own
ioremap() with a physical address for IMAP_ADDR.
>
> But I can see the same also in some u-boot code where I imagine we are accessing physical addresses.
>
> Clear my doubt please!!
In u-boot everything is mapped 1:1 so there is no difference between virt
and phys addrs.
- kumar
^ permalink raw reply
* MMU is enabled in u-boot?
From: dibacco @ 2006-02-15 21:58 UTC (permalink / raw)
To: linuxppc-embedded
u-boot works with MMU enabled? Why is it needed, if so?
^ permalink raw reply
* Re: MMU is enabled in u-boot?
From: Eugene Surovegin @ 2006-02-15 22:00 UTC (permalink / raw)
To: dibacco@inwind.it; +Cc: linuxppc-embedded
In-Reply-To: <IUR10W$F435AD432BF7E29E360C74B2CBBCC42B@libero.it>
On Wed, Feb 15, 2006 at 10:58:08PM +0100, dibacco@inwind.it wrote:
> u-boot works with MMU enabled? Why is it needed, if so?
Depends on CPU. Some CPUs just don't work without MMU.
--
Eugene
^ permalink raw reply
* Cache-inhibited region for certain exception handler(e500 chips, 2.4 kernel)?
From: Xianghua Xiao @ 2006-02-15 22:06 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1067 bytes --]
Is there a way to put certain exception handler(e.g. machine check) on e500
to a cache-inhibited region?
1. The e500 kernel puts exception handlers at the starting of the physical
memory.
2. All the physical memory are covered by a few TLB1s to do
0xc0000000-0x00000000 translation.
3. We can not add a new TLB1 to map a small piece of memory, because it has
boundary limitation(4K...256M). We can not use two TLB1 to overlap since it
will cause program error.
4. When we tried to move a handler(e.g. machine check) to a different
location, the kernel won't boot.
5. We don't want to map all the exceptional handlers to be cache inhibited,
say, the first 1MB, the performance will be horrible if we do so.
Is there a way at all to tweak things like this, i.e., put an exception
handler into a piece of memory that is cache-inhibited?
I also thought about use mlock/mmap on /dev/mem, move the specific exception
handler to a high address then use a separate TLB1 to cover it(need change
link script?),etc.
Any suggestion is greatly appreciated.
xianghua
[-- Attachment #2: Type: text/html, Size: 2687 bytes --]
^ permalink raw reply
* Re: Cache-inhibited region for certain exception handler(e500 chips, 2.4 kernel)?
From: Kumar Gala @ 2006-02-15 23:25 UTC (permalink / raw)
To: risc10; +Cc: linuxppc-embedded
In-Reply-To: <000201c6327c$1a2b80f0$b07c520a@fsl.freescale.net>
On Wed, 15 Feb 2006, Xianghua Xiao wrote:
> Is there a way to put certain exception handler(e.g. machine check) on e500
> to a cache-inhibited region?
>
> 1. The e500 kernel puts exception handlers at the starting of the physical
> memory.
> 2. All the physical memory are covered by a few TLB1s to do
> 0xc0000000-0x00000000 translation.
> 3. We can not add a new TLB1 to map a small piece of memory, because it has
> boundary limitation(4K...256M). We can not use two TLB1 to overlap since it
> will cause program error.
> 4. When we tried to move a handler(e.g. machine check) to a different
> location, the kernel won't boot.
> 5. We don't want to map all the exceptional handlers to be cache inhibited,
> say, the first 1MB, the performance will be horrible if we do so.
>
> Is there a way at all to tweak things like this, i.e., put an exception
> handler into a piece of memory that is cache-inhibited?
>
> I also thought about use mlock/mmap on /dev/mem, move the specific exception
> handler to a high address then use a separate TLB1 to cover it(need change
> link script?),etc.
>
Why exactly do you the mcheck handler to be cache inhibited? One simple
way would be to setup a temp mapping in kernel virtual address space
somewhere and have the first thing the current handler does is jump to
that location.
- kumar
^ permalink raw reply
* PowerQUICC II Pro MPC8349E-MDS Linux 2.6 support
From: David Hawkins @ 2006-02-15 23:50 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <Pine.LNX.4.44.0602151722050.30048-100000@gate.crashing.org>
Hi Kumar,
I saw your email earlier, so figured you were listening in
on the PPC group at the moment.
In the recent 2.6 kernel source, you authored the file:
arch/ppc/platforms/83xx/mpc834x_sys.h and .c
are these files for the MPC8349E-MDS board?
In the Denx source, there is modified versions for the
TQM board, but I wasn't sure what platform the original
files were targeted for.
Thanks,
Dave Hawkins,
Caltech.
^ permalink raw reply
* Re: PowerQUICC II Pro MPC8349E-MDS Linux 2.6 support
From: Kumar Gala @ 2006-02-15 23:45 UTC (permalink / raw)
To: David Hawkins; +Cc: linuxppc-embedded
In-Reply-To: <43F3BE4A.7070603@ovro.caltech.edu>
On Wed, 15 Feb 2006, David Hawkins wrote:
>
> Hi Kumar,
>
> I saw your email earlier, so figured you were listening in
> on the PPC group at the moment.
>
> In the recent 2.6 kernel source, you authored the file:
>
> arch/ppc/platforms/83xx/mpc834x_sys.h and .c
>
> are these files for the MPC8349E-MDS board?
Yes, Freescale names the board four different things durings its
development (ADS, SYS, MDS, ok maybe only three :)
> In the Denx source, there is modified versions for the
> TQM board, but I wasn't sure what platform the original
> files were targeted for.
Not sure, I follow. The MPC834x MDS was the first 834x system supported.
However, if you are looking at 834x, I recommend you grab my u-boot tree
from kernel.org since it has support for booting the kernel with a flat
device tree. From 2.6.16, all future 83xx work will be done in
arch/powerpc which requires a flat dev tree to boot.
- kumar
^ permalink raw reply
* Re: PowerQUICC II Pro MPC8349E-MDS Linux 2.6 support
From: David Hawkins @ 2006-02-16 0:01 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <Pine.LNX.4.44.0602151743030.450-100000@gate.crashing.org>
>> ... for the MPC8349E-MDS board?
>
> Yes, Freescale names the board four different things durings its
> development (ADS, SYS, MDS, ok maybe only three :)
Ok, great.
>>In the Denx source, there is modified versions for the
>>TQM board, but I wasn't sure what platform the original
>>files were targeted for.
>
> Not sure, I follow. The MPC834x MDS was the first 834x system supported.
Sorry, my fault, I wasn't clear.
I was just referring to the fact that in addition to your
source, the Denx tree also has the work they are doing on
the TQM board that contains an 8349E.
> However, if you are looking at 834x, I recommend you grab my u-boot tree
> from kernel.org since it has support for booting the kernel with a flat
> device tree. From 2.6.16, all future 83xx work will be done in
> arch/powerpc which requires a flat dev tree to boot.
Ok.
The reason I was asking, was that I want to benchmark an 8349E
based system. Wolfgang Denx mentioned the TQM system, so I took
a look in the Denx tree, and saw that their work was based
on yours. I assumed your work was for a Freescale reference board,
but didn't know which.
Thanks for the clarification.
Dave
^ permalink raw reply
* Re: Re: Gigabit ethernet support of ppc440gx in 2.6 and 2.4
From: Eugene Surovegin @ 2006-02-16 4:49 UTC (permalink / raw)
To: ?????????; +Cc: linuxppc-embedded
In-Reply-To: <43F402AC.026BD0.10674>
On Thu, Feb 16, 2006 at 12:45:15PM +0800, ????????? wrote:
> Does the TCP/IP Acceleration Hardware of 440GX have been supported
> in official 2.6 kernel?
> How about the CPU utilization when you get 900+Mb/s? Since we want
> to do something such as simple datas codec at the same time.
My driver (both 2.4 and 2.6) supports TCP/UDP checksum offload. No TSO
yet.
I don't remember exact CPU load numbers, but it was less than 20% for
TX case (Ocotea was transmitting data).
--
Eugene
^ permalink raw reply
* Re: Re: Gigabit ethernet support of ppc440gx in 2.6 and 2.4
From: 廖荣生 @ 2006-02-16 4:45 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-embedded
Hi Eugene:
Does the TCP/IP Acceleration Hardware of 440GX have been supported in official 2.6 kernel?
How about the CPU utilization when you get 900+Mb/s? Since we want to do something such as simple datas codec at the same time.
Regards,
Lonsn
>
>On Wed, Feb 15, 2006 at 02:08:52PM +0800, ????????? wrote:
>> We want to get a data rate of 600Mbits/s over gigabit ethernet of ppc440gx.
>> How about the status of support to ppc440gx GigE in Linux kernel?
>> Which kernel version should we select? 2.6 or 2.4?
>
>GigE support for 440GX is in official 2.6. Patch for 2.4 is available
>at http://kernel.ebshome.net. If you don't feel comfortable dealing
>with kernel patches, I'd recommend 2.6
>
>Effective Ethernet throughput highly depends on packet size. For some
>small packet sizes 600Mb/s is theoretically impossible over GigE.
>
>I achieved 900+ Mb/s TCP throughput with my driver (packets around 4K
>long) and using sendfile(2) based test application.
>
>--
>Eugene
>
>
^ permalink raw reply
* scatter/gather DMA and cache coherency
From: Phil Nitschke @ 2006-02-16 7:21 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I've been using a PCI device driver developed by a third party company.
It uses a scatter/gather DMA I/O to transfer data from the PCI device
into user memory. When using a buffer size of about 1 MB, the driver
achieves a transfer bandwidth of about 60 MB/s, on a 66 MHz, 32-bit
bus.
The problem is, that sometimes the data is corrupt (usually on the first
transfer). We've concluded that the problem is related to cache
coherency. The Artesyn 2.6.10 reference kernel (branched from the
kernel at penguinppc.org) must be built with CONFIG_NOT_COHERENT_CACHE=y,
as Artesyn have never successfully verified operation with hardware
coherency enabled.
My understanding is that their Marvel system controller (MV64460)
supports cache snooping, but their Linux kernel support hasn't caught up
yet.
So if I understand my situation correctly, the device driver must use
software-enforced coherency to avoid data corruption. Is this correct?
What currently happens is this:
The buffers are allocated with get_user_pages(...)
After each DMA transfer is complete, the driver invalidates the cache
using __dma_sync_page(...)
Only on close() does the driver set the pages dirty, like this:
/* Set each cache page dirty */
for (ipage = 0; ipage < nr_pages; ipage++)
{
if (!PageReserved (pages[ipage]))
SetPageDirty ( pages[ ipage ] );
}
/* Every mapped page must be released from the page cache */
for (ipage = 0; ipage < nr_pages; ipage++)
page_cache_release ( pages[ ipage ] );
According to my reading of "Linux Device Drivers, Third Edition" by
Jonathan Corbet, Alessandro Rubini, and Greg Kroah-Hartman,
SetPageDirty() should be called every time the pages are changed (not
just when the pages are released). (OTOH, the text does not mention the
__dma_sync_page() routine at all.)
Could this be the cause of the corruption we're seeing?
If not, are there any other steps required to enforce "software"
coherency?
--
Phil
^ permalink raw reply
* Re: scatter/gather DMA and cache coherency
From: Eugene Surovegin @ 2006-02-16 8:03 UTC (permalink / raw)
To: Phil Nitschke; +Cc: linuxppc-embedded
In-Reply-To: <kw4q2zg45r.fsf@lamorak.int.avalon.com.au>
On Thu, Feb 16, 2006 at 05:51:20PM +1030, Phil Nitschke wrote:
> Hi,
>
> I've been using a PCI device driver developed by a third party company.
> It uses a scatter/gather DMA I/O to transfer data from the PCI device
> into user memory. When using a buffer size of about 1 MB, the driver
> achieves a transfer bandwidth of about 60 MB/s, on a 66 MHz, 32-bit
> bus.
>
> The problem is, that sometimes the data is corrupt (usually on the first
> transfer). We've concluded that the problem is related to cache
> coherency. The Artesyn 2.6.10 reference kernel (branched from the
> kernel at penguinppc.org) must be built with CONFIG_NOT_COHERENT_CACHE=y,
> as Artesyn have never successfully verified operation with hardware
> coherency enabled.
> My understanding is that their Marvel system controller (MV64460)
> supports cache snooping, but their Linux kernel support hasn't caught up
> yet.
>
> So if I understand my situation correctly, the device driver must use
> software-enforced coherency to avoid data corruption. Is this correct?
>
> What currently happens is this:
>
> The buffers are allocated with get_user_pages(...)
>
> After each DMA transfer is complete, the driver invalidates the cache
> using __dma_sync_page(...)
No, buffers must be invalidated _before_ DMA transfer, not after.
Also, don't use internal PPC functions like __dma_sync_page. Please,
read Documentation/DMA-API.txt for official API.
--
Eugene
^ permalink raw reply
* Re: scatter/gather DMA and cache coherency
From: Phil Nitschke @ 2006-02-16 13:52 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-embedded
In-Reply-To: <20060216080303.GD23150@gate.ebshome.net>
>>>>> "ES" == Eugene Surovegin <ebs@ebshome.net> writes:
ES> On Thu, Feb 16, 2006 at 05:51:20PM +1030, Phil Nitschke wrote:
>> Hi,
>>
>> I've been using a PCI device driver developed by a third party
>> company. It uses a scatter/gather DMA I/O to transfer data from
>> the PCI device into user memory. When using a buffer size of
>> about 1 MB, the driver achieves a transfer bandwidth of about 60
>> MB/s, on a 66 MHz, 32-bit bus.
>>
>> The problem is, that sometimes the data is corrupt (usually on
>> the first transfer). We've concluded that the problem is related
>> to cache coherency. The Artesyn 2.6.10 reference kernel
>> (branched from the kernel at penguinppc.org) must be built with
>> CONFIG_NOT_COHERENT_CACHE=y, as Artesyn have never successfully
>> verified operation with hardware coherency enabled. My
>> understanding is that their Marvel system controller (MV64460)
>> supports cache snooping, but their Linux kernel support hasn't
>> caught up yet.
>>
>> So if I understand my situation correctly, the device driver must
>> use software-enforced coherency to avoid data corruption. Is
>> this correct?
>>
>> What currently happens is this:
>>
>> The buffers are allocated with get_user_pages(...)
>>
>> After each DMA transfer is complete, the driver invalidates the
>> cache using __dma_sync_page(...)
ES> No, buffers must be invalidated _before_ DMA transfer, not
ES> after. Also, don't use internal PPC functions like
ES> __dma_sync_page. Please, read Documentation/DMA-API.txt for
ES> official API.
Thanks for the suggestions. I'd like to point out, however, a few
points:
1/. I did not write the driver (see my first line above). I'm
reading someone else's source and trying to figure out whether it
is right or wrong, so I can discuss with them authoritatively
what is going on.
2/. I'm not _sure_ I understand terms like software-enforced
coherency, non-consistent platforms, etc. So should I be looking
at the API in section I or II of DMA-API.txt ? (I think section 'Id')
3/. I think I did not explain the DMA process clearly enough. This
is how the third party documentation says the driver should be
used (my annotations in parenthesis):
- Allocate and lock buffer into physical memory
(Call driver ioctl function to map user DMA buffer using
get_user_pages())
- Configure DMA chain
- Start DMA transfer
(Set ID of the DMA descriptor that the DMA controller
shall load first. Allow target to perform bus-mastered
DMA into platform memory)
- Wait for DMA transfer to complete
(interrupt signals end of transfer from target)
- Do Cache Invalidate
(Call driver ioctl which calls __dma_sync_page(), to
invalidate the cache prior to reading the buffer from the
host CPU. Then copy data from buffer into other user
memory.)
- Unlock and free buffer from physical memory
(Call device driver ioctl function which calls
free_user_pages())
So is __dma_sync_page being called by their driver routines at
the wrong time?
4/. The DMA-API.txt says:
"Memory coherency operates at a granularity called the cache
line width. In order for memory mapped by this API to operate
correctly, the mapped region must begin exactly on a cache
line boundary and end exactly on one (to prevent two
separately mapped regions from sharing a single cache line)."
Given that we're not relying on cache snooping, and we call
functions to invalidate the cache, does this statement still
apply?
Thanks again,
--
Phil
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox