* RE: xilinx Ml405 NFS mount problem
From: John Linn @ 2008-04-01 23:55 UTC (permalink / raw)
To: Robert Woodworth; +Cc: linuxppc-embedded
In-Reply-To: <1207093428.4830.79.camel@PisteOff>
Hi Rob,
I am using GigE and no checksum offload.
I don't have a quick way to test packet loss.
EDK 10.1 may help your problem.
-- John
-----Original Message-----
From: Robert Woodworth [mailto:rwoodworth@securics.com]=20
Sent: Tuesday, April 01, 2008 5:44 PM
To: John Linn
Cc: MingLiu; linuxppc-embedded@ozlabs.org
Subject: RE: xilinx Ml405 NFS mount problem
Can you test your packet loss with your setup??
GigE or 100T??
Do you have hardware checksum turned on in your bitfile?
I strongly believe that there is a timing problem in the MPMC3/LL_TEMAC.
I think the smaller FX12 does not suffer as much as the larger FX60. My
FX12 is fairly good, my FX60 is very bad. Guessing. The FX20 in the
ML405 is somewhere between.
When I make small changes to my bit file (I'm currently working on an
image processing HDL module) the quality of my LL_TEMAC changes
dramatically. If I take out one of my custom modules and re-synthesize
the LL_TEMAC packet loss goes way up. Add another module, re-synthesize
and packet loss is down.
I would *really* like a Xilinx EDK expert give me some advise on this
issue.
Rob.
On Tue, 2008-04-01 at 10:53 -0600, John Linn wrote:
> Now that you say that, I have been running TCP with my NFS mount as =
I'm mounting across a corporate network.
>=20
> I am also using the latest LL TEMAC with EDK 10.1.
>=20
> Thanks,
> John
>=20
> -----Original Message-----
> From: Robert Woodworth [mailto:rwoodworth@securics.com]=20
> Sent: Tuesday, April 01, 2008 10:50 AM
> To: MingLiu
> Cc: John Linn; linuxppc-embedded@ozlabs.org
> Subject: RE: xilinx Ml405 NFS mount problem
>=20
> I think you may be suffering from the latest LL_TEMAC packet loss
> problem. (NFS/UDP really does not like packet loss)
>=20
>=20
> Let me guess. =20
> You are using a base system from "Base System Builder Wizard"?
> EDK 9.2i. Default syntheses/P&R options.
>=20
> I have seen a massive packet loss problems on my ML403 and two other
> boards I have with an FX60.
>=20
> This is probably a hardware problem.
> Xilinx has acknowledged an LL_TEMAC problem to me but has not provided =
a
> fix. I have heard that things are better with EDK/ISE-10.1 but I have
> not tested it.
>=20
>=20
> The vendor of one of my boards (Pico) has fixed the problem on the =
FX60
> by highly constraining the timing of the LL_TEMAC in map/PR. On my
> ML403 I used similar constraints and it fixed the problem, but only if
> the device is plugged into a GigE switch. The problem is still there
> with the same .bit file on a 100-T switch.=20
>=20
>=20
> Are you on a GigE switch?
>=20
>=20
>=20
> Rob.
>=20
>=20
>=20
>=20
>=20
>=20
> On Tue, 2008-04-01 at 16:15 +0000, MingLiu wrote:
> > Dear John,
> > =20
> > Thank you for your replying.=20
> >=20
> > >It=A1=AFs not obvious to me what the problem is as I don=A1=AFt see =
any driver
> > failures. Have you >tried using a ramdisk and then seeing if the
> > network is working before using NFS root? =20
> > =20
> > Not yet. I will try it soon. However from the information on the
> > LL_TEMAC, it seems everything is fine and it should work.=20
> > =20
> >=20
> >=20
> > >And I=A1=AFm assuming you have used the NFS root before so you know =
that
> > it=A1=AFs good for sure.
> >=20
> > =20
> >=20
> > >I test on the ML405 with NFS root and haven=A1=AFt seen this =
problem, but
> > my setup is a little different. I use DHCP rather than >a static =
IP,
> > but other than that it=A1=AFs similar.
> >=20
> > =20
> >=20
> > Yes. I used NFS before. I can make sure my NFS server works well. =
Also
> > in principle, static IP should get a same result as DHCP, I think.=20
> >=20
> > =20
> >=20
> > >How long has it been since you pulled from the Xilinx Git tree?
> >=20
> > =20
> >=20
> > I just pulled the Xilinx tree quite recently. I am using a latest
> > kernel.
> >=20
> > =20
> >=20
> > BR=20
> >=20
> > Ming
> >=20
> > =20
> >=20
> > =20
> > =20
> > And I=A1=AFm assuming you have used the NFS root before so =
you know
> > that it=A1=AFs good for sure.
> > =20
> > =20
> > =20
> > I test on the ML405 with NFS root and haven=A1=AFt seen this
> > problem, but my setup is a little different. I use DHCP
> > rather than a static IP, but other than that it=A1=AFs =
similar.
> > =20
> > =20
> > =20
> > I=A1=AFm assuming that you accidentally got 2 different =
powerup
> > outputs in the message below as the 1st stops and a 2nd =
starts
> > in the middle.
> > =20
> > =20
> > =20
> > How long has it been since you pulled from the Xilinx Git
> > tree?
> > =20
> > =20
> > =20
> > Thanks,
> > =20
> > John
> > =20
> > =20
> > =20
> > =20
> > =
______________________________________________________________
> > From: linuxppc-embedded-bounces
> > +john.linn=3Dxilinx.com@ozlabs.org
> > [mailto:linuxppc-embedded-bounces
> > +john.linn=3Dxilinx.com@ozlabs.org] On Behalf Of MingLiu
> > Sent: Tuesday, April 01, 2008 8:12 AM
> > To: linuxppc-embedded@ozlabs.org
> > Subject: xilinx Ml405 NFS mount problem
> > =20
> > =20
> > =20
> > =20
> > Dear friends,
> > =20
> > I am bringing up my kernel from Xilinx git tree. =
Unfortunately I met some
> > problem when mounting the root file system. Here is the =
information
> > listed. I will appreciate a lot if someone can help me out =
of the trouble.=20
> > Thanks a lot!
> > =20
> > =20
> > loaded at: 00400000 0059F19C
> > board data at: 0059D120 0059D19C
> > relocated to: 004050C8 00405144
> > zimage at: 00405F3F 0059C025
> > avail ram: 005A0000 08000000
> > =20
> > Linux/PPC load: root=3D/dev/nfs
> > ip=3D192.168.0.4:192.168.0.3:192.168.0.3:255.255.255.0 rw
> > nfsroot=3D192.168.0.3:/home/mingliu/ml403_rootfs =
console=3DttyUL0,38400
> > mem=3D32M
> > Uncompressing Linux...done.
> > Now booting the kernel
> > Linux version 2.6.24-rc8-xlnx-g1db182b8-dirty =
(mingliu@cca01) (gcc version
> > 3.4.1) #7 Tue Apr 1 14:55:25 CEST 2008
> > Xilinx Generic PowerPC board support package (Xilinx ML405) =
(Virtex-4 FX)
> > Zone PFN ranges:
> > DMA 0 -> 8192
> > =20
> > Normal 8192 -> 8192
> > =20
> > HighMem 8192 -> 8192
> > Movable zone start PFN for each node
> > early_node_map[1] active PFN ranges
> > 0: 0 -> 8192
> > Built 1 zonelists in Zone order, mobility grouping on. =
Total pages: 8128
> > Kernel command line: root=3D/de v/nfs
> > ip=3D192.168.0.4:192.168.0.3:192.168.0.3:255.255.255.0 rw
> > nfsroot=3D192.168.0.3:/home/mingliu/ml403_rootfs =
console=3DttyUL0,38400
> > mem=3D32M
> > Xilinx INTC #0 at 0x81800000 mapped to 0xFDFFF000
> > PID hash table entries: 128 (order: 7, 512 bytes)
> > Console: colour dummy device 80x25
> > Dentry cache hash table entries: 4096 (order: 2, 16384 =
bytes)
> > Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
> > Memory: 28884k available (2552k kernel code, 944k data, 84k =
init, 0k highmem)
> > SLUB: Genslabs=3D11, HWalign=3D32, Order=3D0-1, =
MinObjects=3D4, CPUs=3D1, Nodes=3D1
> > Mount-cache hash table entries: 512
> > net_namespace: 64 bytes
> > NET: Registered protocol family 16
> > Registering device uartlite:0
> > Fixup MAC address for xilinx_lltemac:0
> > Regis tering device xilinx_lltemac:0
> > NET: Registered protocol family 2
> > IP route cache hash table entries: 1024 (order: 0, 4096 =
bytes)
> > TCP established hash table entries: 1024 (order: 1, 8192 =
bytes)
> > TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
> > TCP: Hash tables configured (established 1024 bind 1024)
> > TCP reno registered
> > sysctl table check failed: /kernel/l2cr .1.31 Missing =
strategy
> > Call Trace:
> > [c1c0fe50] [c0008b70] show_stack+0x40/0x194 (unreliable)
> > [c1c0fe90] [c003aed4] set_fail+0x68/0x80
> > [c1c0feb0] [c003b4ec] sysctl_check_table+0x600/0x77c
> > [c1c0fef0] [c003b4d4] sysctl_check_table+0x5e8/0x77c
> > [c1c0ff30] [c002605c] register_sysctl_table+0x64/0xb4
> > [c1c0ff50] [c034579c] register_ppc_htab_sysctl+0x18/0x2c
> > [c1c0ff60] [c034482c] kernel_init+0x94/0x2bc
> > [c1c0fff0] [c0004d58] kernel_thread+0x44/0x60
> > Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
> > fuse init (API version 7.9)
> > io scheduler noop registered
> > io scheduler anticipatory registered
> > io scheduler deadline registered
> > io scheduler cfq registered (default)
> > uartlite.0: ttyUL0 at MM IO 0x84000003 (irq =3D 3) is a =
uartlite
> > console [ttyUL0] enabled
> > loop: module loaded
> > nbd: registered device at major 43
> > xilinx_lltemac xilinx_lltemac.0: MAC address is now 0: =
a:35: 1: 2: 3
> > xilinx_lltemac xilinx_lltemac.0: XLlTemac: using DMA mode.
> > XLlTemac: Dma base address: phy: 0x84600100, virt: =
0xc3008100
> > XLlTemac: buffer descriptor size: 32768 (0x8000)
> > XLlTemac: Allocating DMA descriptors with =
kmalloc<6>XLlTemac:
> > (buffer_descriptor_init) phy: 0x1d18000, virt: 0xc1d18000, =
size: 0x8000
> > XTemac: PHY detected at address 7.
> > xilinx_lltemac xilinx_lltemac.0: eth0: Xilinx TEMAC at =
0x81C00000 mapped
> > to 0xC3004000, irq=3D2
> > console [netcon0] enabled
> > Linux version 2.6.24-rc8-xlnx-g1db182b8-dirty =
(mingliu@cca01) (gcc version
> > 3.4.1) #7 Tue Apr 1 14:55:25 CEST 2008
> > =20
> > Xilinx Generic PowerPC board support package (Xilinx ML405)
> > (Virtex-4 FX)
> > =20
> > Zone PFN ranges:
> > DMA 0 -> 8192
> > Normal 8192 -> 8192
> > HighMem 8192 -> 8192
> > Movable zone start PFN for each node
> > early_node_map[1] active PFN range
> > s
> > 0: 0 -> 8192
> > Built 1 zonelists in Zone order, mobility grouping on. =
Total pages: 8128
> > Kernel command line: root=3D/dev/nfs
> > ip=3D192.168.0.4:192.168.0.3:192.168.0.3:255.255.255.0 rw
> > nfsroot=3D192.168.0.3:/home/mingliu/ml403_rootfs =
console=3DttyUL0,38400
> > mem=3D32M
> > Xilinx INTC #0 at 0x81800000 mapped to 0xFDFFF000
> > PID hash table entries: 128 (order: 7, 512 bytes)
> > Console: colour dummy device 80x25
> > Dentry cache hash table entries: 4096 (order: 2, 16384 =
bytes)
> > Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
> > Memory: 28884k available (2552k kernel code, 944k data, 84k =
init, 0k highmem)
> > SLUB: Genslabs=3D11, HWalign=3D32, Order=3D0-1, =
MinObjects=3D4, CPUs=3D1, Nodes=3D1
> > Mount-cache hash table entries: 512
> > n
> > et_namespace: 64 bytes
> > NET: Registered protocol family 16
> > Registering device uartlite:0
> > Fixup MAC address for xilinx_lltemac:0
> > Registering device xilinx_lltemac:0
> > NET: Registered protocol family 2
> > IP route cache hash table entries: 1024 (order: 0, 4096 =
bytes)
> > TCP established hash table entries: 1024 (order: 1, 8192 =
bytes)
> > TCP bind hash table entries: 1024
> > (order: 0, 4096 bytes)
> > TCP: Hash tables configured (established 1024 bind 1024)
> > TCP reno registered
> > sysctl table check failed: /kernel/l2cr .1.31 Missing =
strategy
> > Call Trace:
> > [c1c0fe50] [c0008b70] show_stack+0x40/0x194 (unreliable)
> > [c1c0fe90] [c003aed4] set_fail+0x68/0x80
> > [c1c0feb0] [c003b4ec] sysctl_check_table+0x600/0x77c
> > [c1c0fef0] [c003b4d4] sysctl_c
> > heck_table+0x5e8/0x77c
> > [c1c0ff30] [c002605c] register_sysctl_table+0x64/0xb4
> > [c1c0ff50] [c034579c] register_ppc_htab_sysctl+0x18/0x2c
> > [c1c0ff60] [c034482c] kernel_init+0x94/0x2bc
> > [c1c0fff0] [c0004d58] kernel_thread+0x44/0x60
> > Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
> > fuse init (API version 7.9)
> > io scheduler noop registered<
> > /SPAN>
> > io scheduler anticipatory registered
> > io scheduler deadline registered
> > io scheduler cfq registered (default)
> > uartlite.0: ttyUL0 at MMIO 0x84000003 (irq =3D 3) is a =
uartlite
> > console [ttyUL0] enabled
> > loop: module loaded
> > nbd: registered device at major 43
> > xilinx_lltemac xilinx_lltemac.0: MAC address is now 0: =
a:35: 1: 2: 3
> > xilinx_lltemac xilinx_lltemac.0: XLlTemac: using DMA mode.
> > XLlTemac: Dma base address: phy: 0x84600100, virt: =
0xc3008100
> > XLlTemac: buffer descriptor size: 32768 (0x8000)
> > XLlTemac: Allocating DMA descriptors with =
kmalloc<6>XLlTemac:
> > (buffer_descriptor_init) phy: 0x1d18000, virt: 0xc1d18000, =
size: 0x8000
> > XTemac: PHY detected at address 7.
> > xilinx_lltemac xilinx_lltemac.0: eth0: Xilinx TEMAC at =
0x81C00000 mapped
> > <
> > SPAN style=3D"FONT-SIZE: 12pt">to 0xC3004000, irq=3D2
> > console [netcon0] enabled
> > netconsole: network logging started
> > Generic platform RAM MTD, (c) 2004 Simtec Electronics
> > mice: PS/2 mouse device common for all mice
> > TCP cubic registered
> > NET: Registered protocol family 1
> > NET: Registered protocol family 17
> > RPC: Registered udp transport module.
> > RPC: Registered tcp transport module.
> > eth0: XLlTemac: Options: 0x3fa
> > eth0: XLlTemac: allocating interrupt 0 for dma mode tx.
> > eth0: XLlTemac: allocating interrupt 1 for dma mode rx.
> > eth0: XLlTemac: speed set to 1000Mb/s
> > eth0: XLlTemac: Send Threshold =3D 24, Receive Threshold =3D =
4
> > eth0: XLlTemac: Send Wait bound =3D 254, Receive Wait bound =
=3D 254
> > IP-Config: Complete:
> > =20
> > device=3Deth0, addr=3D192.168.0.4, =
mask=3D255.255.255.0, gw=3D192.168.0.3,
> > host=3D192.168.0.4, domain=3D, nis-domain=3D(none),
> > bootserver=3D192.168.0.3, rootserver=3D192.168.0.3, =
rootpath=3D
> > Looking up port of RPC 100003/2 on 192.168.0.3
> > rpcbind: server 192.168.0.3 not responding, timed out
> > Root-NFS: Unable to get nfsd port number from server, using =
default
> > Looking up port of RPC 10000
> > 5/1 on 192.168.0.3
> > rpcbind: server 192.168.0.3 not responding, timed out
> > Root-NFS: Unable to get mountd port number from server, =
using default
> > mount: server 192.168.0.3 not responding, timed out
> > Root-NFS: Server returned error -5 while mounting =
/home/mingliu/ml403_rootfs
> > VFS: Unable to mount root fs via NFS, trying floppy.
> > VFS: Cannot open root device "nfs" or unknown-block(2,0)
> > Please append a correct "root=3D" boot option; here are=20
> > the available
> > partitions:
> > Kernel panic - not syncing: VFS: Unable to mount root fs on
> > unknown-block(2,0)
> > Rebooting in 180 seconds..
> > =20
> > =20
> > BR
> > Ming
> > =20
> > =20
> > =20
> > =20
> > =
______________________________________________________________
> > Windows Live =
Writer=A3=AC=D6=A7=B3=D6=C0=EB=CF=DF=D7=AB=D0=B4=B2=A9=BF=CD=C4=DA=C8=DD=A3=
=AC=CB=E6=CA=B1=CB=E6=B5=D8=CF=EB=D0=B4=BE=CD=D0=B4=A1=A3
> > =C1=A2=BC=B4=CA=B9=D3=C3=A3=A1
> > =20
> > =20
> >=20
> >=20
> > =
______________________________________________________________________
> > =CA=B9=D3=C3=D0=C2=D2=BB=B4=FA Windows Live Messenger =
=C7=E1=CB=C9=BD=BB=C1=F7=BA=CD=B9=B2=CF=ED=A3=A1 =
=C1=A2=BC=B4=CC=E5=D1=E9=A3=A1=20
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
>=20
>=20
^ permalink raw reply
* Re: [PATCH 01/11] [POWERPC] bootwrapper: Allow specifying of image physical offset
From: Paul Mackerras @ 2008-04-02 0:58 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <5DBEA342-7674-414B-A666-B8FBEED34814@kernel.crashing.org>
Kumar Gala writes:
> Hmm, need to think about that. But my initial reaction is two fold.
> One I don't think this information would be around and two don't we
> already have this problem with a kdump kernel?
I'm just concerned that we have two things that have to match up - the
compiled-in physical address that the kernel assumes it is running at,
and the physical address where it is actually loaded. While those two
things were both always 0 for embedded processors, there wasn't a
problem, but now we can have a situation where a kernel binary has to
be loaded at some nonzero address to work correctly, but there is no
way to work out what that address is for an existing vmlinux binary.
Or have I missed something?
For a kdump kernel, at least for 64-bit, the physical address has to
be 32MB. There is no other choice, so there is no possibility of
confusion.
For 85xx, would it be possible to have the kernel figure out what
physical address it has been loaded at, and use that as the base
address, rather than having the base address set at compile time?
That would solve my objection since it would mean that there would no
longer be two things that had to be kept in sync. You could pass any
value to wrapper/mkimage (subject to constraints such as it has to be
a multiple of 256M) and it would work. That value could even come
from a config option in the case where wrapper is invoked as part of
the kernel build, but that config option shouldn't affect anything at
all in the vmlinux.
Paul.
^ permalink raw reply
* Re: Access physical memory via mmap() on ppc440epx.
From: Josh Boyer @ 2008-04-02 1:44 UTC (permalink / raw)
To: Leonid; +Cc: linuxppc-embedded
In-Reply-To: <406A31B117F2734987636D6CCC93EE3C033A981B@ehost011-3.exch011.intermedia.net>
On Tue, 2008-04-01 at 14:12 -0700, Leonid wrote:
> Hi:
>
> I am trying to read from NOR flash, located on address 0xfc000000, on my
It's at 0x1fc000000 IIRC.
> TLB entries look strange though. That what it was on u-boot stage:
>
> 440EPx>tlb 0 10
> IDX TID EPN SIZE VTS RPN USER WIMGE USRSVC
> 0 : 00 40000000 256MB V0 -> 0_00000000 U:0000 -I-G- XWRXWR
> 1 : 00 00000000 256MB V0 -> 0_00000000 U:0000 -I-G- XWRXWR
> 2 : 00 c0000000 256MB V0 -> 1_c0000000 U:0000 -I-G- XWRXWR
> 3 : 00 f0000000 256MB V0 -> 1_f0000000 U:0000 WI-G- XWRXWR
See. Virtual is 0xf0000000, physical is 0x1f0000000.
> On Linux stage it looks rather different:
I don't even see your entry in here. Likely because the TLB is small
and it's gone by the time you do the dump
> Probably under MMU it should look this way? How to use mmap() then?
Try mmap64 on the real physical address and see if that helps.
josh
^ permalink raw reply
* Re: [PATCH] Make #include <sysdev/foo.h> work for 64-bit powerpc
From: Michael Ellerman @ 2008-04-02 1:55 UTC (permalink / raw)
To: Kumar Gala; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <0A4216BD-1505-46DE-B08E-23E9B7E51AD2@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 930 bytes --]
On Tue, 2008-04-01 at 08:18 -0500, Kumar Gala wrote:
> On Apr 1, 2008, at 1:54 AM, Stephen Rothwell wrote:
> > Hi Michael,
> >
> > On Tue, 1 Apr 2008 17:39:11 +1100 (EST) Michael Ellerman <michael@ellerman.id.au
> > > wrote:
> >>
> >> We currently have inconsistent settings between 32 & 64-bit which
> >> means
> >> 32-bit code can #include <sysdev/foo.h> but 64-bit code can't.
> >
> > Kumar sent a very similar (if not identical) patch earlier today.
>
> I actually sent it several days ago, but reposted as part of the
> series of work I was doing. ;)
OK, I missed it. I'm not fussed who's goes in, I just needed it for some
other work.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Please pull from 'for-2.6.25' branch
From: Kumar Gala @ 2008-04-02 2:36 UTC (permalink / raw)
To: Paul Mackerras; +Cc: ppc-dev list, Linus Torvalds
In-Reply-To: <Pine.LNX.4.64.0803311156160.4549@blarg.am.freescale.net>
On Mar 31, 2008, at 11:57 AM, Kumar Gala wrote:
> Please pull from 'for-2.6.25' branch of
>
> master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git
> for-2.6.25
>
> I'd like to get these minor fixes into 2.6.25. They aren't critical
> but
> extremely convenient at this point.
Paul, any comments on sending this onto linus. I was hoping to avoid
2.6.25 coming up not support the proper device bindings for DMA and
SATA.
- k
>
>
> to receive the following updates:
>
> arch/powerpc/boot/dts/mpc8377_mds.dts | 4 ++--
> arch/powerpc/boot/dts/mpc8377_rdb.dts | 3 +--
> arch/powerpc/boot/dts/mpc8378_rdb.dts | 3 +--
> arch/powerpc/boot/dts/mpc8379_mds.dts | 8 ++++----
> arch/powerpc/boot/dts/mpc8379_rdb.dts | 3 +--
> arch/powerpc/configs/mpc832x_mds_defconfig | 11 +++--------
> arch/powerpc/configs/mpc834x_mds_defconfig | 11 +++--------
> arch/powerpc/configs/mpc836x_mds_defconfig | 11 +++--------
> arch/powerpc/configs/mpc837x_rdb_defconfig | 24 ++++++++++++++++++
> +++++-
> arch/powerpc/configs/mpc83xx_defconfig | 24 ++++++++++++++++++
> +++++-
> arch/powerpc/configs/mpc8544_ds_defconfig | 11 +++--------
> arch/powerpc/configs/mpc8568mds_defconfig | 11 +++--------
> arch/powerpc/configs/mpc8572_ds_defconfig | 11 +++--------
> arch/powerpc/configs/mpc85xx_defconfig | 11 +++--------
> arch/powerpc/configs/mpc8641_hpcn_defconfig | 11 +++--------
> arch/powerpc/configs/prpmc2800_defconfig | 11 +++--------
> arch/powerpc/configs/storcenter_defconfig | 11 +++--------
> drivers/ata/sata_fsl.c | 5 +----
> drivers/dma/fsldma.c | 8 ++++----
> 19 files changed, 90 insertions(+), 102 deletions(-)
>
> Anton Vorontsov (1):
> [POWERPC] 83xx: Fix wrong USB phy type in mpc837xrdb dts
>
> Kim Phillips (2):
> [POWERPC] 83xx: enable usb in 837x rdb and 83xx defconfigs
> [POWERPC] sata_fsl: reduce compatibility to fsl,pq-sata
>
> Kumar Gala (2):
> [POWERPC] fsldma: Use compatiable binding as spec
> [POWERPC] Fix defconfigs so we dont set both GENRTC and RTCLIB
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: Virtex V5FX PPC 440 Support In Xilinx Git Tree
From: Grant Likely @ 2008-04-02 4:09 UTC (permalink / raw)
To: John Linn; +Cc: git, linuxppc-embedded
In-Reply-To: <20080401234142.41B13191804A@mail111-sin.bigfish.com>
On Tue, Apr 1, 2008 at 5:41 PM, John Linn <John.Linn@xilinx.com> wrote:
>
>
>
>
> I pushed PowerPC 440 support to the Xilinx Git server with support for ppc
> arch and with powerpc arch support coming in the near future.
Cool, I look forward to playing with it...
/me just needs to find a client who needs him to do V5 work. :-)
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: mpc52xx_mmap_ctl access
From: Grant Likely @ 2008-04-02 4:15 UTC (permalink / raw)
To: Marcelo Dalmas; +Cc: linuxppc-embedded
In-Reply-To: <132281.10315.qm@web50302.mail.re2.yahoo.com>
On Tue, Apr 1, 2008 at 11:03 AM, Marcelo Dalmas <m_dalmas@yahoo.com.br> wrote:
> Hi all!
>
> I'm updating a device driver from linux 2.6.16 ppc
> tree to linux 2.6.24 powerpc in a lite5200 based
> board.
>
> I need to access mpc52xx_mmap_ctl and mpc52xx_cslpc.
>
> In ppc tree I do:
>
> mmap_ctl =
> ioremap(MPC52xx_PA(MPC52xx_MMAP_CTL_OFFSET),
> MPC52xx_MMAP_CTL_SIZE)
>
> How can I access it in powerpc tree?
1) In your device tree, add a new node for the local plus bus control
registers with the correct base address.
2) Use of_find_compatible_node() to get a pointer to the node in your
platform init code.
3) Use of_iomap() to map the registers into the kernel address space.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: SecretLab Git Server
From: Grant Likely @ 2008-04-02 4:17 UTC (permalink / raw)
To: Sam Karp; +Cc: linuxppc-embedded
In-Reply-To: <800687fe0803311912w6da7e8d0i6567a824b7065bdf@mail.gmail.com>
On Mon, Mar 31, 2008 at 8:12 PM, Sam Karp <sam.d.karp@gmail.com> wrote:
> Any idea of other sources where else I could get either a kernel with the
> USB driver or a standalone driver for the Xilinx ML403 board?
Look on the powerpc mailing list archives for Peter Korsgaard's patch
set for the c67x00. (I believe v10 is the latest patch set).
You need to use the mailing list archive instead of patchwork. For
some reason patchwork doesn't recognize Peter's patches.
I'll try to get my git server up and running again ASAP.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Please pull powerpc.git merge branch
From: Grant Likely @ 2008-04-02 4:27 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, akpm, torvalds, linux-kernel
In-Reply-To: <18418.49494.457893.866627@cargo.ozlabs.ibm.com>
On Tue, Apr 1, 2008 at 5:12 PM, Paul Mackerras <paulus@samba.org> wrote:
> Bartlomiej Sieka writes:
>
> > What about http://patchwork.ozlabs.org/linuxppc/patch?id=17525 ? I don't
> > see it in the merge branch of your repository, and it would be nice to
> > get it upstream as it fixes boot problems on some MPC5200-based boards.
>
> It needs a proper stand-alone commit message and an acked-by from
> Grant. The commit message should explain why you are making the
> changes you are making rather than just saying "the bulk of this patch
> is taken from http://...".
Total Ack. I just missed it when it was sent. But Paul is right, it
needs a real commit message. Feel free to add my Acked-by: line when
you resend.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* RE: Access physical memory via mmap() on ppc440epx.
From: Leonid @ 2008-04-02 4:30 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-embedded
In-Reply-To: <1207100665.12155.100.camel@vader.jdub.homelinux.org>
Hi, Josh:
Thank you for your suggestion. Somehow it didn't work with mmap (may be,
my mistake, I'll double check), however it partially helped me with my
another problem.
I have kernel driver where I need read/write some HW device, connected
on address 0xea000000, chip select 4. This chip select configured
properly, here are EBC registers:
440EPx>rd ebc0_b4cr
ebc0_b4cr: 0xea01a000 -368992256
440EPx>rd ebc0_b4ap
ebc0_b4ap: 0x03037000 50556928
>From u-boot I can read/write this address with no problem (I use md/mw
commands).
In my driver I tried to ioremap() this address and any attempt to access
led to crash, same as with mmap().
When, following your suggestion, I used address 0x1ea00000 and
ioremap64(), crashes disappeared!
I even can write, but when I read data back I see least significant byte
of each 16 bits word only (bus is configured 16 bits width).=20
What can it be?
Thanks,
Leonid.=20
-----Original Message-----
From: Josh Boyer [mailto:jwboyer@gmail.com]=20
Sent: Tuesday, April 01, 2008 6:44 PM
To: Leonid
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Access physical memory via mmap() on ppc440epx.
On Tue, 2008-04-01 at 14:12 -0700, Leonid wrote:
> Hi:
>=20
> I am trying to read from NOR flash, located on address 0xfc000000, on
my
It's at 0x1fc000000 IIRC.
> TLB entries look strange though. That what it was on u-boot stage:
>=20
> 440EPx>tlb 0 10
> IDX TID EPN SIZE VTS RPN USER WIMGE USRSVC
> 0 : 00 40000000 256MB V0 -> 0_00000000 U:0000 -I-G- XWRXWR
> 1 : 00 00000000 256MB V0 -> 0_00000000 U:0000 -I-G- XWRXWR
> 2 : 00 c0000000 256MB V0 -> 1_c0000000 U:0000 -I-G- XWRXWR
> 3 : 00 f0000000 256MB V0 -> 1_f0000000 U:0000 WI-G- XWRXWR
See. Virtual is 0xf0000000, physical is 0x1f0000000.
> On Linux stage it looks rather different:
I don't even see your entry in here. Likely because the TLB is small
and it's gone by the time you do the dump
> Probably under MMU it should look this way? How to use mmap() then?
Try mmap64 on the real physical address and see if that helps.
josh
^ permalink raw reply
* [PATCH] [POWERPC] Fix iSeries hard irq enabling regression
From: Benjamin Herrenschmidt @ 2008-04-02 4:58 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
A subtle bug sneaked into iSeries recently. On this platform, we
must not normally clear MSR:EE unless it's for short periods of
time. Taking an interrupt while soft-disabled doesn't cause us to
clear it for example.
The iSeries kernel expects to mostly run with MSR:EE enabled at
all times except a few exception entry/exit code path. Thus
local_irq_enable() doesn't check if it needs to hard-enable as
it expects this to be unnecessary on iSeries.
However, hard_irq_disable() _does_ cause MSR:EE to be cleared,
including on iSeries. A call to it was recently added to the
context switch code, thus causing interrupts to become disabled
for a long period of time, causing the iSeries watchdog to kick
in under some circumstances and other nasty things.
This patch fixes it by making local_irq_enable() properly re-enable
MSR:EE on iSeries. It basically removes a return statement here
to make iSeries use the same code path as everybody else. That does
mean that we might occasionally get spurrious decrementer interrupts
but I don't think that matters.
Another option would have been to make hard_irq_disable() a nop
on iSeries but I didn't like it much, in case we have good reasons
to hard-disable.
Part of the patch is fixes to make sure the hard_enabled PACA field
is properly set on iSeries as it used not to be before, since it
was mostly unused.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
--
arch/powerpc/kernel/head_64.S | 13 +++++++------
arch/powerpc/kernel/irq.c | 1 -
2 files changed, 7 insertions(+), 7 deletions(-)
--- linux-work.orig/arch/powerpc/kernel/head_64.S 2008-04-02 15:47:20.000000000 +1100
+++ linux-work/arch/powerpc/kernel/head_64.S 2008-04-02 15:48:50.000000000 +1100
@@ -1387,12 +1387,14 @@ __secondary_start:
#ifdef CONFIG_PPC_ISERIES
BEGIN_FW_FTR_SECTION
ori r4,r4,MSR_EE
+ li r8,1
+ stb r8,PACAHARDIRQEN(r13)
END_FW_FTR_SECTION_IFSET(FW_FEATURE_ISERIES)
#endif
BEGIN_FW_FTR_SECTION
- stb r7,PACASOFTIRQEN(r13)
stb r7,PACAHARDIRQEN(r13)
END_FW_FTR_SECTION_IFCLR(FW_FEATURE_ISERIES)
+ stb r7,PACASOFTIRQEN(r13)
mtspr SPRN_SRR0,r3
mtspr SPRN_SRR1,r4
@@ -1520,15 +1522,14 @@ _INIT_GLOBAL(start_here_common)
#ifdef CONFIG_PPC_ISERIES
BEGIN_FW_FTR_SECTION
mfmsr r5
- ori r5,r5,MSR_EE /* Hard Enabled */
+ ori r5,r5,MSR_EE /* Hard Enabled on iSeries*/
mtmsrd r5
+ li r5,1
END_FW_FTR_SECTION_IFSET(FW_FEATURE_ISERIES)
#endif
-BEGIN_FW_FTR_SECTION
- stb r5,PACAHARDIRQEN(r13)
-END_FW_FTR_SECTION_IFCLR(FW_FEATURE_ISERIES)
+ stb r5,PACAHARDIRQEN(r13) /* Hard Disabled on others */
- bl .start_kernel
+ bl .start_kernel
/* Not reached */
BUG_OPCODE
Index: linux-work/arch/powerpc/kernel/irq.c
===================================================================
--- linux-work.orig/arch/powerpc/kernel/irq.c 2008-04-02 15:46:34.000000000 +1100
+++ linux-work/arch/powerpc/kernel/irq.c 2008-04-02 15:46:37.000000000 +1100
@@ -143,7 +143,6 @@ void local_irq_restore(unsigned long en)
*/
if (local_paca->lppaca_ptr->int_dword.any_int)
iseries_handle_interrupts();
- return;
}
/*
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH] Cell OProfile: SPU mutex lock fix
From: Arnd Bergmann @ 2008-04-02 5:21 UTC (permalink / raw)
To: cbe-oss-dev; +Cc: linuxppc-dev, cel, linux-kernel, Carl Love
In-Reply-To: <1206460727.7132.232.camel@carll-linux-desktop>
On Tuesday 25 March 2008, Carl Love wrote:
> This patch fixes a bug in the code that records the SPU data and
> context switches. The buffer_mutex lock must be held when the
> kernel is adding data to the buffer between the kernel and the
> OProfile daemon. The lock is not being held in the current code
> base. This patch fixes the bug using work queues. The data to
> be passed to the daemon is caputured by the interrupt handler.
> The workqueue function is invoked to grab the buffer_mutex lock
> and add the data to the buffer.
So what was the exact bug you're fixing with this? There was no
buffer_mutex before, so why do you need it now? Can't this be a
spinlock so you can get it from interrupt context instead of
using a workqueue?
> Index: linux-2.6.25-rc4/arch/powerpc/oprofile/cell/spu_profiler.c
> ===================================================================
> --- linux-2.6.25-rc4.orig/arch/powerpc/oprofile/cell/spu_profiler.c
> +++ linux-2.6.25-rc4/arch/powerpc/oprofile/cell/spu_profiler.c
> @@ -16,6 +16,7 @@
> #include <linux/smp.h>
> #include <linux/slab.h>
> #include <asm/cell-pmu.h>
> +#include <linux/workqueue.h>
> #include "pr_util.h"
>
Please keep #include statements in alphabetical order, with all linux/ files
before the asm/ files.
> #define TRACE_ARRAY_SIZE 1024
> @@ -32,9 +33,19 @@ static unsigned int profiling_interval;
>
> #define SPU_PC_MASK 0xFFFF
>
> +/* The generic OProfile code uses the buffer_mutex to protect the buffer
> + * between the kernel and the daemon. The SPU code needs to use the buffer
> + * to ensure that the kernel SPU writes complete as a single block before
> + * being consumed by the daemon.
> + */
> +extern struct mutex buffer_mutex;
> +
> static DEFINE_SPINLOCK(sample_array_lock);
> unsigned long sample_array_lock_flags;
>
> +struct work_struct spu_record_wq;
> +extern struct workqueue_struct *oprofile_spu_wq;
> +
> void set_spu_profiling_frequency(unsigned int freq_khz, unsigned int cycles_reset)
> {
> unsigned long ns_per_cyc;
Never put extern statements in the implementation, they describe the
interface between two parts of the code and should be inside of a
common header.
Why do you want to have your own workqueue instead of using the
global one?
> @@ -123,14 +134,14 @@ static int cell_spu_pc_collection(int cp
> return entry;
> }
>
> -
> -static enum hrtimer_restart profile_spus(struct hrtimer *timer)
> -{
> - ktime_t kt;
> +static void profile_spus_record_samples (struct work_struct *ws) {
> + /* This routine is called via schedule_work() to record the
> + * spu data. It must be run in a normal kernel mode to
> + * grab the OProfile mutex lock.
> + */
> int cpu, node, k, num_samples, spu_num;
>
> - if (!spu_prof_running)
> - goto stop;
> + mutex_lock(&buffer_mutex);
>
> for_each_online_cpu(cpu) {
> if (cbe_get_hw_thread_id(cpu))
> @@ -170,6 +181,20 @@ static enum hrtimer_restart profile_spus
> smp_wmb(); /* insure spu event buffer updates are written */
> /* don't want events intermingled... */
>
> + mutex_unlock(&buffer_mutex);
> +}
> +
> +static enum hrtimer_restart profile_spus(struct hrtimer *timer)
> +{
> + ktime_t kt;
> +
> +
> + if (!spu_prof_running)
> + goto stop;
> +
> + /* schedule the funtion to record the data */
> + schedule_work(&spu_record_wq);
> +
> kt = ktime_set(0, profiling_interval);
> if (!spu_prof_running)
> goto stop;
This looks like you want to use a delayed_work rather than building your
own out of hrtimer and work. Is there any point why you want to use
an hrtimer?
> -static DEFINE_SPINLOCK(buffer_lock);
> +extern struct mutex buffer_mutex;
> +extern struct workqueue_struct *oprofile_spu_wq;
> +extern int calls_to_record_switch;
> +
Again, public interfaces need to go to a header file, and should
have a name that identifies the interface. "buffer_mutex" is
certainly not a suitable name for a kernel-wide global variable!
> static DEFINE_SPINLOCK(cache_lock);
> static int num_spu_nodes;
> +
> int spu_prof_num_nodes;
> int last_guard_val[MAX_NUMNODES * 8];
> +int cnt_swtch_processed_flag[MAX_NUMNODES * 8];
> +
> +struct spus_profiling_code_data_s {
> + int num_spu_nodes;
> + struct work_struct spu_prof_code_wq;
> +} spus_profiling_code_data;
> +
> +struct spu_context_switch_data_s {
> + struct spu *spu;
> + unsigned long spu_cookie;
> + unsigned long app_dcookie;
> + unsigned int offset;
> + unsigned long objectId;
> + int valid_entry;
> +} spu_context_switch_data;
I don't understand what these variables are really doing, but
having e.g. just one spu_context_switch_data for all the SPUs
doesn't seem to make much sense. What happens when two SPUs do
a context switch at the same time?
> +int calls_to_record_switch = 0;
> +int record_spu_start_flag = 0;
> +
> +struct spus_cntxt_sw_data_s {
> + int num_spu_nodes;
> + struct spu_context_switch_data_s spu_data[MAX_NUMNODES * 8];
> + struct work_struct spu_cntxt_work;
> +} spus_cntxt_sw_data;
Something is very wrong if you need so many global variables!
> /* Container for caching information about an active SPU task. */
> struct cached_info {
> @@ -44,6 +73,8 @@ struct cached_info {
> struct kref cache_ref;
> };
>
> +struct workqueue_struct *oprofile_spu_wq;
> +
> static struct cached_info *spu_info[MAX_NUMNODES * 8];
While you're cleaning this up, I guess the cached_info should
be moved into a pointer from struct spu as well, instead of
having this global variable here.
> @@ -375,16 +457,30 @@ int spu_sync_start(void)
> int k;
> int ret = SKIP_GENERIC_SYNC;
> int register_ret;
> - unsigned long flags = 0;
>
> spu_prof_num_nodes = number_of_online_nodes();
> num_spu_nodes = spu_prof_num_nodes * 8;
>
> - spin_lock_irqsave(&buffer_lock, flags);
> - add_event_entry(ESCAPE_CODE);
> - add_event_entry(SPU_PROFILING_CODE);
> - add_event_entry(num_spu_nodes);
> - spin_unlock_irqrestore(&buffer_lock, flags);
> + /* create private work queue, execution of work is time critical */
> + oprofile_spu_wq = create_workqueue("spu_oprofile");
> +
> + /* due to a race when the spu is already running stuff, need to
> + * set a flag to tell the spu context switch to record the start
> + * before recording the context switches.
> + */
> + record_spu_start_flag = 1;
> +
> + spus_profiling_code_data.num_spu_nodes = num_spu_nodes;
> +
> + /* setup work queue functiion for recording context switch info */
> + spus_cntxt_sw_data.num_spu_nodes = num_spu_nodes;
> + for (k = 0; k<(MAX_NUMNODES * 8); k++) {
> + spus_cntxt_sw_data.spu_data[k].valid_entry = 0;
> + cnt_swtch_processed_flag[k] = 0;
> + }
> +
> + INIT_WORK(&spus_cntxt_sw_data.spu_cntxt_work,
> + record_spu_process_switch);
I would guess that you need one work struct per SPU instead of a global
one, if you want to pass the SPU pointer as an argument.
Arnd <><
^ permalink raw reply
* [BUG] 2.6.25-rc8-mm1 kernel panic while bootup on powerpc
From: Kamalesh Babulal @ 2008-04-02 6:25 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, Balbir Singh, linux-kernel
In-Reply-To: <20080401213214.8fbb6d6b.akpm@linux-foundation.org>
Hi Andrew,
The 2.6.25-rc8-mm1 kernel panic's while bootup on the power machine(s).
[ 0.000000] ------------[ cut here ]------------
[ 0.000000] kernel BUG at arch/powerpc/mm/init_64.c:240!
[ 0.000000] Oops: Exception in kernel mode, sig: 5 [#1]
[ 0.000000] SMP NR_CPUS=32 NUMA PowerMac
[ 0.000000] Modules linked in:
[ 0.000000] NIP: c0000000003d1dcc LR: c0000000003d1dc4 CTR: c00000000002b6ac
[ 0.000000] REGS: c00000000049b960 TRAP: 0700 Not tainted (2.6.25-rc8-mm1-autokern1)
[ 0.000000] MSR: 9000000000021032 <ME,IR,DR> CR: 44000088 XER: 20000000
[ 0.000000] TASK = c0000000003f9c90[0] 'swapper' THREAD: c000000000498000 CPU: 0
[ 0.000000] GPR00: c0000000003d1dc4 c00000000049bbe0 c0000000004989d0 0000000000000001
[ 0.000000] GPR04: d59aca40f0000000 000000000b000000 0000000000000010 0000000000000000
[ 0.000000] GPR08: 0000000000000004 0000000000000001 c00000027e520800 c0000000004bf0f0
[ 0.000000] GPR12: c0000000004bf020 c0000000003fa900 0000000000000000 0000000000000000
[ 0.000000] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 0.000000] GPR20: 0000000000000000 0000000000000000 0000000000000000 4000000001400000
[ 0.000000] GPR24: 00000000017d64b0 c0000000003d6250 0000000000000000 c000000000504000
[ 0.000000] GPR28: 0000000000000000 cf000000001f8000 0000000001000000 cf00000000000000
[ 0.000000] NIP [c0000000003d1dcc] .vmemmap_populate+0xb8/0xf4
[ 0.000000] LR [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4
[ 0.000000] Call Trace:
[ 0.000000] [c00000000049bbe0] [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4 (unreliable)
[ 0.000000] [c00000000049bc70] [c0000000003d2ee8] .sparse_mem_map_populate+0x38/0x60
[ 0.000000] [c00000000049bd00] [c0000000003c242c] .sparse_early_mem_map_alloc+0x54/0x94
[ 0.000000] [c00000000049bd90] [c0000000003c250c] .sparse_init+0xa0/0x20c
[ 0.000000] [c00000000049be50] [c0000000003ab7d0] .setup_arch+0x1ac/0x218
[ 0.000000] [c00000000049bee0] [c0000000003a36ac] .start_kernel+0xe0/0x3fc
[ 0.000000] [c00000000049bf90] [c000000000008594] .start_here_common+0x54/0xc0
[ 0.000000] Instruction dump:
[ 0.000000] 7fe3fb78 7ca02a14 4082000c 3860fff4 4800003c e92289c8 e96289c0 e9090002
[ 0.000000] e8eb0002 4bc575cd 60000000 78630fe0 <0b030000> 7ffff214 7fbfe840 7fe3fb78
[ 0.000000] ---[ end trace 31fd0ba7d8756001 ]---
[ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: [BUG] 2.6.25-rc8-mm1 kernel panic while bootup on powerpc
From: Andrew Morton @ 2008-04-02 6:39 UTC (permalink / raw)
To: Kamalesh Babulal
Cc: Badari, linux-kernel, linuxppc-dev, Pulavarty, Balbir Singh
In-Reply-To: <47F326E0.3010604@linux.vnet.ibm.com>
On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> Hi Andrew,
>
> The 2.6.25-rc8-mm1 kernel panic's while bootup on the power machine(s).
>
> [ 0.000000] ------------[ cut here ]------------
> [ 0.000000] kernel BUG at arch/powerpc/mm/init_64.c:240!
> [ 0.000000] Oops: Exception in kernel mode, sig: 5 [#1]
> [ 0.000000] SMP NR_CPUS=32 NUMA PowerMac
> [ 0.000000] Modules linked in:
> [ 0.000000] NIP: c0000000003d1dcc LR: c0000000003d1dc4 CTR: c00000000002b6ac
> [ 0.000000] REGS: c00000000049b960 TRAP: 0700 Not tainted (2.6.25-rc8-mm1-autokern1)
> [ 0.000000] MSR: 9000000000021032 <ME,IR,DR> CR: 44000088 XER: 20000000
> [ 0.000000] TASK = c0000000003f9c90[0] 'swapper' THREAD: c000000000498000 CPU: 0
> [ 0.000000] GPR00: c0000000003d1dc4 c00000000049bbe0 c0000000004989d0 0000000000000001
> [ 0.000000] GPR04: d59aca40f0000000 000000000b000000 0000000000000010 0000000000000000
> [ 0.000000] GPR08: 0000000000000004 0000000000000001 c00000027e520800 c0000000004bf0f0
> [ 0.000000] GPR12: c0000000004bf020 c0000000003fa900 0000000000000000 0000000000000000
> [ 0.000000] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> [ 0.000000] GPR20: 0000000000000000 0000000000000000 0000000000000000 4000000001400000
> [ 0.000000] GPR24: 00000000017d64b0 c0000000003d6250 0000000000000000 c000000000504000
> [ 0.000000] GPR28: 0000000000000000 cf000000001f8000 0000000001000000 cf00000000000000
> [ 0.000000] NIP [c0000000003d1dcc] .vmemmap_populate+0xb8/0xf4
> [ 0.000000] LR [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4
> [ 0.000000] Call Trace:
> [ 0.000000] [c00000000049bbe0] [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4 (unreliable)
> [ 0.000000] [c00000000049bc70] [c0000000003d2ee8] .sparse_mem_map_populate+0x38/0x60
> [ 0.000000] [c00000000049bd00] [c0000000003c242c] .sparse_early_mem_map_alloc+0x54/0x94
> [ 0.000000] [c00000000049bd90] [c0000000003c250c] .sparse_init+0xa0/0x20c
> [ 0.000000] [c00000000049be50] [c0000000003ab7d0] .setup_arch+0x1ac/0x218
> [ 0.000000] [c00000000049bee0] [c0000000003a36ac] .start_kernel+0xe0/0x3fc
> [ 0.000000] [c00000000049bf90] [c000000000008594] .start_here_common+0x54/0xc0
> [ 0.000000] Instruction dump:
> [ 0.000000] 7fe3fb78 7ca02a14 4082000c 3860fff4 4800003c e92289c8 e96289c0 e9090002
> [ 0.000000] e8eb0002 4bc575cd 60000000 78630fe0 <0b030000> 7ffff214 7fbfe840 7fe3fb78
> [ 0.000000] ---[ end trace 31fd0ba7d8756001 ]---
> [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
>
int __meminit vmemmap_populate(struct page *start_page,
unsigned long nr_pages, int node)
{
unsigned long mode_rw;
unsigned long start = (unsigned long)start_page;
unsigned long end = (unsigned long)(start_page + nr_pages);
unsigned long page_size = 1 << mmu_psize_defs[mmu_linear_psize].shift;
mode_rw = _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | PP_RWXX;
/* Align to the page size of the linear mapping. */
start = _ALIGN_DOWN(start, page_size);
for (; start < end; start += page_size) {
int mapped;
void *p;
if (vmemmap_populated(start, page_size))
continue;
p = vmemmap_alloc_block(page_size, node);
if (!p)
return -ENOMEM;
pr_debug("vmemmap %08lx allocated at %p, physical %08lx.\n",
start, p, __pa(p));
mapped = htab_bolt_mapping(start, start + page_size,
__pa(p), mode_rw, mmu_linear_psize,
mmu_kernel_ssize);
=====> BUG_ON(mapped < 0);
}
return 0;
}
Beats me. pseries? Badari has been diddling with the bolted memory code
in git-powerpc...
^ permalink raw reply
* Re: [BUG] 2.6.25-rc8-mm1 kernel panic while bootup on powerpc
From: Kamalesh Babulal @ 2008-04-02 7:08 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, Balbir Singh, Badari Pulavarty, linux-kernel
In-Reply-To: <20080401233909.23220623.akpm@linux-foundation.org>
Andrew Morton wrote:
> On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
>
>> Hi Andrew,
>>
>> The 2.6.25-rc8-mm1 kernel panic's while bootup on the power machine(s).
>>
>> [ 0.000000] ------------[ cut here ]------------
>> [ 0.000000] kernel BUG at arch/powerpc/mm/init_64.c:240!
>> [ 0.000000] Oops: Exception in kernel mode, sig: 5 [#1]
>> [ 0.000000] SMP NR_CPUS=32 NUMA PowerMac
>> [ 0.000000] Modules linked in:
>> [ 0.000000] NIP: c0000000003d1dcc LR: c0000000003d1dc4 CTR: c00000000002b6ac
>> [ 0.000000] REGS: c00000000049b960 TRAP: 0700 Not tainted (2.6.25-rc8-mm1-autokern1)
>> [ 0.000000] MSR: 9000000000021032 <ME,IR,DR> CR: 44000088 XER: 20000000
>> [ 0.000000] TASK = c0000000003f9c90[0] 'swapper' THREAD: c000000000498000 CPU: 0
>> [ 0.000000] GPR00: c0000000003d1dc4 c00000000049bbe0 c0000000004989d0 0000000000000001
>> [ 0.000000] GPR04: d59aca40f0000000 000000000b000000 0000000000000010 0000000000000000
>> [ 0.000000] GPR08: 0000000000000004 0000000000000001 c00000027e520800 c0000000004bf0f0
>> [ 0.000000] GPR12: c0000000004bf020 c0000000003fa900 0000000000000000 0000000000000000
>> [ 0.000000] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>> [ 0.000000] GPR20: 0000000000000000 0000000000000000 0000000000000000 4000000001400000
>> [ 0.000000] GPR24: 00000000017d64b0 c0000000003d6250 0000000000000000 c000000000504000
>> [ 0.000000] GPR28: 0000000000000000 cf000000001f8000 0000000001000000 cf00000000000000
>> [ 0.000000] NIP [c0000000003d1dcc] .vmemmap_populate+0xb8/0xf4
>> [ 0.000000] LR [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4
>> [ 0.000000] Call Trace:
>> [ 0.000000] [c00000000049bbe0] [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4 (unreliable)
>> [ 0.000000] [c00000000049bc70] [c0000000003d2ee8] .sparse_mem_map_populate+0x38/0x60
>> [ 0.000000] [c00000000049bd00] [c0000000003c242c] .sparse_early_mem_map_alloc+0x54/0x94
>> [ 0.000000] [c00000000049bd90] [c0000000003c250c] .sparse_init+0xa0/0x20c
>> [ 0.000000] [c00000000049be50] [c0000000003ab7d0] .setup_arch+0x1ac/0x218
>> [ 0.000000] [c00000000049bee0] [c0000000003a36ac] .start_kernel+0xe0/0x3fc
>> [ 0.000000] [c00000000049bf90] [c000000000008594] .start_here_common+0x54/0xc0
>> [ 0.000000] Instruction dump:
>> [ 0.000000] 7fe3fb78 7ca02a14 4082000c 3860fff4 4800003c e92289c8 e96289c0 e9090002
>> [ 0.000000] e8eb0002 4bc575cd 60000000 78630fe0 <0b030000> 7ffff214 7fbfe840 7fe3fb78
>> [ 0.000000] ---[ end trace 31fd0ba7d8756001 ]---
>> [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
>>
>
> int __meminit vmemmap_populate(struct page *start_page,
> unsigned long nr_pages, int node)
> {
> unsigned long mode_rw;
> unsigned long start = (unsigned long)start_page;
> unsigned long end = (unsigned long)(start_page + nr_pages);
> unsigned long page_size = 1 << mmu_psize_defs[mmu_linear_psize].shift;
>
> mode_rw = _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | PP_RWXX;
>
> /* Align to the page size of the linear mapping. */
> start = _ALIGN_DOWN(start, page_size);
>
> for (; start < end; start += page_size) {
> int mapped;
> void *p;
>
> if (vmemmap_populated(start, page_size))
> continue;
>
> p = vmemmap_alloc_block(page_size, node);
> if (!p)
> return -ENOMEM;
>
> pr_debug("vmemmap %08lx allocated at %p, physical %08lx.\n",
> start, p, __pa(p));
>
> mapped = htab_bolt_mapping(start, start + page_size,
> __pa(p), mode_rw, mmu_linear_psize,
> mmu_kernel_ssize);
> =====> BUG_ON(mapped < 0);
> }
>
> return 0;
> }
>
> Beats me. pseries? Badari has been diddling with the bolted memory code
> in git-powerpc...
One of the machines is the Power5 and another is PowerMac G5, on which the
same kernel panic is seen.
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: [BUG] 2.6.25-rc8-mm1 kernel panic while bootup on powerpc
From: Michael Ellerman @ 2008-04-02 7:17 UTC (permalink / raw)
To: Kamalesh Babulal
Cc: linuxppc-dev, Andrew Morton, Badari Pulavarty, linux-kernel,
Balbir Singh
In-Reply-To: <47F330FF.3050806@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 4590 bytes --]
On Wed, 2008-04-02 at 12:38 +0530, Kamalesh Babulal wrote:
> Andrew Morton wrote:
> > On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> >
> >> Hi Andrew,
> >>
> >> The 2.6.25-rc8-mm1 kernel panic's while bootup on the power machine(s).
> >>
> >> [ 0.000000] ------------[ cut here ]------------
> >> [ 0.000000] kernel BUG at arch/powerpc/mm/init_64.c:240!
> >> [ 0.000000] Oops: Exception in kernel mode, sig: 5 [#1]
> >> [ 0.000000] SMP NR_CPUS=32 NUMA PowerMac
> >> [ 0.000000] Modules linked in:
> >> [ 0.000000] NIP: c0000000003d1dcc LR: c0000000003d1dc4 CTR: c00000000002b6ac
> >> [ 0.000000] REGS: c00000000049b960 TRAP: 0700 Not tainted (2.6.25-rc8-mm1-autokern1)
> >> [ 0.000000] MSR: 9000000000021032 <ME,IR,DR> CR: 44000088 XER: 20000000
> >> [ 0.000000] TASK = c0000000003f9c90[0] 'swapper' THREAD: c000000000498000 CPU: 0
> >> [ 0.000000] GPR00: c0000000003d1dc4 c00000000049bbe0 c0000000004989d0 0000000000000001
> >> [ 0.000000] GPR04: d59aca40f0000000 000000000b000000 0000000000000010 0000000000000000
> >> [ 0.000000] GPR08: 0000000000000004 0000000000000001 c00000027e520800 c0000000004bf0f0
> >> [ 0.000000] GPR12: c0000000004bf020 c0000000003fa900 0000000000000000 0000000000000000
> >> [ 0.000000] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> >> [ 0.000000] GPR20: 0000000000000000 0000000000000000 0000000000000000 4000000001400000
> >> [ 0.000000] GPR24: 00000000017d64b0 c0000000003d6250 0000000000000000 c000000000504000
> >> [ 0.000000] GPR28: 0000000000000000 cf000000001f8000 0000000001000000 cf00000000000000
> >> [ 0.000000] NIP [c0000000003d1dcc] .vmemmap_populate+0xb8/0xf4
> >> [ 0.000000] LR [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4
> >> [ 0.000000] Call Trace:
> >> [ 0.000000] [c00000000049bbe0] [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4 (unreliable)
> >> [ 0.000000] [c00000000049bc70] [c0000000003d2ee8] .sparse_mem_map_populate+0x38/0x60
> >> [ 0.000000] [c00000000049bd00] [c0000000003c242c] .sparse_early_mem_map_alloc+0x54/0x94
> >> [ 0.000000] [c00000000049bd90] [c0000000003c250c] .sparse_init+0xa0/0x20c
> >> [ 0.000000] [c00000000049be50] [c0000000003ab7d0] .setup_arch+0x1ac/0x218
> >> [ 0.000000] [c00000000049bee0] [c0000000003a36ac] .start_kernel+0xe0/0x3fc
> >> [ 0.000000] [c00000000049bf90] [c000000000008594] .start_here_common+0x54/0xc0
> >> [ 0.000000] Instruction dump:
> >> [ 0.000000] 7fe3fb78 7ca02a14 4082000c 3860fff4 4800003c e92289c8 e96289c0 e9090002
> >> [ 0.000000] e8eb0002 4bc575cd 60000000 78630fe0 <0b030000> 7ffff214 7fbfe840 7fe3fb78
> >> [ 0.000000] ---[ end trace 31fd0ba7d8756001 ]---
> >> [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
> >>
> >
> > int __meminit vmemmap_populate(struct page *start_page,
> > unsigned long nr_pages, int node)
> > {
> > unsigned long mode_rw;
> > unsigned long start = (unsigned long)start_page;
> > unsigned long end = (unsigned long)(start_page + nr_pages);
> > unsigned long page_size = 1 << mmu_psize_defs[mmu_linear_psize].shift;
> >
> > mode_rw = _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | PP_RWXX;
> >
> > /* Align to the page size of the linear mapping. */
> > start = _ALIGN_DOWN(start, page_size);
> >
> > for (; start < end; start += page_size) {
> > int mapped;
> > void *p;
> >
> > if (vmemmap_populated(start, page_size))
> > continue;
> >
> > p = vmemmap_alloc_block(page_size, node);
> > if (!p)
> > return -ENOMEM;
> >
> > pr_debug("vmemmap %08lx allocated at %p, physical %08lx.\n",
> > start, p, __pa(p));
> >
> > mapped = htab_bolt_mapping(start, start + page_size,
> > __pa(p), mode_rw, mmu_linear_psize,
> > mmu_kernel_ssize);
> > =====> BUG_ON(mapped < 0);
> > }
> >
> > return 0;
> > }
> >
> > Beats me. pseries? Badari has been diddling with the bolted memory code
> > in git-powerpc...
>
> One of the machines is the Power5 and another is PowerMac G5, on which the
> same kernel panic is seen.
Can you enable DEBUG_LOW in arch/powerpc/platforms/pseries/lpar.c, that
should show what's happening in hpte_insert().
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Xilinx LLTEMAC driver issues
From: Johann Baudy @ 2008-04-02 7:20 UTC (permalink / raw)
To: Magnus Hjorth; +Cc: linuxppc-embedded, John Linn, git
In-Reply-To: <000601c8931f$e1d549a0$a57fdce0$@se>
[-- Attachment #1: Type: text/plain, Size: 31267 bytes --]
I've solved this checksum offloading issue with this below patch.
It may help, if you need performance. It certainly needs review but it works
on my side.
--- xilinxgit/drivers/net/xilinx_lltemac/xlltemac_main.c.orig 2008-03-21
09:11:43.000000000 +0100
+++ xilinxgit/drivers/net/xilinx_lltemac/xlltemac_main.c 2008-03-21
09:24:23.000000000 +0100
@@ -133,7 +133,7 @@
(XLlDma_mBdRead((BdPtr), XLLDMA_BD_STSCTRL_USR0_OFFSET)) &
0xFFFFFFFE )
#define BdCsumSetup(BdPtr, Start, Insert) \
- XLlDma_mBdWrite((BdPtr), XLLDMA_BD_USR1_OFFSET, (Start) << 16 |
(Insert))
+ XLlDma_mBdWrite((BdPtr), XLLDMA_BD_USR1_OFFSET, ((Start) << 16) |
(Insert))
/* Used for debugging */
#define BdCsumInsert(BdPtr) \
@@ -1540,7 +1541,7 @@ static int xenet_DmaSend_internal(struct
/*
* if tx checksum offloading is enabled, when the ethernet stack
* wants us to perform the checksum in hardware,
- * skb->ip_summed is CHECKSUM_COMPLETE. Otherwise skb->ip_summed is
+ * skb->ip_summed is CHECKSUM_PARTIAL. Otherwise skb->ip_summed is
* CHECKSUM_NONE, meaning the checksum is already done, or
* CHECKSUM_UNNECESSARY, meaning checksumming is turned off (e.g.
* loopback interface)
@@ -1565,9 +1566,11 @@ static int xenet_DmaSend_internal(struct
* skb_transport_header(skb) points to the beginning of the ip header
*
*/
- if (skb->ip_summed == CHECKSUM_COMPLETE) {
+ if (skb->ip_summed == CHECKSUM_PARTIAL) {
+
+ unsigned int csum_start_off = skb_transport_offset(skb);
+ unsigned int csum_index_off = csum_start_off + skb->csum_offset;
- unsigned char *raw = skb_transport_header(skb);
#if 0
{
unsigned int csum = _xenet_tx_csum(skb);
@@ -1578,9 +1581,8 @@ static int xenet_DmaSend_internal(struct
}
#else
BdCsumEnable(bd_ptr);
- BdCsumSetup(bd_ptr, raw - skb->data,
- (raw - skb->data) + skb->csum);
-
+ BdCsumSetup(bd_ptr, csum_start_off,
+ csum_index_off);
#endif
lp->tx_hw_csums++;
}
@@ -3277,7 +3279,7 @@ static int __devinit xtenet_of_probe(str
struct resource *r_irq = &r_irq_struct; /* Interrupt resources */
struct resource *r_mem = &r_mem_struct; /* IO mem resources */
struct xlltemac_platform_data *pdata = &pdata_struct;
- void *mac_address;
+ const void *mac_address;
int rc = 0;
const phandle *llink_connected_handle;
struct device_node *llink_connected_node;
On Mon, Mar 31, 2008 at 11:10 AM, Magnus Hjorth <mh@omnisys.se> wrote:
> Deactivating checksum offloading helped a lot! I still have some packet
> loss and not the best performance (TFTP transfer about 100 kbyte/s) but at
> least it works.
>
> Thanks!
>
> //Magnus
>
> > -----Original Message-----
> > From: rza1 [mailto:rza1@so-logic.net]
> > Sent: den 31 mars 2008 11:14
> > To: Magnus Hjorth
> > Cc: John Linn; git; linuxppc-embedded@ozlabs.org
> > Subject: Re: Xilinx LLTEMAC driver issues
> >
> > Hi Magnus,
> >
> > 1.
> > I am using nearly the same versions then you and got the same problems
> > too ;-).
> > I think there are some problems with the checksum offloading.
> > Try to sniff the some packages (e.g. wireshark)...
> > For me ICMP (ping) worked but udp and tcp not (because off a wrong
> > checksum in the transport layer).
> > A quick solution is to just deactivate checksum offloading.
> >
> > 2.
> > I remember some problems with Virtex-4 presamples too.
> > There where problems with the hard-temac wrapper. You had to use 1.00.a
> > and not b version.
> > But I don't have these problems with the EDK 9.2sp2/ISE9.2sp3 anymore.
> >
> > all the best,
> > Robert
> >
> > Magnus Hjorth wrote:
> > > Hi John,
> > >
> > > Thanks for the very fast reply! Right now I'm not at work so I don't
> > > have the board or EDK here to test anything.
> > >
> > > I'm using checksum offload, but I don't know if DRE is enabled or not.
> I
> > > can't recall seeing any setting to enable/disable DRE..
> > >
> > > A few things that crossed my mind:
> > >
> > > Last year I did a design with EDK 8.2, back then there was an issue
> with
> > > the ML403 boards having an old revision of the FPGA which wasn't
> > > compatible with some versions of the IP core. There are no such
> version
> > > issues with the xps_ll_temac?
> > >
> > > I don't think that I had phy-addr set in the DTS file. Will test that
> on
> > > Monday.
> > >
> > > Best regards,
> > > Magnus
> > >
> > >
> > > On Sat, 2008-03-29 at 07:58 -0600, John Linn wrote:
> > >
> > >> Hi Magnus,
> > >>
> > >> Sorry to hear you're having problems with it.
> > >>
> > >> I am doing testing on an ML405 which is the same board but with a
> bigger
> > FPGA, but with ppc arch and I don't see this issue. I have done limited
> testing
> > with powerpc arch and the LL TEMAC, but I didn't see this issue there
> either.
> > Powerpc arch is definitely less mature in my experience than the ppc
> arch. I'll
> > do a quick test with my powerpc arch and make sure again I'm not seeing
> it.
> > >>
> > >> My kernel is from the Xilinx Git tree, but there have been a number
> of
> > changes we have pushed out so I don't know how long ago you pulled from
> the Git
> > tree.
> > >>
> > >> My EDK project is 10.1 so it's a little newer. I am using LL TEMAC
> 1.01a so
> > it's a little newer. I reviewed the change log for the LL TEMAC and
> don't see
> > any big problems that were fixed in the newer versions, more new
> features. I'll
> > check with some others here to see if I missed something there.
> > >>
> > >> I am using DMA also, but no DRE or checksum offload. You didn't say
> anything
> > about those. I'm going to insert my mhs file that describes my system to
> let you
> > compare your system configuration. It's not clear to me yet if you have
> a h/w or
> > s/w problem.
> > >>
> > >> I'll also insert some of my device tree with the LL TEMAC so you can
> compare
> > (ignore 16550 stuff as we are still working on that).
> > >>
> > >> Since you can't ping reliably I would probably focus on that since
> it's
> > simpler than the other issues you're seeing.
> > >>
> > >> Thanks,
> > >> John
> > >>
> > >>
> > >>
> > >> #
> >
> ##############################################################################
> > >> # Created by Base System Builder Wizard for Xilinx EDK 10.1.1 Build
> > EDK_K_SP1.1
> > >> # Thu Feb 14 14:11:12 2008
> > >> # Target Board: Xilinx Virtex 4 ML405 Evaluation Platform Rev 1
> > >> # Family: virtex4
> > >> # Device: xc4vfx20
> > >> # Package: ff672
> > >> # Speed Grade: -10
> > >> # Processor: ppc405_0
> > >> # Processor clock frequency: 300.00 MHz
> > >> # Bus clock frequency: 100.00 MHz
> > >> # On Chip Memory : 8 KB
> > >> # Total Off Chip Memory : 128 MB
> > >> # - DDR_SDRAM = 128 MB
> > >> #
> >
> ##############################################################################
> > >> PARAMETER VERSION = 2.1.0
> > >>
> > >>
> > >> PORT fpga_0_RS232_Uart_sin_pin = fpga_0_RS232_Uart_sin, DIR = I
> > >> PORT fpga_0_RS232_Uart_sout_pin = fpga_0_RS232_Uart_sout, DIR = O
> > >> PORT fpga_0_LEDs_4Bit_GPIO_IO_pin = fpga_0_LEDs_4Bit_GPIO_IO, DIR =
> IO, VEC
> > = [0:3]
> > >> PORT fpga_0_IIC_EEPROM_Scl_pin = fpga_0_IIC_EEPROM_Scl, DIR = IO
> > >> PORT fpga_0_IIC_EEPROM_Sda_pin = fpga_0_IIC_EEPROM_Sda, DIR = IO
> > >> PORT fpga_0_SysACE_CompactFlash_SysACE_CLK_pin =
> > fpga_0_SysACE_CompactFlash_SysACE_CLK, DIR = I
> > >> PORT fpga_0_SysACE_CompactFlash_SysACE_MPA_pin =
> > fpga_0_SysACE_CompactFlash_SysACE_MPA, DIR = O, VEC = [6:1]
> > >> PORT fpga_0_SysACE_CompactFlash_SysACE_MPD_pin =
> > fpga_0_SysACE_CompactFlash_SysACE_MPD, DIR = IO, VEC = [15:0]
> > >> PORT fpga_0_SysACE_CompactFlash_SysACE_CEN_pin =
> > fpga_0_SysACE_CompactFlash_SysACE_CEN, DIR = O
> > >> PORT fpga_0_SysACE_CompactFlash_SysACE_OEN_pin =
> > fpga_0_SysACE_CompactFlash_SysACE_OEN, DIR = O
> > >> PORT fpga_0_SysACE_CompactFlash_SysACE_WEN_pin =
> > fpga_0_SysACE_CompactFlash_SysACE_WEN, DIR = O
> > >> PORT fpga_0_SysACE_CompactFlash_SysACE_MPIRQ_pin =
> > fpga_0_SysACE_CompactFlash_SysACE_MPIRQ, DIR = I
> > >> PORT fpga_0_DDR_SDRAM_DDR_Clk_pin = fpga_0_DDR_SDRAM_DDR_Clk, DIR =
> O
> > >> PORT fpga_0_DDR_SDRAM_DDR_Clk_n_pin = fpga_0_DDR_SDRAM_DDR_Clk_n,
> DIR = O
> > >> PORT fpga_0_DDR_SDRAM_DDR_Addr_pin = fpga_0_DDR_SDRAM_DDR_Addr, DIR
> = O, VEC
> > = [12:0]
> > >> PORT fpga_0_DDR_SDRAM_DDR_BankAddr_pin =
> fpga_0_DDR_SDRAM_DDR_BankAddr, DIR
> > = O, VEC = [1:0]
> > >> PORT fpga_0_DDR_SDRAM_DDR_CAS_n_pin = fpga_0_DDR_SDRAM_DDR_CAS_n,
> DIR = O
> > >> PORT fpga_0_DDR_SDRAM_DDR_CE_pin = fpga_0_DDR_SDRAM_DDR_CE, DIR = O
> > >> PORT fpga_0_DDR_SDRAM_DDR_CS_n_pin = fpga_0_DDR_SDRAM_DDR_CS_n, DIR
> = O
> > >> PORT fpga_0_DDR_SDRAM_DDR_RAS_n_pin = fpga_0_DDR_SDRAM_DDR_RAS_n,
> DIR = O
> > >> PORT fpga_0_DDR_SDRAM_DDR_WE_n_pin = fpga_0_DDR_SDRAM_DDR_WE_n, DIR
> = O
> > >> PORT fpga_0_DDR_SDRAM_DDR_DM_pin = fpga_0_DDR_SDRAM_DDR_DM, DIR = O,
> VEC =
> > [3:0]
> > >> PORT fpga_0_DDR_SDRAM_DDR_DQS = fpga_0_DDR_SDRAM_DDR_DQS, DIR = IO,
> VEC =
> > [3:0]
> > >> PORT fpga_0_DDR_SDRAM_DDR_DQ = fpga_0_DDR_SDRAM_DDR_DQ, DIR = IO,
> VEC =
> > [31:0]
> > >> PORT fpga_0_TriMode_MAC_GMII_GMII_TXD_0_pin =
> > fpga_0_TriMode_MAC_GMII_GMII_TXD_0, DIR = O, VEC = [7:0]
> > >> PORT fpga_0_TriMode_MAC_GMII_GMII_TX_EN_0_pin =
> > fpga_0_TriMode_MAC_GMII_GMII_TX_EN_0, DIR = O
> > >> PORT fpga_0_TriMode_MAC_GMII_GMII_TX_ER_0_pin =
> > fpga_0_TriMode_MAC_GMII_GMII_TX_ER_0, DIR = O
> > >> PORT fpga_0_TriMode_MAC_GMII_GMII_TX_CLK_0_pin =
> > fpga_0_TriMode_MAC_GMII_GMII_TX_CLK_0, DIR = O
> > >> PORT fpga_0_TriMode_MAC_GMII_GMII_RXD_0_pin =
> > fpga_0_TriMode_MAC_GMII_GMII_RXD_0, DIR = I, VEC = [7:0]
> > >> PORT fpga_0_TriMode_MAC_GMII_GMII_RX_DV_0_pin =
> > fpga_0_TriMode_MAC_GMII_GMII_RX_DV_0, DIR = I
> > >> PORT fpga_0_TriMode_MAC_GMII_GMII_RX_ER_0_pin =
> > fpga_0_TriMode_MAC_GMII_GMII_RX_ER_0, DIR = I
> > >> PORT fpga_0_TriMode_MAC_GMII_GMII_RX_CLK_0_pin =
> > fpga_0_TriMode_MAC_GMII_GMII_RX_CLK_0, DIR = I
> > >> PORT fpga_0_TriMode_MAC_GMII_MII_TX_CLK_0_pin =
> > fpga_0_TriMode_MAC_GMII_MII_TX_CLK_0, DIR = I
> > >> PORT fpga_0_TriMode_MAC_GMII_MDIO_0_pin =
> fpga_0_TriMode_MAC_GMII_MDIO_0,
> > DIR = IO
> > >> PORT fpga_0_TriMode_MAC_GMII_MDC_0_pin =
> fpga_0_TriMode_MAC_GMII_MDC_0, DIR
> > = O
> > >> PORT fpga_0_TriMode_MAC_GMII_TemacPhy_RST_n_pin =
> > fpga_0_TriMode_MAC_GMII_TemacPhy_RST_n, DIR = O
> > >> PORT sys_clk_pin = dcm_clk_s, DIR = I, SIGIS = CLK, CLK_FREQ =
> 100000000
> > >> PORT sys_rst_pin = sys_rst_s, DIR = I, RST_POLARITY = 0, SIGIS = RST
> > >>
> > >>
> > >> BEGIN ppc405_virtex4
> > >> PARAMETER INSTANCE = ppc405_0
> > >> PARAMETER HW_VER = 2.01.a
> > >> PARAMETER C_FASTEST_PLB_CLOCK = DPLB1
> > >> PARAMETER C_IDCR_BASEADDR = 0b0100000000
> > >> PARAMETER C_IDCR_HIGHADDR = 0b0111111111
> > >> BUS_INTERFACE JTAGPPC = jtagppc_0_0
> > >> BUS_INTERFACE IPLB0 = plb
> > >> BUS_INTERFACE DPLB0 = plb
> > >> BUS_INTERFACE IPLB1 = ppc405_0_iplb1
> > >> BUS_INTERFACE DPLB1 = ppc405_0_dplb1
> > >> BUS_INTERFACE RESETPPC = ppc_reset_bus
> > >> PORT CPMC405CLOCK = proc_clk_s
> > >> PORT EICC405EXTINPUTIRQ = EICC405EXTINPUTIRQ
> > >> END
> > >>
> > >> BEGIN jtagppc_cntlr
> > >> PARAMETER INSTANCE = jtagppc_0
> > >> PARAMETER HW_VER = 2.01.a
> > >> BUS_INTERFACE JTAGPPC0 = jtagppc_0_0
> > >> END
> > >>
> > >> BEGIN plb_v46
> > >> PARAMETER INSTANCE = plb
> > >> PARAMETER C_DCR_INTFCE = 0
> > >> PARAMETER C_NUM_CLK_PLB2OPB_REARB = 100
> > >> PARAMETER HW_VER = 1.02.a
> > >> PORT PLB_Clk = sys_clk_s
> > >> PORT SYS_Rst = sys_bus_reset
> > >> END
> > >>
> > >> BEGIN xps_bram_if_cntlr
> > >> PARAMETER INSTANCE = xps_bram_if_cntlr_1
> > >> PARAMETER HW_VER = 1.00.a
> > >> PARAMETER C_SPLB_NATIVE_DWIDTH = 64
> > >> PARAMETER C_BASEADDR = 0xffffe000
> > >> PARAMETER C_HIGHADDR = 0xffffffff
> > >> BUS_INTERFACE SPLB = plb
> > >> BUS_INTERFACE PORTA = xps_bram_if_cntlr_1_port
> > >> END
> > >>
> > >> BEGIN bram_block
> > >> PARAMETER INSTANCE = plb_bram_if_cntlr_1_bram
> > >> PARAMETER HW_VER = 1.00.a
> > >> BUS_INTERFACE PORTA = xps_bram_if_cntlr_1_port
> > >> END
> > >>
> > >> BEGIN xps_uart16550
> > >> PARAMETER INSTANCE = RS232_Uart
> > >> PARAMETER HW_VER = 2.00.a
> > >> PARAMETER C_IS_A_16550 = 1
> > >> PARAMETER C_BASEADDR = 0x83e00000
> > >> PARAMETER C_HIGHADDR = 0x83e0ffff
> > >> BUS_INTERFACE SPLB = plb
> > >> PORT sin = fpga_0_RS232_Uart_sin
> > >> PORT sout = fpga_0_RS232_Uart_sout
> > >> PORT IP2INTC_Irpt = RS232_Uart_IP2INTC_Irpt
> > >> END
> > >>
> > >> BEGIN xps_gpio
> > >> PARAMETER INSTANCE = LEDs_4Bit
> > >> PARAMETER HW_VER = 1.00.a
> > >> PARAMETER C_INTERRUPT_PRESENT = 1
> > >> PARAMETER C_GPIO_WIDTH = 4
> > >> PARAMETER C_IS_DUAL = 0
> > >> PARAMETER C_IS_BIDIR = 1
> > >> PARAMETER C_ALL_INPUTS = 0
> > >> PARAMETER C_BASEADDR = 0x81400000
> > >> PARAMETER C_HIGHADDR = 0x8140ffff
> > >> BUS_INTERFACE SPLB = plb
> > >> PORT GPIO_IO = fpga_0_LEDs_4Bit_GPIO_IO
> > >> PORT IP2INTC_Irpt = LEDs_4Bit_IP2INTC_Irpt
> > >> END
> > >>
> > >> BEGIN xps_iic
> > >> PARAMETER INSTANCE = IIC_EEPROM
> > >> PARAMETER HW_VER = 2.00.a
> > >> PARAMETER C_CLK_FREQ = 100000000
> > >> PARAMETER C_IIC_FREQ = 100000
> > >> PARAMETER C_TEN_BIT_ADR = 0
> > >> PARAMETER C_BASEADDR = 0x81600000
> > >> PARAMETER C_HIGHADDR = 0x8160ffff
> > >> BUS_INTERFACE SPLB = plb
> > >> PORT Scl = fpga_0_IIC_EEPROM_Scl
> > >> PORT Sda = fpga_0_IIC_EEPROM_Sda
> > >> PORT IIC2INTC_Irpt = IIC_EEPROM_IIC2INTC_Irpt
> > >> END
> > >>
> > >> BEGIN xps_sysace
> > >> PARAMETER INSTANCE = SysACE_CompactFlash
> > >> PARAMETER HW_VER = 1.00.a
> > >> PARAMETER C_MEM_WIDTH = 16
> > >> PARAMETER C_BASEADDR = 0x83600000
> > >> PARAMETER C_HIGHADDR = 0x8360ffff
> > >> BUS_INTERFACE SPLB = plb
> > >> PORT SysACE_CLK = fpga_0_SysACE_CompactFlash_SysACE_CLK
> > >> PORT SysACE_MPA = fpga_0_SysACE_CompactFlash_SysACE_MPA_split
> > >> PORT SysACE_MPD = fpga_0_SysACE_CompactFlash_SysACE_MPD
> > >> PORT SysACE_CEN = fpga_0_SysACE_CompactFlash_SysACE_CEN
> > >> PORT SysACE_OEN = fpga_0_SysACE_CompactFlash_SysACE_OEN
> > >> PORT SysACE_WEN = fpga_0_SysACE_CompactFlash_SysACE_WEN
> > >> PORT SysACE_MPIRQ = fpga_0_SysACE_CompactFlash_SysACE_MPIRQ
> > >> PORT SysACE_IRQ = SysACE_CompactFlash_SysACE_IRQ
> > >> END
> > >>
> > >> BEGIN mpmc
> > >> PARAMETER INSTANCE = DDR_SDRAM
> > >> PARAMETER HW_VER = 4.00.a
> > >> PARAMETER C_NUM_PORTS = 3
> > >> PARAMETER C_MEM_PARTNO = HYB25D512160BE-5
> > >> PARAMETER C_MEM_DATA_WIDTH = 32
> > >> PARAMETER C_MEM_DQS_WIDTH = 4
> > >> PARAMETER C_MEM_DM_WIDTH = 4
> > >> PARAMETER C_MEM_TYPE = DDR
> > >> PARAMETER C_NUM_IDELAYCTRL = 2
> > >> PARAMETER C_IDELAYCTRL_LOC = IDELAYCTRL_X0Y3-IDELAYCTRL_X0Y2
> > >> PARAMETER C_PIM0_BASETYPE = 2
> > >> PARAMETER C_PIM1_BASETYPE = 2
> > >> PARAMETER C_PIM2_BASETYPE = 3
> > >> PARAMETER C_MPMC_CLK0_PERIOD_PS = 10000
> > >> PARAMETER C_SDMA2_PI2LL_CLK_RATIO = 1
> > >> PARAMETER C_MPMC_BASEADDR = 0x00000000
> > >> PARAMETER C_MPMC_HIGHADDR = 0x07ffffff
> > >> PARAMETER C_SDMA_CTRL_BASEADDR = 0x84600000
> > >> PARAMETER C_SDMA_CTRL_HIGHADDR = 0x8460ffff
> > >> BUS_INTERFACE SPLB0 = ppc405_0_iplb1
> > >> BUS_INTERFACE SPLB1 = ppc405_0_dplb1
> > >> BUS_INTERFACE SDMA_LL2 = TriMode_MAC_GMII_LLINK0
> > >> BUS_INTERFACE SDMA_CTRL2 = plb
> > >> PORT DDR_Addr = fpga_0_DDR_SDRAM_DDR_Addr
> > >> PORT DDR_BankAddr = fpga_0_DDR_SDRAM_DDR_BankAddr
> > >> PORT DDR_CAS_n = fpga_0_DDR_SDRAM_DDR_CAS_n
> > >> PORT DDR_CE = fpga_0_DDR_SDRAM_DDR_CE
> > >> PORT DDR_CS_n = fpga_0_DDR_SDRAM_DDR_CS_n
> > >> PORT DDR_RAS_n = fpga_0_DDR_SDRAM_DDR_RAS_n
> > >> PORT DDR_WE_n = fpga_0_DDR_SDRAM_DDR_WE_n
> > >> PORT DDR_DM = fpga_0_DDR_SDRAM_DDR_DM
> > >> PORT DDR_DQS = fpga_0_DDR_SDRAM_DDR_DQS
> > >> PORT DDR_DQ = fpga_0_DDR_SDRAM_DDR_DQ
> > >> PORT DDR_Clk = fpga_0_DDR_SDRAM_DDR_Clk
> > >> PORT DDR_Clk_n = fpga_0_DDR_SDRAM_DDR_Clk_n
> > >> PORT MPMC_Clk0 = sys_clk_s
> > >> PORT MPMC_Clk90 = DDR_SDRAM_mpmc_clk_90_s
> > >> PORT SDMA2_Clk = sys_clk_s
> > >> PORT MPMC_Clk_200MHz = clk_200mhz_s
> > >> PORT MPMC_Rst = sys_periph_reset
> > >> PORT SDMA2_Rx_IntOut = DDR_SDRAM_SDMA2_Rx_IntOut
> > >> PORT SDMA2_Tx_IntOut = DDR_SDRAM_SDMA2_Tx_IntOut
> > >> END
> > >>
> > >> BEGIN xps_ll_temac
> > >> PARAMETER INSTANCE = TriMode_MAC_GMII
> > >> PARAMETER HW_VER = 1.01.a
> > >> PARAMETER C_SPLB_CLK_PERIOD_PS = 10000
> > >> PARAMETER C_PHY_TYPE = 1
> > >> PARAMETER C_NUM_IDELAYCTRL = 4
> > >> PARAMETER C_IDELAYCTRL_LOC = IDELAYCTRL_X1Y1-IDELAYCTRL_X1Y3-
> > IDELAYCTRL_X2Y2-IDELAYCTRL_X2Y3
> > >> PARAMETER C_TEMAC_TYPE = 1
> > >> PARAMETER C_BUS2CORE_CLK_RATIO = 1
> > >> PARAMETER C_BASEADDR = 0x81c00000
> > >> PARAMETER C_HIGHADDR = 0x81c0ffff
> > >> BUS_INTERFACE SPLB = plb
> > >> BUS_INTERFACE LLINK0 = TriMode_MAC_GMII_LLINK0
> > >> PORT GMII_TXD_0 = fpga_0_TriMode_MAC_GMII_GMII_TXD_0
> > >> PORT GMII_TX_EN_0 = fpga_0_TriMode_MAC_GMII_GMII_TX_EN_0
> > >> PORT GMII_TX_ER_0 = fpga_0_TriMode_MAC_GMII_GMII_TX_ER_0
> > >> PORT GMII_TX_CLK_0 = fpga_0_TriMode_MAC_GMII_GMII_TX_CLK_0
> > >> PORT GMII_RXD_0 = fpga_0_TriMode_MAC_GMII_GMII_RXD_0
> > >> PORT GMII_RX_DV_0 = fpga_0_TriMode_MAC_GMII_GMII_RX_DV_0
> > >> PORT GMII_RX_ER_0 = fpga_0_TriMode_MAC_GMII_GMII_RX_ER_0
> > >> PORT GMII_RX_CLK_0 = fpga_0_TriMode_MAC_GMII_GMII_RX_CLK_0
> > >> PORT MII_TX_CLK_0 = fpga_0_TriMode_MAC_GMII_MII_TX_CLK_0
> > >> PORT MDIO_0 = fpga_0_TriMode_MAC_GMII_MDIO_0
> > >> PORT MDC_0 = fpga_0_TriMode_MAC_GMII_MDC_0
> > >> PORT TemacPhy_RST_n = fpga_0_TriMode_MAC_GMII_TemacPhy_RST_n
> > >> PORT GTX_CLK_0 = temac_clk_s
> > >> PORT REFCLK = clk_200mhz_s
> > >> PORT LlinkTemac0_CLK = sys_clk_s
> > >> PORT TemacIntc0_Irpt = TriMode_MAC_GMII_TemacIntc0_Irpt
> > >> END
> > >>
> > >> BEGIN util_bus_split
> > >> PARAMETER INSTANCE = SysACE_CompactFlash_util_bus_split_0
> > >> PARAMETER HW_VER = 1.00.a
> > >> PARAMETER C_SIZE_IN = 7
> > >> PARAMETER C_LEFT_POS = 0
> > >> PARAMETER C_SPLIT = 6
> > >> PORT Sig = fpga_0_SysACE_CompactFlash_SysACE_MPA_split
> > >> PORT Out1 = fpga_0_SysACE_CompactFlash_SysACE_MPA
> > >> END
> > >>
> > >> BEGIN plb_v46
> > >> PARAMETER INSTANCE = ppc405_0_iplb1
> > >> PARAMETER HW_VER = 1.02.a
> > >> PORT PLB_Clk = sys_clk_s
> > >> PORT SYS_Rst = sys_bus_reset
> > >> END
> > >>
> > >> BEGIN plb_v46
> > >> PARAMETER INSTANCE = ppc405_0_dplb1
> > >> PARAMETER HW_VER = 1.02.a
> > >> PORT PLB_Clk = sys_clk_s
> > >> PORT SYS_Rst = sys_bus_reset
> > >> END
> > >>
> > >> BEGIN clock_generator
> > >> PARAMETER INSTANCE = clock_generator_0
> > >> PARAMETER HW_VER = 2.00.a
> > >> PARAMETER C_EXT_RESET_HIGH = 1
> > >> PARAMETER C_CLKIN_FREQ = 100000000
> > >> PARAMETER C_CLKOUT0_FREQ = 100000000
> > >> PARAMETER C_CLKOUT0_BUF = TRUE
> > >> PARAMETER C_CLKOUT0_PHASE = 0
> > >> PARAMETER C_CLKOUT0_GROUP = DCM0
> > >> PARAMETER C_CLKOUT1_FREQ = 100000000
> > >> PARAMETER C_CLKOUT1_BUF = TRUE
> > >> PARAMETER C_CLKOUT1_PHASE = 90
> > >> PARAMETER C_CLKOUT1_GROUP = DCM0
> > >> PARAMETER C_CLKOUT2_FREQ = 300000000
> > >> PARAMETER C_CLKOUT2_BUF = TRUE
> > >> PARAMETER C_CLKOUT2_PHASE = 0
> > >> PARAMETER C_CLKOUT2_GROUP = DCM0
> > >> PARAMETER C_CLKOUT3_FREQ = 200000000
> > >> PARAMETER C_CLKOUT3_BUF = TRUE
> > >> PARAMETER C_CLKOUT3_PHASE = 0
> > >> PARAMETER C_CLKOUT3_GROUP = NONE
> > >> PARAMETER C_CLKOUT4_FREQ = 125000000
> > >> PARAMETER C_CLKOUT4_BUF = TRUE
> > >> PARAMETER C_CLKOUT4_PHASE = 0
> > >> PARAMETER C_CLKOUT4_GROUP = NONE
> > >> PORT CLKOUT0 = sys_clk_s
> > >> PORT CLKOUT1 = DDR_SDRAM_mpmc_clk_90_s
> > >> PORT CLKOUT2 = proc_clk_s
> > >> PORT CLKOUT3 = clk_200mhz_s
> > >> PORT CLKOUT4 = temac_clk_s
> > >> PORT CLKIN = dcm_clk_s
> > >> PORT LOCKED = Dcm_all_locked
> > >> PORT RST = net_gnd
> > >> END
> > >>
> > >> BEGIN proc_sys_reset
> > >> PARAMETER INSTANCE = proc_sys_reset_0
> > >> PARAMETER HW_VER = 2.00.a
> > >> PARAMETER C_EXT_RESET_HIGH = 0
> > >> BUS_INTERFACE RESETPPC0 = ppc_reset_bus
> > >> PORT Slowest_sync_clk = sys_clk_s
> > >> PORT Dcm_locked = Dcm_all_locked
> > >> PORT Ext_Reset_In = sys_rst_s
> > >> PORT Bus_Struct_Reset = sys_bus_reset
> > >> PORT Peripheral_Reset = sys_periph_reset
> > >> END
> > >>
> > >> BEGIN xps_intc
> > >> PARAMETER INSTANCE = xps_intc_0
> > >> PARAMETER HW_VER = 1.00.a
> > >> PARAMETER C_BASEADDR = 0x81800000
> > >> PARAMETER C_HIGHADDR = 0x8180ffff
> > >> BUS_INTERFACE SPLB = plb
> > >> PORT Irq = EICC405EXTINPUTIRQ
> > >> PORT Intr = RS232_Uart_IP2INTC_Irpt & LEDs_4Bit_IP2INTC_Irpt &
> > IIC_EEPROM_IIC2INTC_Irpt & SysACE_CompactFlash_SysACE_IRQ &
> > TriMode_MAC_GMII_TemacIntc0_Irpt & DDR_SDRAM_SDMA2_Rx_IntOut &
> > DDR_SDRAM_SDMA2_Tx_IntOut
> > >> END
> > >>
> > >>
> > >>
> > >> #address-cells = <1>;
> > >> #size-cells = <1>;
> > >> compatible = "xlnx,virtex";
> > >> model = "testing";
> > >> DDR_SDRAM: memory@0 {
> > >> device_type = "memory";
> > >> reg = < 0 8000000 >;
> > >> } ;
> > >> chosen {
> > >> bootargs = "console=ttyS0,9600 ip=on
> > nfsroot=172.16.40.76:/v2pclients/jhl26,tcp";
> > >> linux,stdout-path = "/plb@0/serial@83e00000";
> > >> } ;
> > >> cpus {
> > >> #address-cells = <1>;
> > >> #cpus = <1>;
> > >> #size-cells = <0>;
> > >> ppc405_0: cpu@0 {
> > >> clock-frequency = <11e1a300>;
> > >> compatible = "PowerPC,405", "ibm,ppc405";
> > >> d-cache-line-size = <20>;
> > >> d-cache-size = <4000>;
> > >> device_type = "cpu";
> > >> i-cache-line-size = <20>;
> > >> i-cache-size = <4000>;
> > >> model = "PowerPC,405";
> > >> reg = <0>;
> > >> timebase-frequency = <11e1a300>;
> > >> xlnx,apu-control = <de00>;
> > >> xlnx,apu-udi-1 = <a18983>;
> > >> xlnx,apu-udi-2 = <a38983>;
> > >> xlnx,apu-udi-3 = <a589c3>;
> > >> xlnx,apu-udi-4 = <a789c3>;
> > >> xlnx,apu-udi-5 = <a98c03>;
> > >> xlnx,apu-udi-6 = <ab8c03>;
> > >> xlnx,apu-udi-7 = <ad8c43>;
> > >> xlnx,apu-udi-8 = <af8c43>;
> > >> xlnx,deterministic-mult = <0>;
> > >> xlnx,disable-operand-forwarding = <1>;
> > >> xlnx,fastest-plb-clock = "DPLB0";
> > >> xlnx,generate-plb-timespecs = <1>;
> > >> xlnx,mmu-enable = <1>;
> > >> xlnx,pvr-high = <0>;
> > >> xlnx,pvr-low = <0>;
> > >> } ;
> > >> } ;
> > >> plb: plb@0 {
> > >> #address-cells = <1>;
> > >> #size-cells = <1>;
> > >> compatible = "xlnx,plb-v46-1.02.a";
> > >> ranges ;
> > >> IIC_EEPROM: i2c@81600000 {
> > >> compatible = "xlnx,xps-iic-2.00.a";
> > >> interrupt-parent = <&xps_intc_0>;
> > >> interrupts = < 4 2 >;
> > >> reg = < 81600000 10000 >;
> > >> xlnx,clk-freq = <5f5e100>;
> > >> xlnx,family = "virtex4";
> > >> xlnx,gpo-width = <1>;
> > >> xlnx,iic-freq = <186a0>;
> > >> xlnx,scl-inertial-delay = <0>;
> > >> xlnx,sda-inertial-delay = <0>;
> > >> xlnx,ten-bit-adr = <0>;
> > >> } ;
> > >> LEDs_4Bit: gpio@81400000 {
> > >> compatible = "xlnx,xps-gpio-1.00.a";
> > >> interrupt-parent = <&xps_intc_0>;
> > >> interrupts = < 5 2 >;
> > >> reg = < 81400000 10000 >;
> > >> xlnx,all-inputs = <0>;
> > >> xlnx,all-inputs-2 = <0>;
> > >> xlnx,dout-default = <0>;
> > >> xlnx,dout-default-2 = <0>;
> > >> xlnx,family = "virtex4";
> > >> xlnx,gpio-width = <4>;
> > >> xlnx,interrupt-present = <1>;
> > >> xlnx,is-bidir = <1>;
> > >> xlnx,is-bidir-2 = <1>;
> > >> xlnx,is-dual = <0>;
> > >> xlnx,tri-default = <ffffffff>;
> > >> xlnx,tri-default-2 = <ffffffff>;
> > >> } ;
> > >> RS232_Uart: serial@83e00000 {
> > >> compatible = "xlnx,xps-uart16550-2.00.a";
> > >> // compatible = "ns16550";
> > >> device_type = "serial";
> > >> interrupt-parent = <&xps_intc_0>;
> > >> interrupts = < 6 2 >;
> > >> reg = < 83e00000 10000 >;
> > >> current-speed = <d#9600>;
> > >> clock-frequency = <d#100000000>; /* added
> > by jhl */
> > >> reg-shift = <2>;
> > >> xlnx,family = "virtex4";
> > >> xlnx,has-external-rclk = <0>;
> > >> xlnx,has-external-xin = <0>;
> > >> xlnx,is-a-16550 = <1>;
> > >> } ;
> > >> SysACE_CompactFlash: sysace@83600000 {
> > >> compatible = "xlnx,xps-sysace-1.00.a";
> > >> interrupt-parent = <&xps_intc_0>;
> > >> interrupts = < 3 2 >;
> > >> reg = < 83600000 10000 >;
> > >> xlnx,family = "virtex4";
> > >> xlnx,mem-width = <10>;
> > >> } ;
> > >> TriMode_MAC_GMII: xps-ll-temac@81c00000 {
> > >> #address-cells = <1>;
> > >> #size-cells = <1>;
> > >> compatible = "xlnx,compound";
> > >> ethernet@81c00000 {
> > >> compatible = "xlnx,xps-ll-temac-
> > 1.01.a";
> > >> device_type = "network";
> > >> interrupt-parent =
> > <&xps_intc_0>;
> > >> interrupts = < 2 2 >;
> > >> llink-connected = <&PIM2>;
> > >> local-mac-address = [ 02 00 00
> > 00 00 01 ];
> > >> reg = < 81c00000 40 >;
> > >> xlnx,bus2core-clk-ratio = <1>;
> > >> xlnx,phy-type = <1>;
> > >> xlnx,phyaddr = <1>;
> > >> xlnx,rxcsum = <0>;
> > >> xlnx,rxfifo = <1000>;
> > >> xlnx,temac-type = <1>;
> > >> xlnx,txcsum = <0>;
> > >> xlnx,txfifo = <1000>;
> > >> } ;
> > >> } ;
> > >> mpmc@0 {
> > >> #address-cells = <1>;
> > >> #size-cells = <1>;
> > >> compatible = "xlnx,mpmc-4.00.a";
> > >> PIM2: sdma@84600100 {
> > >> compatible = "xlnx,ll-dma-
> > 1.00.a";
> > >> interrupt-parent =
> > <&xps_intc_0>;
> > >> interrupts = < 1 2 0 2 >;
> > >> reg = < 84600100 80 >;
> > >> } ;
> > >> } ;
> > >> xps_bram_if_cntlr_1: xps-bram-if-cntlr@ffffe000 {
> > >> compatible = "xlnx,xps-bram-if-cntlr-
> > 1.00.a";
> > >> reg = < ffffe000 2000 >;
> > >> xlnx,family = "virtex4";
> > >> } ;
> > >> xps_intc_0: interrupt-controller@81800000 {
> > >> #interrupt-cells = <2>;
> > >> compatible = "xlnx,xps-intc-1.00.a";
> > >> interrupt-controller ;
> > >> reg = < 81800000 10000 >;
> > >> xlnx,num-intr-inputs = <7>;
> > >> } ;
> > >> } ;
> > >> ppc405_0_dplb1: plb@1 {
> > >> #address-cells = <1>;
> > >> #size-cells = <1>;
> > >> compatible = "xlnx,plb-v46-1.02.a";
> > >> ranges ;
> > >> } ;
> > >> } ;
> > >>
> > >>
> > >>
> > >> -----Original Message-----
> > >> From: Magnus Hjorth [mailto:mh@omnisys.se]
> > >> Sent: Saturday, March 29, 2008 6:54 AM
> > >> To: git
> > >> Cc: linuxppc-embedded@ozlabs.org
> > >> Subject: Xilinx LLTEMAC driver issues
> > >>
> > >> Hi,
> > >>
> > >> I'm having some networking troubles with the Xilinx LLTEMAC driver
> from the
> > >> Xilinx Linux git tree (powerpc arch) on an ML403 board. EDK9.2SP2,
> > >> xps_ll_temac v1.00.b
> > >>
> > >> The weird thing is, that it sort of half works. It successfully makes
> a DHCP
> > >> request and gets its IP address. I tried setting up a tftpd server,
> and I can
> > >> see UDP requests coming in but the response doesn't seem to come out.
> I also
> > >> tried running a TCP server on the board, and it can see and accept
> incoming
> > >> connections but after that no data seems to get through. I can ping
> out and
> > >> get around 40% packet loss.
> > >>
> > >> Looking at /proc/interrupts, I can see both TxDma interrupts and
> RxDma
> > >> interrupts. No eth0 interrupts but that seems to be OK judging by the
> driver
> > >> source comments. Ifconfig shows no collistions, no dropped packets,
> no
> > errors,
> > >> so the system seems to think that everything is OK.
> > >>
> > >> Clues anyone? I'm starting to run out of ideas...
> > >>
> > >> Best regards,
> > >> Magnus
> > >>
> > >>
> > >> --
> > >>
> > >> Magnus Hjorth, M.Sc.
> > >> Omnisys Instruments AB
> > >> Gruvgatan 8
> > >> SE-421 30 Västra Frölunda, SWEDEN
> > >> Phone: +46 31 734 34 09
> > >> Fax: +46 31 734 34 29
> > >> http://www.omnisys.se
> > >>
> > >
> > > _______________________________________________
> > > Linuxppc-embedded mailing list
> > > Linuxppc-embedded@ozlabs.org
> > > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
Johann Baudy
johaahn@gmail.com
[-- Attachment #2: Type: text/html, Size: 49288 bytes --]
^ permalink raw reply
* [PATCH 0/4] [POWERPC] lockdep support for ppc64
From: Benjamin Herrenschmidt @ 2008-04-02 7:52 UTC (permalink / raw)
To: linuxppc-dev
[Not to merge just yet ... almost]
This serie of patches adds lockdep support for 64 bits
powerpc. Dale's patch for 32 bits still need me to review
and test it which I'll try to do asap.
It needs the iSeries hardirq enable fix that I posted
earlier (which is probably 2.6.25 material).
Note that we can already see potential problems exposed
by it. So far on my list:
- something wrong with iseries veth. Haven't got to figure
out what yet, could be a false positive
- possible deadlock with the device-tree rwlock. The one that
I caught with lockdep here is pSeries rtas_set_rtc_time() calls
rtas_token() from softirq, which does on of_find_property(),
which takes the read lock. Other things can call prom_add_propety()
which can take the write lock, while softirqs are enabled -> boom.
Maybe we should forbid OF device-tree access from IRQs and thus
things that need to use rtas_token() will have to cache the token.
^ permalink raw reply
* [PATCH 1/4] [POWERPC] Initialize paca->current earlier
From: Benjamin Herrenschmidt @ 2008-04-02 7:52 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1207122728.672673.111194574046.qpush@grosgo>
Currently, we initialize the "current" pointer in the PACA (which
is used by the "current" macro in the kernel) before calling
setup_system(). That means that early_setup() is called with
current still "NULL" which is -not- a good idea. It happens to
work so far but breaks with lockdep when early code calls printk.
This changes it so that all PACAs are statically initialized with
__current pointing to the init task. For non-0 CPUs, this is fixed
up before use.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/kernel/head_64.S | 4 ----
arch/powerpc/kernel/paca.c | 3 ++-
2 files changed, 2 insertions(+), 5 deletions(-)
--- linux-work.orig/arch/powerpc/kernel/head_64.S 2008-04-02 18:20:53.000000000 +1100
+++ linux-work/arch/powerpc/kernel/head_64.S 2008-04-02 18:24:45.000000000 +1100
@@ -1505,10 +1505,6 @@ _INIT_GLOBAL(start_here_common)
li r0,0
stdu r0,-STACK_FRAME_OVERHEAD(r1)
- /* ptr to current */
- LOAD_REG_IMMEDIATE(r4, init_task)
- std r4,PACACURRENT(r13)
-
/* Load the TOC */
ld r2,PACATOC(r13)
std r1,PACAKSAVE(r13)
Index: linux-work/arch/powerpc/kernel/paca.c
===================================================================
--- linux-work.orig/arch/powerpc/kernel/paca.c 2008-04-02 18:28:07.000000000 +1100
+++ linux-work/arch/powerpc/kernel/paca.c 2008-04-02 18:28:22.000000000 +1100
@@ -72,7 +72,8 @@ struct slb_shadow slb_shadow[] __cacheli
.paca_index = (number), /* Paca Index */ \
.kernel_toc = (unsigned long)(&__toc_start) + 0x8000UL, \
.hw_cpu_id = 0xffff, \
- .slb_shadow_ptr = &slb_shadow[number],
+ .slb_shadow_ptr = &slb_shadow[number], \
+ .__current = &init_task,
#ifdef CONFIG_PPC_ISERIES
#define PACA_INIT_ISERIES(number) \
^ permalink raw reply
* [PATCH 2/4] [POWERPC] lockdep stacktrace support
From: Benjamin Herrenschmidt @ 2008-04-02 7:52 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1207122728.672673.111194574046.qpush@grosgo>
From: Christoph Hellwig <hch@lst.de>
I recently tried to work on lockdep for powerpc. I have preliminary
version of the stacktrace code, but had to give up on trace irqflags
support because I'm not that knowledgeable on lowlevel ppc details.
Maybe someone more faimilar with the code wants to give it another try?
My stacktrace code is below:
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/Kconfig | 4 +++
arch/powerpc/kernel/Makefile | 1
arch/powerpc/kernel/stacktrace.c | 52 +++++++++++++++++++++++++++++++++++++++
3 files changed, 57 insertions(+)
--- linux-work.orig/arch/powerpc/Kconfig 2008-04-02 15:46:07.000000000 +1100
+++ linux-work/arch/powerpc/Kconfig 2008-04-02 16:47:46.000000000 +1100
@@ -49,6 +49,10 @@ config IRQ_PER_CPU
bool
default y
+config STACKTRACE_SUPPORT
+ bool
+ default y
+
config RWSEM_GENERIC_SPINLOCK
bool
Index: linux-work/arch/powerpc/kernel/Makefile
===================================================================
--- linux-work.orig/arch/powerpc/kernel/Makefile 2008-04-02 15:46:07.000000000 +1100
+++ linux-work/arch/powerpc/kernel/Makefile 2008-04-02 16:46:07.000000000 +1100
@@ -67,6 +67,7 @@ obj-$(CONFIG_BOOTX_TEXT) += btext.o
obj-$(CONFIG_SMP) += smp.o
obj-$(CONFIG_KPROBES) += kprobes.o
obj-$(CONFIG_PPC_UDBG_16550) += legacy_serial.o udbg_16550.o
+obj-$(CONFIG_STACKTRACE) += stacktrace.o
pci64-$(CONFIG_PPC64) += pci_dn.o isa-bridge.o
obj-$(CONFIG_PCI) += pci_$(CONFIG_WORD_SIZE).o $(pci64-y) \
Index: linux-work/arch/powerpc/kernel/stacktrace.c
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux-work/arch/powerpc/kernel/stacktrace.c 2008-04-02 16:46:07.000000000 +1100
@@ -0,0 +1,52 @@
+
+#include <linux/sched.h>
+#include <linux/stacktrace.h>
+
+
+#ifdef CONFIG_PPC64
+#define MIN_STACK_FRAME 112 /* same as STACK_FRAME_OVERHEAD, in fact */
+#define FRAME_LR_SAVE 2
+#define INT_FRAME_SIZE (sizeof(struct pt_regs) + STACK_FRAME_OVERHEAD + 288)
+#define REGS_MARKER 0x7265677368657265ul
+#define FRAME_MARKER 12
+#else
+#define MIN_STACK_FRAME 16
+#define FRAME_LR_SAVE 1
+#define INT_FRAME_SIZE (sizeof(struct pt_regs) + STACK_FRAME_OVERHEAD)
+#define REGS_MARKER 0x72656773ul
+#define FRAME_MARKER 2
+#endif
+
+
+/*
+ * Save stack-backtrace addresses into a stack_trace buffer.
+ * If all_contexts is set, all contexts (hardirq, softirq and process)
+ * are saved. If not set then only the current context is saved.
+ */
+void save_stack_trace(struct stack_trace *trace)
+{
+ unsigned long sp;
+
+ asm("mr %0,1" : "=r" (sp));
+
+ for (;;) {
+ unsigned long *stack = (unsigned long *) sp;
+ unsigned long newsp, ip;
+
+ if (!validate_sp(sp, current, MIN_STACK_FRAME))
+ return;
+
+ newsp = stack[0];
+ ip = stack[FRAME_LR_SAVE];
+
+ if (!trace->skip)
+ trace->entries[trace->nr_entries++] = ip;
+ else
+ trace->skip--;
+
+ if (trace->nr_entries >= trace->max_entries)
+ return;
+
+ sp = newsp;
+ }
+}
^ permalink raw reply
* [PATCH 3/4] [POWERPC] Fixup softirq preempt count
From: Benjamin Herrenschmidt @ 2008-04-02 7:52 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1207122728.672673.111194574046.qpush@grosgo>
This fixes the handling of the preempt count when switching
interrupt stacks so that HW interrupt properly get the softirq
mask copied over from the previous stack.
It also initializes the softirq stack preempt_count to 0 instead
of SOFTIRQ_OFFSET, like x86, as __do_softirq() does the increment,
and we hit some lockdep checks if we have it twice.
That means we do run for a little while off the softirq stack
with the preempt-count set to 0, which could be deadly if we
try to take a softirq at that point, however we do so with
interrupts disabled, so I think we are ok.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/kernel/irq.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
--- linux-work.orig/arch/powerpc/kernel/irq.c 2008-04-02 16:48:58.000000000 +1100
+++ linux-work/arch/powerpc/kernel/irq.c 2008-04-02 16:49:36.000000000 +1100
@@ -310,8 +310,21 @@ void do_IRQ(struct pt_regs *regs)
handler = &__do_IRQ;
irqtp->task = curtp->task;
irqtp->flags = 0;
+
+ /* Copy the softirq bits in preempt_count so that the
+ * softirq checks work in the hardirq context.
+ */
+ irqtp->preempt_count =
+ (irqtp->preempt_count & ~SOFTIRQ_MASK) |
+ (curtp->preempt_count & SOFTIRQ_MASK);
+
call_handle_irq(irq, desc, irqtp, handler);
irqtp->task = NULL;
+
+
+ /* Set any flag that may have been set on the
+ * alternate stack
+ */
if (irqtp->flags)
set_bits(irqtp->flags, &curtp->flags);
} else
@@ -357,7 +370,7 @@ void irq_ctx_init(void)
memset((void *)softirq_ctx[i], 0, THREAD_SIZE);
tp = softirq_ctx[i];
tp->cpu = i;
- tp->preempt_count = SOFTIRQ_OFFSET;
+ tp->preempt_count = 0;
memset((void *)hardirq_ctx[i], 0, THREAD_SIZE);
tp = hardirq_ctx[i];
^ permalink raw reply
* [PATCH 4/4] [POWERPC] irqtrace support to 64-bit powerpc
From: Benjamin Herrenschmidt @ 2008-04-02 7:52 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1207122728.672673.111194574046.qpush@grosgo>
This adds the low level irq tracing hooks to the powerpc architecture
needed to enable full lockdep functionality
Partly based on Johannes Berg's initial version, removing the asm
trampoline that isn't needed (thus improving perfs) and all sorts
of bits and pieces, reworking most of the assembly, etc...
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/Kconfig | 9 +++++++
arch/powerpc/kernel/entry_64.S | 27 +++++++++++++++++++++-
arch/powerpc/kernel/head_64.S | 47 +++++++++++++++++++++++++++-------------
arch/powerpc/kernel/irq.c | 3 +-
arch/powerpc/kernel/ppc_ksyms.c | 4 ---
arch/powerpc/kernel/setup_64.c | 4 +++
include/asm-powerpc/exception.h | 6 ++---
include/asm-powerpc/hw_irq.h | 13 +++++------
include/asm-powerpc/irqflags.h | 37 +++++++++++++++++++++----------
include/asm-powerpc/rwsem.h | 35 ++++++++++++++++++++++-------
include/asm-powerpc/spinlock.h | 1
11 files changed, 134 insertions(+), 52 deletions(-)
--- linux-work.orig/arch/powerpc/Kconfig 2008-04-02 18:30:18.000000000 +1100
+++ linux-work/arch/powerpc/Kconfig 2008-04-02 18:30:21.000000000 +1100
@@ -53,6 +53,15 @@ config STACKTRACE_SUPPORT
bool
default y
+config TRACE_IRQFLAGS_SUPPORT
+ bool
+ depends on PPC64
+ default y
+
+config LOCKDEP_SUPPORT
+ bool
+ default y
+
config RWSEM_GENERIC_SPINLOCK
bool
Index: linux-work/arch/powerpc/kernel/irq.c
===================================================================
--- linux-work.orig/arch/powerpc/kernel/irq.c 2008-04-02 18:30:20.000000000 +1100
+++ linux-work/arch/powerpc/kernel/irq.c 2008-04-02 18:30:21.000000000 +1100
@@ -114,7 +114,7 @@ static inline void set_soft_enabled(unsi
: : "r" (enable), "i" (offsetof(struct paca_struct, soft_enabled)));
}
-void local_irq_restore(unsigned long en)
+void raw_local_irq_restore(unsigned long en)
{
/*
* get_paca()->soft_enabled = en;
@@ -174,6 +174,7 @@ void local_irq_restore(unsigned long en)
__hard_irq_enable();
}
+EXPORT_SYMBOL(raw_local_irq_restore);
#endif /* CONFIG_PPC64 */
int show_interrupts(struct seq_file *p, void *v)
Index: linux-work/arch/powerpc/kernel/ppc_ksyms.c
===================================================================
--- linux-work.orig/arch/powerpc/kernel/ppc_ksyms.c 2008-04-02 18:11:56.000000000 +1100
+++ linux-work/arch/powerpc/kernel/ppc_ksyms.c 2008-04-02 18:30:21.000000000 +1100
@@ -45,10 +45,6 @@
#include <asm/signal.h>
#include <asm/dcr.h>
-#ifdef CONFIG_PPC64
-EXPORT_SYMBOL(local_irq_restore);
-#endif
-
#ifdef CONFIG_PPC32
extern void transfer_to_handler(void);
extern void do_IRQ(struct pt_regs *regs);
Index: linux-work/include/asm-powerpc/hw_irq.h
===================================================================
--- linux-work.orig/include/asm-powerpc/hw_irq.h 2008-04-02 18:11:56.000000000 +1100
+++ linux-work/include/asm-powerpc/hw_irq.h 2008-04-02 18:30:21.000000000 +1100
@@ -27,7 +27,7 @@ static inline unsigned long local_get_fl
return flags;
}
-static inline unsigned long local_irq_disable(void)
+static inline unsigned long raw_local_irq_disable(void)
{
unsigned long flags, zero;
@@ -39,14 +39,15 @@ static inline unsigned long local_irq_di
return flags;
}
-extern void local_irq_restore(unsigned long);
+extern void raw_local_irq_restore(unsigned long);
extern void iseries_handle_interrupts(void);
-#define local_irq_enable() local_irq_restore(1)
-#define local_save_flags(flags) ((flags) = local_get_flags())
-#define local_irq_save(flags) ((flags) = local_irq_disable())
+#define raw_local_irq_enable() raw_local_irq_restore(1)
+#define raw_local_save_flags(flags) ((flags) = local_get_flags())
+#define raw_local_irq_save(flags) ((flags) = raw_local_irq_disable())
-#define irqs_disabled() (local_get_flags() == 0)
+#define raw_irqs_disabled() (local_get_flags() == 0)
+#define raw_irqs_disabled_flags(flags) ((flags) == 0)
#define __hard_irq_enable() __mtmsrd(mfmsr() | MSR_EE, 1)
#define __hard_irq_disable() __mtmsrd(mfmsr() & ~MSR_EE, 1)
Index: linux-work/include/asm-powerpc/irqflags.h
===================================================================
--- linux-work.orig/include/asm-powerpc/irqflags.h 2008-04-02 18:11:56.000000000 +1100
+++ linux-work/include/asm-powerpc/irqflags.h 2008-04-02 18:30:21.000000000 +1100
@@ -2,30 +2,43 @@
* include/asm-powerpc/irqflags.h
*
* IRQ flags handling
- *
- * This file gets included from lowlevel asm headers too, to provide
- * wrapped versions of the local_irq_*() APIs, based on the
- * raw_local_irq_*() macros from the lowlevel headers.
*/
#ifndef _ASM_IRQFLAGS_H
#define _ASM_IRQFLAGS_H
+#ifndef __ASSEMBLY__
/*
* Get definitions for raw_local_save_flags(x), etc.
*/
#include <asm-powerpc/hw_irq.h>
+#else
+#ifdef CONFIG_TRACE_IRQFLAGS
/*
- * Do the CPU's IRQ-state tracing from assembly code. We call a
- * C function, so save all the C-clobbered registers:
+ * Most of the CPU's IRQ-state tracing is done from assembly code; we
+ * have to call a C function so call a wrapper that saves all the
+ * C-clobbered registers.
*/
-#ifdef CONFIG_TRACE_IRQFLAGS
-
-#error No support on PowerPC yet for CONFIG_TRACE_IRQFLAGS
-
+#define TRACE_ENABLE_INTS bl .trace_hardirqs_on
+#define TRACE_DISABLE_INTS bl .trace_hardirqs_off
+#define TRACE_AND_RESTORE_IRQ_PARTIAL(en,skip) \
+ cmpdi en, 0; \
+ bne 95f; \
+ stb en,PACASOFTIRQEN(r13); \
+ bl .trace_hardirqs_off; \
+ b skip; \
+95: bl .trace_hardirqs_on; \
+ li en,1;
+#define TRACE_AND_RESTORE_IRQ(en) \
+ TRACE_AND_RESTORE_IRQ_PARTIAL(en,96f); \
+96: stb en,PACASOFTIRQEN(r13)
#else
-# define TRACE_IRQS_ON
-# define TRACE_IRQS_OFF
+#define TRACE_ENABLE_INTS
+#define TRACE_DISABLE_INTS
+#define TRACE_AND_RESTORE_IRQ_PARTIAL(en,skip)
+#define TRACE_AND_RESTORE_IRQ(en) \
+ stb en,PACASOFTIRQEN(r13)
+#endif
#endif
#endif
Index: linux-work/include/asm-powerpc/rwsem.h
===================================================================
--- linux-work.orig/include/asm-powerpc/rwsem.h 2008-04-02 18:11:56.000000000 +1100
+++ linux-work/include/asm-powerpc/rwsem.h 2008-04-02 18:30:21.000000000 +1100
@@ -32,11 +32,20 @@ struct rw_semaphore {
#define RWSEM_ACTIVE_WRITE_BIAS (RWSEM_WAITING_BIAS + RWSEM_ACTIVE_BIAS)
spinlock_t wait_lock;
struct list_head wait_list;
+#ifdef CONFIG_DEBUG_LOCK_ALLOC
+ struct lockdep_map dep_map;
+#endif
};
+#ifdef CONFIG_DEBUG_LOCK_ALLOC
+# define __RWSEM_DEP_MAP_INIT(lockname) , .dep_map = { .name = #lockname }
+#else
+# define __RWSEM_DEP_MAP_INIT(lockname)
+#endif
+
#define __RWSEM_INITIALIZER(name) \
- { RWSEM_UNLOCKED_VALUE, SPIN_LOCK_UNLOCKED, \
- LIST_HEAD_INIT((name).wait_list) }
+ { RWSEM_UNLOCKED_VALUE, __SPIN_LOCK_UNLOCKED((name).wait_lock), \
+ LIST_HEAD_INIT((name).wait_list) __RWSEM_DEP_MAP_INIT(name) }
#define DECLARE_RWSEM(name) \
struct rw_semaphore name = __RWSEM_INITIALIZER(name)
@@ -46,12 +55,15 @@ extern struct rw_semaphore *rwsem_down_w
extern struct rw_semaphore *rwsem_wake(struct rw_semaphore *sem);
extern struct rw_semaphore *rwsem_downgrade_wake(struct rw_semaphore *sem);
-static inline void init_rwsem(struct rw_semaphore *sem)
-{
- sem->count = RWSEM_UNLOCKED_VALUE;
- spin_lock_init(&sem->wait_lock);
- INIT_LIST_HEAD(&sem->wait_list);
-}
+extern void __init_rwsem(struct rw_semaphore *sem, const char *name,
+ struct lock_class_key *key);
+
+#define init_rwsem(sem) \
+ do { \
+ static struct lock_class_key __key; \
+ \
+ __init_rwsem((sem), #sem, &__key); \
+ } while (0)
/*
* lock for reading
@@ -78,7 +90,7 @@ static inline int __down_read_trylock(st
/*
* lock for writing
*/
-static inline void __down_write(struct rw_semaphore *sem)
+static inline void __down_write_nested(struct rw_semaphore *sem, int subclass)
{
int tmp;
@@ -88,6 +100,11 @@ static inline void __down_write(struct r
rwsem_down_write_failed(sem);
}
+static inline void __down_write(struct rw_semaphore *sem)
+{
+ __down_write_nested(sem, 0);
+}
+
static inline int __down_write_trylock(struct rw_semaphore *sem)
{
int tmp;
Index: linux-work/include/asm-powerpc/spinlock.h
===================================================================
--- linux-work.orig/include/asm-powerpc/spinlock.h 2008-04-02 18:11:56.000000000 +1100
+++ linux-work/include/asm-powerpc/spinlock.h 2008-04-02 18:30:21.000000000 +1100
@@ -19,6 +19,7 @@
*
* (the type definitions are in asm/spinlock_types.h)
*/
+#include <linux/irqflags.h>
#ifdef CONFIG_PPC64
#include <asm/paca.h>
#include <asm/hvcall.h>
Index: linux-work/include/asm-powerpc/exception.h
===================================================================
--- linux-work.orig/include/asm-powerpc/exception.h 2008-04-02 18:11:56.000000000 +1100
+++ linux-work/include/asm-powerpc/exception.h 2008-04-02 18:30:21.000000000 +1100
@@ -228,18 +228,18 @@ label##_pSeries: \
BEGIN_FW_FTR_SECTION; \
stb r11,PACAHARDIRQEN(r13); \
END_FW_FTR_SECTION_IFCLR(FW_FEATURE_ISERIES); \
+ TRACE_DISABLE_INTS; \
BEGIN_FW_FTR_SECTION; \
mfmsr r10; \
ori r10,r10,MSR_EE; \
mtmsrd r10,1; \
END_FW_FTR_SECTION_IFSET(FW_FEATURE_ISERIES)
-
#else
#define DISABLE_INTS \
li r11,0; \
stb r11,PACASOFTIRQEN(r13); \
- stb r11,PACAHARDIRQEN(r13)
-
+ stb r11,PACAHARDIRQEN(r13); \
+ TRACE_DISABLE_INTS
#endif /* CONFIG_PPC_ISERIES */
#define ENABLE_INTS \
Index: linux-work/arch/powerpc/kernel/head_64.S
===================================================================
--- linux-work.orig/arch/powerpc/kernel/head_64.S 2008-04-02 18:24:45.000000000 +1100
+++ linux-work/arch/powerpc/kernel/head_64.S 2008-04-02 18:30:21.000000000 +1100
@@ -36,8 +36,7 @@
#include <asm/firmware.h>
#include <asm/page_64.h>
#include <asm/exception.h>
-
-#define DO_SOFT_DISABLE
+#include <asm/irqflags.h>
/*
* We layout physical memory as follows:
@@ -450,8 +449,8 @@ bad_stack:
*/
fast_exc_return_irq: /* restores irq state too */
ld r3,SOFTE(r1)
+ TRACE_AND_RESTORE_IRQ(r3);
ld r12,_MSR(r1)
- stb r3,PACASOFTIRQEN(r13) /* restore paca->soft_enabled */
rldicl r4,r12,49,63 /* get MSR_EE to LSB */
stb r4,PACAHARDIRQEN(r13) /* restore paca->hard_enabled */
b 1f
@@ -808,7 +807,7 @@ _STATIC(load_up_altivec)
* Hash table stuff
*/
.align 7
-_GLOBAL(do_hash_page)
+_STATIC(do_hash_page)
std r3,_DAR(r1)
std r4,_DSISR(r1)
@@ -820,6 +819,27 @@ BEGIN_FTR_SECTION
END_FTR_SECTION_IFCLR(CPU_FTR_SLB)
/*
+ * On iSeries, we soft-disable interrupts here, then
+ * hard-enable interrupts so that the hash_page code can spin on
+ * the hash_table_lock without problems on a shared processor.
+ */
+ DISABLE_INTS
+
+ /*
+ * Currently, trace_hardirqs_off() will be called by DISABLE_INTS
+ * and will clobber volatile registers when irq tracing is enabled
+ * so we need to reload them. It may be possible to be smarter here
+ * and move the irq tracing elsewhere but let's keep it simple for
+ * now
+ */
+#ifdef CONFIG_TRACE_IRQFLAGS
+ ld r3,_DAR(r1)
+ ld r4,_DSISR(r1)
+ ld r5,_TRAP(r1)
+ ld r12,_MSR(r1)
+ clrrdi r5,r5,4
+#endif /* CONFIG_TRACE_IRQFLAGS */
+ /*
* We need to set the _PAGE_USER bit if MSR_PR is set or if we are
* accessing a userspace segment (even from the kernel). We assume
* kernel addresses always have the high bit set.
@@ -832,13 +852,6 @@ END_FTR_SECTION_IFCLR(CPU_FTR_SLB)
rlwimi r4,r5,22+2,31-2,31-2 /* Set _PAGE_EXEC if trap is 0x400 */
/*
- * On iSeries, we soft-disable interrupts here, then
- * hard-enable interrupts so that the hash_page code can spin on
- * the hash_table_lock without problems on a shared processor.
- */
- DISABLE_INTS
-
- /*
* r3 contains the faulting address
* r4 contains the required access permissions
* r5 contains the trap number
@@ -848,7 +861,6 @@ END_FTR_SECTION_IFCLR(CPU_FTR_SLB)
bl .hash_page /* build HPTE if possible */
cmpdi r3,0 /* see if hash_page succeeded */
-#ifdef DO_SOFT_DISABLE
BEGIN_FW_FTR_SECTION
/*
* If we had interrupts soft-enabled at the point where the
@@ -860,7 +872,7 @@ BEGIN_FW_FTR_SECTION
*/
beq 13f
END_FW_FTR_SECTION_IFSET(FW_FEATURE_ISERIES)
-#endif
+
BEGIN_FW_FTR_SECTION
/*
* Here we have interrupts hard-disabled, so it is sufficient
@@ -874,11 +886,12 @@ END_FW_FTR_SECTION_IFCLR(FW_FEATURE_ISER
/*
* hash_page couldn't handle it, set soft interrupt enable back
- * to what it was before the trap. Note that .local_irq_restore
+ * to what it was before the trap. Note that .raw_local_irq_restore
* handles any interrupts pending at this point.
*/
ld r3,SOFTE(r1)
- bl .local_irq_restore
+ TRACE_AND_RESTORE_IRQ_PARTIAL(r3, 11f)
+ bl .raw_local_irq_restore
b 11f
/* Here we have a page fault that hash_page can't handle. */
@@ -1477,6 +1490,10 @@ _INIT_STATIC(start_here_multiplatform)
addi r2,r2,0x4000
add r2,r2,r26
+ /* Set initial ptr to current */
+ LOAD_REG_IMMEDIATE(r4, init_task)
+ std r4,PACACURRENT(r13)
+
/* Do very early kernel initializations, including initial hash table,
* stab and slb setup before we turn on relocation. */
Index: linux-work/arch/powerpc/kernel/setup_64.c
===================================================================
--- linux-work.orig/arch/powerpc/kernel/setup_64.c 2008-04-02 18:28:32.000000000 +1100
+++ linux-work/arch/powerpc/kernel/setup_64.c 2008-04-02 18:30:21.000000000 +1100
@@ -33,6 +33,7 @@
#include <linux/serial_8250.h>
#include <linux/bootmem.h>
#include <linux/pci.h>
+#include <linux/lockdep.h>
#include <asm/io.h>
#include <asm/kdump.h>
#include <asm/prom.h>
@@ -178,6 +179,9 @@ void __init early_setup(unsigned long dt
/* Enable early debugging if any specified (see udbg.h) */
udbg_early_init();
+ /* Initialize lockdep early or else spinlocks will blow */
+ lockdep_init();
+
DBG(" -> early_setup(), dt_ptr: 0x%lx\n", dt_ptr);
/*
Index: linux-work/arch/powerpc/kernel/entry_64.S
===================================================================
--- linux-work.orig/arch/powerpc/kernel/entry_64.S 2008-04-02 18:11:56.000000000 +1100
+++ linux-work/arch/powerpc/kernel/entry_64.S 2008-04-02 18:30:21.000000000 +1100
@@ -29,6 +29,7 @@
#include <asm/cputable.h>
#include <asm/firmware.h>
#include <asm/bug.h>
+#include <asm/irqflags.h>
/*
* System calls.
@@ -88,6 +89,14 @@ system_call_common:
addi r9,r1,STACK_FRAME_OVERHEAD
ld r11,exception_marker@toc(r2)
std r11,-16(r9) /* "regshere" marker */
+#ifdef CONFIG_TRACE_IRQFLAGS
+ bl .trace_hardirqs_on
+ REST_GPR(0,r1)
+ REST_4GPRS(3,r1)
+ REST_2GPRS(7,r1)
+ addi r9,r1,STACK_FRAME_OVERHEAD
+ ld r12,_MSR(r1)
+#endif /* CONFIG_TRACE_IRQFLAGS */
li r10,1
stb r10,PACASOFTIRQEN(r13)
stb r10,PACAHARDIRQEN(r13)
@@ -102,7 +111,7 @@ BEGIN_FW_FTR_SECTION
b hardware_interrupt_entry
2:
END_FW_FTR_SECTION_IFSET(FW_FEATURE_ISERIES)
-#endif
+#endif /* CONFIG_PPC_ISERIES */
mfmsr r11
ori r11,r11,MSR_EE
mtmsrd r11,1
@@ -504,6 +513,10 @@ BEGIN_FW_FTR_SECTION
li r3,0
stb r3,PACASOFTIRQEN(r13) /* ensure we are soft-disabled */
+#ifdef CONFIG_TRACE_IRQFLAGS
+ bl .trace_hardirqs_off
+ mfmsr r10
+#endif
ori r10,r10,MSR_EE
mtmsrd r10 /* hard-enable again */
addi r3,r1,STACK_FRAME_OVERHEAD
@@ -512,7 +525,7 @@ BEGIN_FW_FTR_SECTION
4:
END_FW_FTR_SECTION_IFSET(FW_FEATURE_ISERIES)
#endif
- stb r5,PACASOFTIRQEN(r13)
+ TRACE_AND_RESTORE_IRQ(r5);
/* extract EE bit and use it to restore paca->hard_enabled */
ld r3,_MSR(r1)
@@ -580,6 +593,16 @@ do_work:
bne restore
/* here we are preempting the current task */
1:
+#ifdef CONFIG_TRACE_IRQFLAGS
+ bl .trace_hardirqs_on
+ /* Note: we just clobbered r10 which used to contain the previous
+ * MSR before the hard-disabling done by the caller of do_work.
+ * We don't have that value anymore, but it doesn't matter as
+ * we will hard-enable unconditionally, we can just reload the
+ * current MSR into r10
+ */
+ mfmsr r10
+#endif /* CONFIG_TRACE_IRQFLAGS */
li r0,1
stb r0,PACASOFTIRQEN(r13)
stb r0,PACAHARDIRQEN(r13)
^ permalink raw reply
* Re: SecretLab Git Server
From: Peter Korsgaard @ 2008-04-02 9:49 UTC (permalink / raw)
To: Grant Likely; +Cc: Sam Karp, linuxppc-embedded
In-Reply-To: <fa686aa40804012117s45d70c1by964d2e54fa097d1@mail.gmail.com>
>>>>> "Grant" == Grant Likely <grant.likely@secretlab.ca> writes:
Grant> On Mon, Mar 31, 2008 at 8:12 PM, Sam Karp <sam.d.karp@gmail.com> wrote:
>> Any idea of other sources where else I could get either a kernel with the
>> USB driver or a standalone driver for the Xilinx ML403 board?
Grant> Look on the powerpc mailing list archives for Peter Korsgaard's patch
Grant> set for the c67x00. (I believe v10 is the latest patch set).
You can also get them from my homepage:
http://peter.korsgaard.com/patches/linux/c67x00-10-*.patch
I'll send an updated series in a few days.
Grant> You need to use the mailing list archive instead of patchwork. For
Grant> some reason patchwork doesn't recognize Peter's patches.
Yeah, I don't know what I'm doing wrong - Maybe it simply doesn't like
me? ;)
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH 0/4] [POWERPC] lockdep support for ppc64
From: Johannes Berg @ 2008-04-02 9:50 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1207122728.672673.111194574046.qpush@grosgo>
[-- Attachment #1: Type: text/plain, Size: 230 bytes --]
> This serie of patches adds lockdep support for 64 bits
> powerpc. Dale's patch for 32 bits still need me to review
> and test it which I'll try to do asap.
Yay. I'll give it another try later today.
Thanks,
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: Virtex V5FX PPC 440 Support In Xilinx Git Tree
From: Peter Korsgaard @ 2008-04-02 9:51 UTC (permalink / raw)
To: John Linn; +Cc: git, linuxppc-embedded
In-Reply-To: <20080401234142.41B13191804A@mail111-sin.bigfish.com>
>>>>> "John" == John Linn <John.Linn@xilinx.com> writes:
John> I pushed PowerPC 440 support to the Xilinx Git server with
John> support for ppc arch and with powerpc arch support coming in
John> the near future.
Neat, but why have you added arch/ppc support? It's supposed to go
away pretty much by the time the hardware gets in the hand of
developers.
--
Bye, Peter Korsgaard
^ 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