* Re: [PATCH] RTAS - adapt procfs interface
From: Nathan Lynch @ 2008-04-01 16:35 UTC (permalink / raw)
To: Jens Osterkamp; +Cc: maxim, linuxppc-dev, Paul Mackerras, cbe-oss-dev
In-Reply-To: <200804011512.20834.jens@de.ibm.com>
Jens Osterkamp wrote:
>
> Handling of the proc_dir_entry->count has being changed in 2.6.24-rc5.
Do you know which commit caused the change?
> After this change the default value for pde->count is 1 and not 0 as it
> was in earlier kernels. Therefore, if we want to check wether our procfs
> file is already opened (already in use), we have to check if pde->count
> is not greater than 2 but not 1.
>
> Signed-off-by: Maxim Shchetynin <maxim@de.ibm.com>
> Signed-off-by: Jens Osterkamp <jens@de.ibm.com>
>
> Index: linux-2.6/arch/powerpc/kernel/rtas_flash.c
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/kernel/rtas_flash.c
> +++ linux-2.6/arch/powerpc/kernel/rtas_flash.c
> @@ -356,7 +356,7 @@ static int rtas_excl_open(struct inode *
>
> /* Enforce exclusive open with use count of PDE */
> spin_lock(&flash_file_open_lock);
> - if (atomic_read(&dp->count) > 1) {
> + if (atomic_read(&dp->count) > 2) {
> spin_unlock(&flash_file_open_lock);
> return -EBUSY;
> }
One could argue that the real problem is using the proc_dir_entry's
reference count to enforce exclusive open.
^ permalink raw reply
* RE: xilinx Ml405 NFS mount problem
From: John Linn @ 2008-04-01 16:53 UTC (permalink / raw)
To: Robert Woodworth, MingLiu; +Cc: linuxppc-embedded
In-Reply-To: <1207068618.4830.60.camel@PisteOff>
Now that you say that, I have been running TCP with my NFS mount as I'm =
mounting across a corporate network.
I am also using the latest LL TEMAC with EDK 10.1.
Thanks,
John
-----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
I think you may be suffering from the latest LL_TEMAC packet loss
problem. (NFS/UDP really does not like packet loss)
Let me guess. =20
You are using a base system from "Base System Builder Wizard"?
EDK 9.2i. Default syntheses/P&R options.
I have seen a massive packet loss problems on my ML403 and two other
boards I have with an FX60.
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.
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
Are you on a GigE switch?
Rob.
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
^ permalink raw reply
* RE: xilinx Ml405 NFS mount problem
From: Robert Woodworth @ 2008-04-01 16:50 UTC (permalink / raw)
To: MingLiu; +Cc: John Linn, linuxppc-embedded
In-Reply-To: <BAY138-W40E4E945BA6E40EABEE811B2F50@phx.gbl>
I think you may be suffering from the latest LL_TEMAC packet loss
problem. (NFS/UDP really does not like packet loss)
Let me guess.
You are using a base system from "Base System Builder Wizard"?
EDK 9.2i. Default syntheses/P&R options.
I have seen a massive packet loss problems on my ML403 and two other
boards I have with an FX60.
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.
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.
Are you on a GigE switch?
Rob.
On Tue, 2008-04-01 at 16:15 +0000, MingLiu wrote:
> Dear John,
>
> Thank you for your replying.
>
> >It’s not obvious to me what the problem is as I don’t see any driver
> failures. Have you >tried using a ramdisk and then seeing if the
> network is working before using NFS root?
>
> Not yet. I will try it soon. However from the information on the
> LL_TEMAC, it seems everything is fine and it should work.
>
>
>
> >And I’m assuming you have used the NFS root before so you know that
> it’s good for sure.
>
>
>
> >I test on the ML405 with NFS root and haven’t seen this problem, but
> my setup is a little different. I use DHCP rather than >a static IP,
> but other than that it’s similar.
>
>
>
> 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.
>
>
>
> >How long has it been since you pulled from the Xilinx Git tree?
>
>
>
> I just pulled the Xilinx tree quite recently. I am using a latest
> kernel.
>
>
>
> BR
>
> Ming
>
>
>
>
>
> And I’m assuming you have used the NFS root before so you know
> that it’s good for sure.
>
>
>
> I test on the ML405 with NFS root and haven’t seen this
> problem, but my setup is a little different. I use DHCP
> rather than a static IP, but other than that it’s similar.
>
>
>
> I’m assuming that you accidentally got 2 different powerup
> outputs in the message below as the 1st stops and a 2nd starts
> in the middle.
>
>
>
> How long has it been since you pulled from the Xilinx Git
> tree?
>
>
>
> Thanks,
>
> John
>
>
>
>
> ______________________________________________________________
> From: linuxppc-embedded-bounces
> +john.linn=xilinx.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces
> +john.linn=xilinx.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
>
>
>
>
> Dear friends,
>
> 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.
> Thanks a lot!
>
>
> loaded at: 00400000 0059F19C
> board data at: 0059D120 0059D19C
> relocated to: 004050C8 00405144
> zimage at: 00405F3F 0059C025
> avail ram: 005A0000 08000000
>
> Linux/PPC load: root=/dev/nfs
> ip=192.168.0.4:192.168.0.3:192.168.0.3:255.255.255.0 rw
> nfsroot=192.168.0.3:/home/mingliu/ml403_rootfs console=ttyUL0,38400
> mem=32M
> 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
>
> Normal 8192 -> 8192
>
> 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=/de v/nfs
> ip=192.168.0.4:192.168.0.3:192.168.0.3:255.255.255.0 rw
> nfsroot=192.168.0.3:/home/mingliu/ml403_rootfs console=ttyUL0,38400
> mem=32M
> 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=11, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1
> 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 = 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=2
> 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
>
> Xilinx Generic PowerPC board support package (Xilinx ML405)
> (Virtex-4 FX)
>
> 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=/dev/nfs
> ip=192.168.0.4:192.168.0.3:192.168.0.3:255.255.255.0 rw
> nfsroot=192.168.0.3:/home/mingliu/ml403_rootfs console=ttyUL0,38400
> mem=32M
> 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=11, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1
> 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 = 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="FONT-SIZE: 12pt">to 0xC3004000, irq=2
> 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 = 24, Receive Threshold = 4
> eth0: XLlTemac: Send Wait bound = 254, Receive Wait bound = 254
> IP-Config: Complete:
>
> device=eth0, addr=192.168.0.4, mask=255.255.255.0, gw=192.168.0.3,
> host=192.168.0.4, domain=, nis-domain=(none),
> bootserver=192.168.0.3, rootserver=192.168.0.3, rootpath=
> 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=" boot option; here are
> the available
> partitions:
> Kernel panic - not syncing: VFS: Unable to mount root fs on
> unknown-block(2,0)
> Rebooting in 180 seconds..
>
>
> BR
> Ming
>
>
>
>
> ______________________________________________________________
> Windows Live Writer，支持离线撰写博客内容，随时随地想写就写。
> 立即使用！
>
>
>
>
> ______________________________________________________________________
> 使用新一代 Windows Live Messenger 轻松交流和共享！ 立即体验！
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: Unable to handle kernel paging request for instruction fetch???
From: Scott Wood @ 2008-04-01 17:09 UTC (permalink / raw)
To: 郭劲; +Cc: linuxppc-embedded
In-Reply-To: <407023539.21267@tsinghua.org.cn>
郭劲 wrote:
> Hi,all,
>
> I run the iperf tool to test the ethernet throughput for my MPC8360E board, after
> about 20 minutes, the exception is happened. Could you tell me why?
>
>
> Unable to handle kernel paging request for instruction fetch
> Faulting instruction address: 0x4e800020
> Oops: Kernel access of bad area, sig: 11 [#1]
> MPC836x MDS
> Modules linked in: encoder mpc_sync k_spi(P)
Can you reproduce it with kallsyms enabled, and without the out-of-tree
module(s)?
> NIP: 4e800020 LR: c01a08d4 CTR: 00000000
Something branched to a bad address from 0xc01a08d0. Can you look up
what line that is in your kernel?
-Scott
^ permalink raw reply
* mpc52xx_mmap_ctl access
From: Marcelo Dalmas @ 2008-04-01 17:03 UTC (permalink / raw)
To: linuxppc-embedded
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?
Thank you,
Marcelo Dalmas
Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento!
http://br.mail.yahoo.com/
^ permalink raw reply
* [PATCH 2/8] powerpc: replace `__attribute' by `__attribute__'
From: Roel Kluin @ 2008-04-01 17:31 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, trivial, lkml
In-Reply-To: <47F26FF6.8070300@tiscali.nl>
replace `__attribute' by `__attribute__'
Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
---
diff --git a/arch/powerpc/platforms/iseries/main_store.h b/arch/powerpc/platforms/iseries/main_store.h
index 1a7a3f5..976b23e 100644
--- a/arch/powerpc/platforms/iseries/main_store.h
+++ b/arch/powerpc/platforms/iseries/main_store.h
@@ -61,7 +61,7 @@ struct IoHriMainStoreSegment4 {
};
/* Main Store VPD for Power4 */
-struct __attribute((packed)) IoHriMainStoreChipInfo1 {
+struct __attribute__((packed)) IoHriMainStoreChipInfo1 {
u32 chipMfgID;
char chipECLevel[4];
};
@@ -73,14 +73,14 @@ struct IoHriMainStoreVpdIdData {
char serialNumber[12];
};
-struct __attribute((packed)) IoHriMainStoreVpdFruData {
+struct __attribute__((packed)) IoHriMainStoreVpdFruData {
char fruLabel[8];
u8 numberOfSlots;
u8 pluggingType;
u16 slotMapIndex;
};
-struct __attribute((packed)) IoHriMainStoreAdrRangeBlock {
+struct __attribute__((packed)) IoHriMainStoreAdrRangeBlock {
void *blockStart;
void *blockEnd;
u32 blockProcChipId;
@@ -88,7 +88,7 @@ struct __attribute((packed)) IoHriMainStoreAdrRangeBlock {
#define MaxAreaAdrRangeBlocks 4
-struct __attribute((packed)) IoHriMainStoreArea4 {
+struct __attribute__((packed)) IoHriMainStoreArea4 {
u32 msVpdFormat;
u8 containedVpdType;
u8 reserved1;
^ permalink raw reply related
* Re: [PATCH 2/8] powerpc: replace `__attribute' by `__attribute__'
From: Sam Ravnborg @ 2008-04-01 18:01 UTC (permalink / raw)
To: Roel Kluin; +Cc: trivial, linuxppc-dev, paulus, lkml
In-Reply-To: <47F27155.1000103@tiscali.nl>
On Tue, Apr 01, 2008 at 07:31:01PM +0200, Roel Kluin wrote:
> replace `__attribute' by `__attribute__'
>
> Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
> ---
> diff --git a/arch/powerpc/platforms/iseries/main_store.h b/arch/powerpc/platforms/iseries/main_store.h
> index 1a7a3f5..976b23e 100644
> --- a/arch/powerpc/platforms/iseries/main_store.h
> +++ b/arch/powerpc/platforms/iseries/main_store.h
> @@ -61,7 +61,7 @@ struct IoHriMainStoreSegment4 {
> };
>
> /* Main Store VPD for Power4 */
> -struct __attribute((packed)) IoHriMainStoreChipInfo1 {
> +struct __attribute__((packed)) IoHriMainStoreChipInfo1 {
> u32 chipMfgID;
> char chipECLevel[4];
> };
Please introduce __packed if you touch this.
See include/linux/compiler-gcc.h
This comment is relevant for all your patches.
We have __used and other similar variants.
So take a good look at include/linux/compiler* and
use the proper shortcuts where available.
Sam
^ permalink raw reply
* RE: xilinx Ml405 NFS mount problem
From: MingLiu @ 2008-04-01 18:36 UTC (permalink / raw)
To: Robert Woodworth; +Cc: John Linn, linuxppc-embedded
In-Reply-To: <1207068618.4830.60.camel@PisteOff>
[-- Attachment #1: Type: text/plain, Size: 2333 bytes --]
Dear Robert> Let me guess. > You are using a base system from "Base System Builder Wizard"?> EDK 9.2i. Default syntheses/P&R options.
I am using EDK 10.1 evaluation version (60 days) from Xilinx. I don't have experience on EDK 9.2 and previously I was working on EDK 8.2.
> I have seen a massive packet loss problems on my ML403 and two other> boards I have with an FX60.> > 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.
I got the following message from my NFS server PC:
Apr 1 15:08:34 linux kernel: UDP: bad checksum. From 192.168.0.4:839 to
192.168.0.3:627 ulen 48
Apr 1 15:08:40 linux kernel: UDP: bad checksum. From 192.168.0.4:839 to
192.168.0.3:627 ulen 48
Apr 1 15:08:49 linux kernel: UDP: bad checksum. From 192.168.0.4:839 to
192.168.0.3:627 ulen 48
Apr 1 15:13:23 linux kernel: nfsd: last server has exited
Apr 1 15:13:23 linux kernel: nfsd: unexporting all filesystems
Apr 1 15:13:23 linux rpc.mountd: Caught signal 15, un-registering and
exiting.
Apr 1 15:13:24 linux kernel: NFSD: Using /var/lib/nfs/v4recovery as the
NFSv4 state recovery directory
Apr 1 15:13:24 linux kernel: NFSD: recovery directory
/var/lib/nfs/v4recovery doesn't exist
Apr 1 15:13:24 linux kernel: NFSD: starting 90-second grace period
Apr 1 16:02:57 linux syslog-ng[3700]: STATS: dropped 0
Apr 1 17:02:57 linux syslog-ng[3700]: STATS: dropped 0
Apr 1 18:02:58 linux syslog-ng[3700]: STATS: dropped 0
I shows "UDP bad checksum" from my board to the PC. I don't know if it has something to do with the package loss problem.
> 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.
I connect the board with the PC point-to-point with gigabit ethernet. It should be even better than a Gigabit switch, right?
BR
Ming
_________________________________________________________________
Windows Live Photo gallery 数码相机的超级伴侣，轻松管理和编辑照片，还能制作全景美图！
http://get.live.cn/product/photo.html
[-- Attachment #2: Type: text/html, Size: 2638 bytes --]
^ permalink raw reply
* Re: [PATCHv4 0/5] cpm2: Reset the CPM at startup and fix the cpm_uart driver accordingly.
From: Scott Wood @ 2008-04-01 19:19 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-dev
In-Reply-To: <200804011433.29841.laurentp@cse-semaphore.com>
Laurent Pinchart wrote:
> Hi everybody,
>
> these 5 patches reset the CPM in cpm2_reset() and fix the cpm_uart driver to
> initialise SMC ports correctly without relying on any initialisation
> performed by the boot loader/wrapper. They update the boot wrapper code and
> the EP8248E device tree to match the new SMC registers description.
>
> Patches 2/5, 3/5 and 4/5 (boot wrapper and EP8248E device tree updates)
> haven't been tested due to lack of hardware.
Tested OK on ep8248e.
ACK 1-5
-Scott
^ permalink raw reply
* [PATCH / RFC 2/2] ISP1760: bus glue code
From: Sebastian Siewior @ 2008-04-01 19:52 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linuxppc-dev, Thomas Gleixner, linux-usb
In-Reply-To: <20080401195158.657955430@linutronix.de>
This patch contains the entry for the build system and glue code for the
platform bus. Currently OpenFirmware and PCI is supported.
Signed-off-by: Sebastian Siewior <bigeasy@linutronix.de>
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -95,6 +95,32 @@ config USB_ISP116X_HCD
To compile this driver as a module, choose M here: the
module will be called isp116x-hcd.
+config USB_ISP1760_HCD
+ tristate "ISP 1760 HCD support"
+ depends on USB && EXPERIMENTAL
+ ---help---
+ The ISP1760 chip is a USB 2.0 host controller.
+
+ This driver does not support isochronous transfers or OTG.
+
+ To compile this driver as a module, choose M here: the
+ module will be called isp1760-hcd.
+
+config USB_ISP1760_PCI
+ bool "Support for the PCI bus"
+ depends on USB_ISP1760_HCD && PCI
+ ---help---
+ Enables support for the device present on the PCI bus.
+ This should only be required if you happen to have the eval kit from
+ NXP and you are going to test it.
+
+config USB_ISP1760_OF
+ bool "Support for the OF platform bus"
+ depends on USB_ISP1760_HCD && OF
+ ---help---
+ Enables support for the device present on the PowerPC
+ OpenFirmware platform bus.
+
config USB_OHCI_HCD
tristate "OHCI HCD support"
depends on USB && USB_ARCH_HAS_OHCI
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -6,6 +6,8 @@ ifeq ($(CONFIG_USB_DEBUG),y)
EXTRA_CFLAGS += -DDEBUG
endif
+isp1760-objs := isp1760-hcd.o isp1760-if.o
+
obj-$(CONFIG_PCI) += pci-quirks.o
obj-$(CONFIG_USB_EHCI_HCD) += ehci-hcd.o
@@ -16,4 +18,4 @@ obj-$(CONFIG_USB_SL811_HCD) += sl811-hcd
obj-$(CONFIG_USB_SL811_CS) += sl811_cs.o
obj-$(CONFIG_USB_U132_HCD) += u132-hcd.o
obj-$(CONFIG_USB_R8A66597_HCD) += r8a66597-hcd.o
-
+obj-$(CONFIG_USB_ISP1760_HCD) += isp1760.o
--- /dev/null
+++ b/drivers/usb/host/isp1760-if.c
@@ -0,0 +1,294 @@
+/*
+ * Glue code for the ISP1760 driver and bus
+ * Currently there is support for
+ * - OpenFirmware
+ * - PCI
+ *
+ * (c) 2007 Sebastian Siewior <bigeasy@linutronix.de>
+ *
+ */
+
+#include <linux/usb.h>
+#include <linux/io.h>
+
+#include "../core/hcd.h"
+#include "isp1760-hcd.h"
+
+#ifdef CONFIG_USB_ISP1760_OF
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#endif
+
+#ifdef CONFIG_USB_ISP1760_PCI
+#include <linux/pci.h>
+#endif
+
+#ifdef CONFIG_USB_ISP1760_OF
+static int of_isp1760_probe(struct of_device *dev,
+ const struct of_device_id *match)
+{
+ struct usb_hcd *hcd;
+ struct device_node *dp = dev->node;
+ struct resource *res;
+ struct resource memory;
+ struct of_irq oirq;
+ int virq;
+ u64 res_len;
+ int ret;
+
+ ret = of_address_to_resource(dp, 0, &memory);
+ if (ret)
+ return -ENXIO;
+
+ res = request_mem_region(memory.start, memory.end - memory.start + 1,
+ dev->dev.bus_id);
+ if (!res)
+ return -EBUSY;
+
+ res_len = memory.end - memory.start + 1;
+
+ if (of_irq_map_one(dp, 0, &oirq)) {
+ ret = -ENODEV;
+ goto release_reg;
+ }
+
+ virq = irq_create_of_mapping(oirq.controller, oirq.specifier,
+ oirq.size);
+
+ hcd = isp1760_register(memory.start, res_len, virq,
+ IRQF_SHARED | IRQF_DISABLED, &dev->dev, dev->dev.bus_id);
+ if (IS_ERR(hcd)) {
+ ret = PTR_ERR(hcd);
+ goto release_reg;
+ }
+
+ dev_set_drvdata(&dev->dev, hcd);
+ return ret;
+
+release_reg:
+ release_mem_region(memory.start, memory.end - memory.start + 1);
+ return ret;
+}
+
+static int of_isp1760_remove(struct of_device *dev)
+{
+ struct usb_hcd *hcd = dev_get_drvdata(&dev->dev);
+
+ dev_set_drvdata(&dev->dev, NULL);
+
+ usb_remove_hcd(hcd);
+ iounmap(hcd->regs);
+ release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
+ usb_put_hcd(hcd);
+ return 0;
+}
+
+static struct of_device_id of_isp1760_match[] = {
+ {
+ .compatible = "nxp,usb-isp1760",
+ },
+ { },
+};
+MODULE_DEVICE_TABLE(of, of_isp1760_match);
+
+static struct of_platform_driver isp1760_of_driver = {
+ .name = "nxp-isp1760",
+ .match_table = of_isp1760_match,
+ .probe = of_isp1760_probe,
+ .remove = of_isp1760_remove,
+};
+#endif
+
+#ifdef CONFIG_USB_ISP1760_PCI
+static u32 nxp_pci_io_base;
+static u32 iolength;
+static u32 pci_mem_phy0;
+static u32 length;
+static u8 *chip_addr;
+static u8 *iobase;
+
+static int __devinit isp1761_pci_probe(struct pci_dev *dev,
+ const struct pci_device_id *id)
+{
+ u8 latency, limit;
+ __u32 reg_data;
+ int retry_count;
+ int length;
+ int status = 1;
+ struct usb_hcd *hcd;
+
+ if (usb_disabled())
+ return -ENODEV;
+
+ if (pci_enable_device(dev) < 0)
+ return -ENODEV;
+
+ if (!dev->irq)
+ return -ENODEV;
+
+ /* Grab the PLX PCI mem maped port start address we need */
+ nxp_pci_io_base = pci_resource_start(dev, 0);
+ iolength = pci_resource_len(dev, 0);
+
+ if (!request_mem_region(nxp_pci_io_base, iolength, "ISP1761 IO MEM")) {
+ printk(KERN_ERR "request region #1\n");
+ return -EBUSY;
+ }
+
+ iobase = ioremap_nocache(nxp_pci_io_base, iolength);
+ if (!iobase) {
+ printk(KERN_ERR "ioremap #1\n");
+ release_mem_region(nxp_pci_io_base, iolength);
+ return -ENOMEM;
+ }
+ /* Grab the PLX PCI shared memory of the ISP 1761 we need */
+ pci_mem_phy0 = pci_resource_start(dev, 3);
+ length = pci_resource_len(dev, 3);
+
+ if (length < 0xffff) {
+ printk(KERN_ERR "memory length for this resource is less than "
+ "required\n");
+ release_mem_region(nxp_pci_io_base, iolength);
+ iounmap(iobase);
+ return -ENOMEM;
+ }
+
+ if (!request_mem_region(pci_mem_phy0, length, "ISP-PCI")) {
+ printk(KERN_ERR "host controller already in use\n");
+ release_mem_region(nxp_pci_io_base, iolength);
+ iounmap(iobase);
+ return -EBUSY;
+ }
+
+ /* bad pci latencies can contribute to overruns */
+ pci_read_config_byte(dev, PCI_LATENCY_TIMER, &latency);
+ if (latency) {
+ pci_read_config_byte(dev, PCI_MAX_LAT, &limit);
+ if (limit && limit < latency)
+ pci_write_config_byte(dev, PCI_LATENCY_TIMER, limit);
+ }
+
+ /* Try to check whether we can access Scratch Register of
+ * Host Controller or not. The initial PCI access is retried until
+ * local init for the PCI bridge is completed
+ */
+ retry_count = 20;
+ reg_data = 0;
+ while ((reg_data != 0xFACE) && retry_count) {
+ /*by default host is in 16bit mode, so
+ * io operations at this stage must be 16 bit
+ * */
+ writel(0xface, chip_addr + HC_SCRATCH_REG);
+ udelay(100);
+ reg_data = readl(chip_addr + HC_SCRATCH_REG);
+ retry_count--;
+ }
+
+ /* Host Controller presence is detected by writing to scratch register
+ * and reading back and checking the contents are same or not
+ */
+ if (reg_data != 0xFACE) {
+ err("scratch register mismatch %x", reg_data);
+ goto clean;
+ }
+
+ pci_set_master(dev);
+
+ status = readl(iobase + 0x68);
+ status |= 0x900;
+ writel(status, iobase + 0x68);
+
+ dev->dev.dma_mask = NULL;
+ hcd = isp1760_register(pci_mem_phy0, length, dev->irq,
+ IRQF_SHARED | IRQF_DISABLED, &dev->dev, dev->dev.bus_id);
+ pci_set_drvdata(dev, hcd);
+ if (!hcd)
+ return 0;
+clean:
+ status = -ENODEV;
+ iounmap(iobase);
+ release_mem_region(pci_mem_phy0, length);
+ release_mem_region(nxp_pci_io_base, iolength);
+ return status;
+}
+static void isp1761_pci_remove(struct pci_dev *dev)
+{
+ struct usb_hcd *hcd;
+
+ hcd = pci_get_drvdata(dev);
+
+ usb_remove_hcd(hcd);
+ iounmap(hcd->regs);
+ release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
+ usb_put_hcd(hcd);
+
+ pci_disable_device(dev);
+
+ iounmap(iobase);
+ iounmap(chip_addr);
+
+ release_mem_region(nxp_pci_io_base, iolength);
+ release_mem_region(pci_mem_phy0, length);
+}
+
+static void ips1761_pci_shutdown(struct pci_dev *dev)
+{
+ printk(KERN_ERR "ips1761_pci_shutdown\n");
+}
+
+static const struct pci_device_id ips1760_plx [] = { {
+ /* handle any USB 2.0 EHCI controller */
+ PCI_DEVICE_CLASS(((PCI_CLASS_BRIDGE_OTHER << 8) | (0x06 << 16)), ~0),
+ .driver_data = 0,
+},
+{ /* end: all zeroes */ }
+};
+MODULE_DEVICE_TABLE(pci, ips1760_plx);
+
+static struct pci_driver isp1761_pci_driver = {
+ .name = "isp1760",
+ .id_table = ips1760_plx,
+ .probe = isp1761_pci_probe,
+ .remove = isp1761_pci_remove,
+ .shutdown = ips1761_pci_shutdown,
+};
+#endif
+
+static int __init isp1760_init(void)
+{
+ int ret;
+
+ init_kmem_once();
+
+#ifdef CONFIG_USB_ISP1760_OF
+ ret = of_register_platform_driver(&isp1760_of_driver);
+ if (ret) {
+ deinit_kmem_cache();
+ return ret;
+ }
+#endif
+
+#ifdef CONFIG_USB_ISP1760_PCI
+ ret = pci_register_driver(&isp1761_pci_driver);
+ if (ret) {
+#ifdef CONFIG_USB_ISP1760_OF
+ of_unregister_platform_driver(&isp1760_of_driver);
+#endif
+ deinit_kmem_cache();
+ }
+#endif
+ return ret;
+}
+module_init(isp1760_init);
+
+static void __exit isp1760_exit(void)
+{
+#ifdef CONFIG_USB_ISP1760_OF
+ of_unregister_platform_driver(&isp1760_of_driver);
+#endif
+#ifdef CONFIG_USB_ISP1760_PCI
+ pci_unregister_driver(&isp1761_pci_driver);
+#endif
+ deinit_kmem_cache();
+}
+module_exit(isp1760_exit);
--
^ permalink raw reply
* Re: [PATCH] RTAS - adapt procfs interface
From: Nathan Lynch @ 2008-04-01 20:04 UTC (permalink / raw)
To: Jens Osterkamp; +Cc: maxim, linuxppc-dev, Paul Mackerras, cbe-oss-dev
In-Reply-To: <20080401163504.GP7137@localdomain>
Nathan Lynch wrote:
>
> One could argue that the real problem is using the proc_dir_entry's
> reference count to enforce exclusive open.
I think this is better... the way these files are used is lame, but
this should preserve the existing behavior. I haven't yet tested
this, can you?
diff --git a/arch/powerpc/kernel/rtas_flash.c b/arch/powerpc/kernel/rtas_flash.c
index f227659..00bc308 100644
--- a/arch/powerpc/kernel/rtas_flash.c
+++ b/arch/powerpc/kernel/rtas_flash.c
@@ -139,7 +139,7 @@ struct rtas_validate_flash_t
unsigned int update_results; /* Update results token */
};
-static DEFINE_SPINLOCK(flash_file_open_lock);
+static atomic_t open_count = ATOMIC_INIT(0);
static struct proc_dir_entry *firmware_flash_pde;
static struct proc_dir_entry *firmware_update_pde;
static struct proc_dir_entry *validate_pde;
@@ -216,7 +216,7 @@ static int rtas_flash_release(struct inode *inode, struct file *file)
uf->flist = NULL;
}
- atomic_dec(&dp->count);
+ atomic_dec(&open_count);
return 0;
}
@@ -352,26 +352,17 @@ static ssize_t rtas_flash_write(struct file *file, const char __user *buffer,
static int rtas_excl_open(struct inode *inode, struct file *file)
{
- struct proc_dir_entry *dp = PDE(inode);
-
- /* Enforce exclusive open with use count of PDE */
- spin_lock(&flash_file_open_lock);
- if (atomic_read(&dp->count) > 1) {
- spin_unlock(&flash_file_open_lock);
+ if (atomic_inc_return(&open_count) > 1) {
+ atomic_dec(&open_count);
return -EBUSY;
}
- atomic_inc(&dp->count);
- spin_unlock(&flash_file_open_lock);
-
return 0;
}
static int rtas_excl_release(struct inode *inode, struct file *file)
{
- struct proc_dir_entry *dp = PDE(inode);
-
- atomic_dec(&dp->count);
+ atomic_dec(&open_count);
return 0;
}
@@ -580,7 +571,7 @@ static int validate_flash_release(struct inode *inode, struct file *file)
}
/* The matching atomic_inc was in rtas_excl_open() */
- atomic_dec(&dp->count);
+ atomic_dec(&open_count);
return 0;
}
^ permalink raw reply related
* RE: [PATCH 1/5] [v2][POWERPC] refactor dcr code
From: Stephen Neuendorffer @ 2008-04-01 20:16 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1206914576.10388.132.camel@pasglop>
I considered function pointers as well, but I think something like
dcr-generic.h is still required in order to get the specialization if
only one is selected.
Also note that I neglected to change the patch description: The
dcr-access-method attribute is applied to the dcr-controller node, not
the dcr slave.
I'd particularly appreciate it if someone with access to PPC64 would
test this...
Steve
> -----Original Message-----
> From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
> Sent: Sunday, March 30, 2008 3:03 PM
> To: Stephen Neuendorffer
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH 1/5] [v2][POWERPC] refactor dcr code
>=20
>=20
> On Fri, 2008-03-28 at 09:23 -0700, Stephen Neuendorffer wrote:
> > Previously, dcr support was configured at compile time to either
using
> > MMIO or native dcr instructions. Although this works for most
> > platforms, it fails on FPGA platforms:
> >
> > 1) Systems may include more than one dcr bus.
> > 2) Systems may be native dcr capable and still use memory mapped dcr
interface.
> >
> > This patch provides runtime support based on the device trees for
the
> > case where CONFIG_PPC_DCR_MMIO and CONFIG_PPC_DCR_NATIVE are both
> > selected. Previously, this was a poorly defined configuration,
which
> > happened to provide NATIVE support. The runtime selection is made
> > based on the dcr slave device having a 'dcr-access-method' attribute
> > in the device tree. If only one of the above options is selected,
> > then the code uses #defines to select only the used code in order to
> > avoid interoducing overhead in existing usage.
> >
> > Signed-off-by: Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com>
>=20
> Looks good. Haven't had a chance to test it yet, but tentatively
>=20
> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>=20
> Initially, I thought about using function pointers but the if/else
will
> probably end up being more efficient. The only thing maybe to ponder
> is whether we could avoid the dcr-generic.h file completely, and have
> the generic wrappers be inline, though considering how slow DCRs are,
> it may not be that useful in practice and less clean...
>=20
> Cheers,
> Ben.
>=20
>=20
> > ---
> > arch/powerpc/sysdev/dcr.c | 91
++++++++++++++++++++++++++++++++-----
> > include/asm-powerpc/dcr-generic.h | 49 ++++++++++++++++++++
> > include/asm-powerpc/dcr-mmio.h | 20 +++++---
> > include/asm-powerpc/dcr-native.h | 16 ++++---
> > include/asm-powerpc/dcr.h | 36 ++++++++++++++-
> > 5 files changed, 186 insertions(+), 26 deletions(-)
> > create mode 100644 include/asm-powerpc/dcr-generic.h
> >
> > diff --git a/arch/powerpc/sysdev/dcr.c b/arch/powerpc/sysdev/dcr.c
> > index 437e48d..d3de0ff 100644
> > --- a/arch/powerpc/sysdev/dcr.c
> > +++ b/arch/powerpc/sysdev/dcr.c
> > @@ -23,6 +23,68 @@
> > #include <asm/prom.h>
> > #include <asm/dcr.h>
> >
> > +#if defined(CONFIG_PPC_DCR_NATIVE) && defined(CONFIG_PPC_DCR_MMIO)
> > +
> > +bool dcr_map_ok_generic(dcr_host_t host)
> > +{
> > + if (host.type =3D=3D INVALID)
> > + return 0;
> > + else if (host.type =3D=3D NATIVE)
> > + return dcr_map_ok_native(host.host.native);
> > + else
> > + return dcr_map_ok_mmio(host.host.mmio);
> > +}
> > +EXPORT_SYMBOL_GPL(dcr_map_ok_generic);
> > +
> > +dcr_host_t dcr_map_generic(struct device_node *dev,
> > + unsigned int dcr_n,
> > + unsigned int dcr_c)
> > +{
> > + dcr_host_t host;
> > + const char *prop =3D of_get_property(dev, "dcr-access-method",
NULL);
> > +
> > + if (!strcmp(prop, "native")) {
> > + host.type =3D NATIVE;
> > + host.host.native =3D dcr_map_native(dev, dcr_n, dcr_c);
> > + } else if (!strcmp(prop, "mmio")) {
> > + host.type =3D MMIO;
> > + host.host.mmio =3D dcr_map_mmio(dev, dcr_n, dcr_c);
> > + } else
> > + host.type =3D INVALID;
> > +
> > + return host;
> > +}
> > +EXPORT_SYMBOL_GPL(dcr_map_generic);
> > +
> > +void dcr_unmap_generic(dcr_host_t host, unsigned int dcr_c)
> > +{
> > + if (host.type =3D=3D NATIVE)
> > + dcr_unmap_native(host.host.native, dcr_c);
> > + else
> > + dcr_unmap_mmio(host.host.mmio, dcr_c);
> > +}
> > +EXPORT_SYMBOL_GPL(dcr_unmap_generic);
> > +
> > +u32 dcr_read_generic(dcr_host_t host, unsigned int dcr_n)
> > +{
> > + if (host.type =3D=3D NATIVE)
> > + return dcr_read_native(host.host.native, dcr_n);
> > + else
> > + return dcr_read_mmio(host.host.mmio, dcr_n);
> > +}
> > +EXPORT_SYMBOL_GPL(dcr_read_generic);
> > +
> > +void dcr_write_generic(dcr_host_t host, unsigned int dcr_n, u32
value)
> > +{
> > + if (host.type =3D=3D NATIVE)
> > + dcr_write_native(host.host.native, dcr_n, value);
> > + else
> > + dcr_write_mmio(host.host.mmio, dcr_n, value);
> > +}
> > +EXPORT_SYMBOL_GPL(dcr_write_generic);
> > +
> > +#endif /* defined(CONFIG_PPC_DCR_NATIVE) &&
defined(CONFIG_PPC_DCR_MMIO) */
> > +
> > unsigned int dcr_resource_start(struct device_node *np, unsigned
int index)
> > {
> > unsigned int ds;
> > @@ -47,7 +109,7 @@ unsigned int dcr_resource_len(struct device_node
*np, unsigned int index)
> > }
> > EXPORT_SYMBOL_GPL(dcr_resource_len);
> >
> > -#ifndef CONFIG_PPC_DCR_NATIVE
> > +#ifdef CONFIG_PPC_DCR_MMIO
> >
> > static struct device_node * find_dcr_parent(struct device_node *
node)
> > {
> > @@ -101,18 +163,19 @@ u64 of_translate_dcr_address(struct
device_node *dev,
> > return ret;
> > }
> >
> > -dcr_host_t dcr_map(struct device_node *dev, unsigned int dcr_n,
> > - unsigned int dcr_c)
> > +dcr_host_mmio_t dcr_map_mmio(struct device_node *dev,
> > + unsigned int dcr_n,
> > + unsigned int dcr_c)
> > {
> > - dcr_host_t ret =3D { .token =3D NULL, .stride =3D 0, .base =3D =
dcr_n };
> > + dcr_host_mmio_t ret =3D { .token =3D NULL, .stride =3D 0, .base =
=3D
dcr_n };
> > u64 addr;
> >
> > pr_debug("dcr_map(%s, 0x%x, 0x%x)\n",
> > dev->full_name, dcr_n, dcr_c);
> >
> > addr =3D of_translate_dcr_address(dev, dcr_n, &ret.stride);
> > - pr_debug("translates to addr: 0x%lx, stride: 0x%x\n",
> > - addr, ret.stride);
> > + pr_debug("translates to addr: 0x%llx, stride: 0x%x\n",
> > + (unsigned long long) addr, ret.stride);
> > if (addr =3D=3D OF_BAD_ADDR)
> > return ret;
> > pr_debug("mapping 0x%x bytes\n", dcr_c * ret.stride);
> > @@ -124,11 +187,11 @@ dcr_host_t dcr_map(struct device_node *dev,
unsigned int dcr_n,
> > ret.token -=3D dcr_n * ret.stride;
> > return ret;
> > }
> > -EXPORT_SYMBOL_GPL(dcr_map);
> > +EXPORT_SYMBOL_GPL(dcr_map_mmio);
> >
> > -void dcr_unmap(dcr_host_t host, unsigned int dcr_c)
> > +void dcr_unmap_mmio(dcr_host_mmio_t host, unsigned int dcr_c)
> > {
> > - dcr_host_t h =3D host;
> > + dcr_host_mmio_t h =3D host;
> >
> > if (h.token =3D=3D NULL)
> > return;
> > @@ -136,7 +199,11 @@ void dcr_unmap(dcr_host_t host, unsigned int
dcr_c)
> > iounmap(h.token);
> > h.token =3D NULL;
> > }
> > -EXPORT_SYMBOL_GPL(dcr_unmap);
> > -#else /* defined(CONFIG_PPC_DCR_NATIVE) */
> > +EXPORT_SYMBOL_GPL(dcr_unmap_mmio);
> > +
> > +#endif /* defined(CONFIG_PPC_DCR_MMIO) */
> > +
> > +#ifdef CONFIG_PPC_DCR_NATIVE
> > DEFINE_SPINLOCK(dcr_ind_lock);
> > -#endif /* !defined(CONFIG_PPC_DCR_NATIVE) */
> > +#endif /* defined(CONFIG_PPC_DCR_NATIVE) */
> > +
> > diff --git a/include/asm-powerpc/dcr-generic.h
b/include/asm-powerpc/dcr-generic.h
> > new file mode 100644
> > index 0000000..0ee74fb
> > --- /dev/null
> > +++ b/include/asm-powerpc/dcr-generic.h
> > @@ -0,0 +1,49 @@
> > +/*
> > + * (c) Copyright 2006 Benjamin Herrenschmidt, IBM Corp.
> > + * <benh@kernel.crashing.org>
> > + *
> > + * This program is free software; you can redistribute it and/or
modify
> > + * it under the terms of the GNU General Public License as
published by
> > + * the Free Software Foundation; either version 2 of the License,
or
> > + * (at your option) any later version.
> > + *
> > + * This program is distributed in the hope that it will be
useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty
of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See
> > + * the GNU General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU General Public
License
> > + * along with this program; if not, write to the Free Software
> > + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
02111-1307 USA
> > + */
> > +
> > +#ifndef _ASM_POWERPC_DCR_GENERIC_H
> > +#define _ASM_POWERPC_DCR_GENERIC_H
> > +#ifdef __KERNEL__
> > +#ifndef __ASSEMBLY__
> > +
> > +enum host_type_t {MMIO, NATIVE, INVALID};
> > +
> > +typedef struct {
> > + enum host_type_t type;
> > + union {
> > + dcr_host_mmio_t mmio;
> > + dcr_host_native_t native;
> > + } host;
> > +} dcr_host_t;
> > +
> > +extern bool dcr_map_ok_generic(dcr_host_t host);
> > +
> > +extern dcr_host_t dcr_map_generic(struct device_node *dev, unsigned
int dcr_n,
> > + unsigned int dcr_c);
> > +extern void dcr_unmap_generic(dcr_host_t host, unsigned int dcr_c);
> > +
> > +extern u32 dcr_read_generic(dcr_host_t host, unsigned int dcr_n);
> > +
> > +extern void dcr_write_generic(dcr_host_t host, unsigned int dcr_n,
u32 value);
> > +
> > +#endif /* __ASSEMBLY__ */
> > +#endif /* __KERNEL__ */
> > +#endif /* _ASM_POWERPC_DCR_GENERIC_H */
> > +
> > +
> > diff --git a/include/asm-powerpc/dcr-mmio.h
b/include/asm-powerpc/dcr-mmio.h
> > index 08532ff..acd491d 100644
> > --- a/include/asm-powerpc/dcr-mmio.h
> > +++ b/include/asm-powerpc/dcr-mmio.h
> > @@ -27,20 +27,26 @@ typedef struct {
> > void __iomem *token;
> > unsigned int stride;
> > unsigned int base;
> > -} dcr_host_t;
> > +} dcr_host_mmio_t;
> >
> > -#define DCR_MAP_OK(host) ((host).token !=3D NULL)
> > +static inline bool dcr_map_ok_mmio(dcr_host_mmio_t host)
> > +{
> > + return host.token !=3D NULL;
> > +}
> >
> > -extern dcr_host_t dcr_map(struct device_node *dev, unsigned int
dcr_n,
> > - unsigned int dcr_c);
> > -extern void dcr_unmap(dcr_host_t host, unsigned int dcr_c);
> > +extern dcr_host_mmio_t dcr_map_mmio(struct device_node *dev,
> > + unsigned int dcr_n,
> > + unsigned int dcr_c);
> > +extern void dcr_unmap_mmio(dcr_host_mmio_t host, unsigned int
dcr_c);
> >
> > -static inline u32 dcr_read(dcr_host_t host, unsigned int dcr_n)
> > +static inline u32 dcr_read_mmio(dcr_host_mmio_t host, unsigned int
dcr_n)
> > {
> > return in_be32(host.token + ((host.base + dcr_n) *
host.stride));
> > }
> >
> > -static inline void dcr_write(dcr_host_t host, unsigned int dcr_n,
u32 value)
> > +static inline void dcr_write_mmio(dcr_host_mmio_t host,
> > + unsigned int dcr_n,
> > + u32 value)
> > {
> > out_be32(host.token + ((host.base + dcr_n) * host.stride),
value);
> > }
> > diff --git a/include/asm-powerpc/dcr-native.h
b/include/asm-powerpc/dcr-native.h
> > index be6c879..67832e5 100644
> > --- a/include/asm-powerpc/dcr-native.h
> > +++ b/include/asm-powerpc/dcr-native.h
> > @@ -26,14 +26,18 @@
> >
> > typedef struct {
> > unsigned int base;
> > -} dcr_host_t;
> > +} dcr_host_native_t;
> >
> > -#define DCR_MAP_OK(host) (1)
> > +static inline bool dcr_map_ok_native(dcr_host_native_t host)
> > +{
> > + return 1;
> > +}
> >
> > -#define dcr_map(dev, dcr_n, dcr_c) ((dcr_host_t){ .base =3D (dcr_n)
})
> > -#define dcr_unmap(host, dcr_c) do {} while (0)
> > -#define dcr_read(host, dcr_n) mfdcr(dcr_n + host.base)
> > -#define dcr_write(host, dcr_n, value) mtdcr(dcr_n + host.base,
value)
> > +#define dcr_map_native(dev, dcr_n, dcr_c) \
> > + ((dcr_host_native_t){ .base =3D (dcr_n) })
> > +#define dcr_unmap_native(host, dcr_c) do {} while (0)
> > +#define dcr_read_native(host, dcr_n) mfdcr(dcr_n +
host.base)
> > +#define dcr_write_native(host, dcr_n, value) mtdcr(dcr_n +
host.base, value)
> >
> > /* Device Control Registers */
> > void __mtdcr(int reg, unsigned int val);
> > diff --git a/include/asm-powerpc/dcr.h b/include/asm-powerpc/dcr.h
> > index 9338d50..6b86322 100644
> > --- a/include/asm-powerpc/dcr.h
> > +++ b/include/asm-powerpc/dcr.h
> > @@ -20,14 +20,47 @@
> > #ifndef _ASM_POWERPC_DCR_H
> > #define _ASM_POWERPC_DCR_H
> > #ifdef __KERNEL__
> > +#ifndef __ASSEMBLY__
> > #ifdef CONFIG_PPC_DCR
> >
> > #ifdef CONFIG_PPC_DCR_NATIVE
> > #include <asm/dcr-native.h>
> > -#else
> > +#endif
> > +
> > +#ifdef CONFIG_PPC_DCR_MMIO
> > #include <asm/dcr-mmio.h>
> > #endif
> >
> > +#if defined(CONFIG_PPC_DCR_NATIVE) && defined(CONFIG_PPC_DCR_MMIO)
> > +
> > +#include <asm/dcr-generic.h>
> > +
> > +#define DCR_MAP_OK(host) dcr_map_ok_generic(host)
> > +#define dcr_map(dev, dcr_n, dcr_c) dcr_map_generic(dev, dcr_n,
dcr_c)
> > +#define dcr_unmap(host, dcr_c) dcr_unmap_generic(host, dcr_c)
> > +#define dcr_read(host, dcr_n) dcr_read_generic(host, dcr_n)
> > +#define dcr_write(host, dcr_n, value) dcr_write_generic(host,
dcr_n, value)
> > +
> > +#else
> > +
> > +#ifdef CONFIG_PPC_DCR_NATIVE
> > +typedef dcr_host_native_t dcr_host_t;
> > +#define DCR_MAP_OK(host) dcr_map_ok_native(host)
> > +#define dcr_map(dev, dcr_n, dcr_c) dcr_map_native(dev, dcr_n,
dcr_c)
> > +#define dcr_unmap(host, dcr_c) dcr_unmap_native(host, dcr_c)
> > +#define dcr_read(host, dcr_n) dcr_read_native(host, dcr_n)
> > +#define dcr_write(host, dcr_n, value) dcr_write_native(host, dcr_n,
value)
> > +#else
> > +typedef dcr_host_mmio_t dcr_host_t;
> > +#define DCR_MAP_OK(host) dcr_map_ok_mmio(host)
> > +#define dcr_map(dev, dcr_n, dcr_c) dcr_map_mmio(dev, dcr_n, dcr_c)
> > +#define dcr_unmap(host, dcr_c) dcr_unmap_mmio(host, dcr_c)
> > +#define dcr_read(host, dcr_n) dcr_read_mmio(host, dcr_n)
> > +#define dcr_write(host, dcr_n, value) dcr_write_mmio(host, dcr_n,
value)
> > +#endif
> > +
> > +#endif /* defined(CONFIG_PPC_DCR_NATIVE) &&
defined(CONFIG_PPC_DCR_MMIO) */
> > +
> > /*
> > * On CONFIG_PPC_MERGE, we have additional helpers to read the DCR
> > * base from the device-tree
> > @@ -41,5 +74,6 @@ extern unsigned int dcr_resource_len(struct
device_node *np,
> > #endif /* CONFIG_PPC_MERGE */
> >
> > #endif /* CONFIG_PPC_DCR */
> > +#endif /* __ASSEMBLY__ */
> > #endif /* __KERNEL__ */
> > #endif /* _ASM_POWERPC_DCR_H */
>=20
^ permalink raw reply
* RE: xilinx Ml405 NFS mount problem
From: MingLiu @ 2008-04-01 20:42 UTC (permalink / raw)
To: Robert Woodworth; +Cc: John Linn, linuxppc-embedded
In-Reply-To: <1207068618.4830.60.camel@PisteOff>
[-- Attachment #1: Type: text/plain, Size: 13008 bytes --]
Dear Robert and all friends,
A little more progress on my problem. I just found that if I disable the hardware check-sum offloading options, the root file system could be mounted then. In combination with the previous information of "UDP bad checksum" I mentioned, it seems that you are absolutely right! The problem is on the hardware checksum logic!
For this problem, maybe it will be better if xilinx could solve it. I am not pretty sure if we can rely on a stricter timing constraint. After all, we are not the original designer of the LL_TEMAC control logic.
Any other idea or suggestion? Thanks in advance.
BR
Ming
> Subject: RE: xilinx Ml405 NFS mount problem> From: rwoodworth@securics.com> To: eemingliu@hotmail.com> CC: john.linn@xilinx.com; linuxppc-embedded@ozlabs.org> Date: Tue, 1 Apr 2008 10:50:18 -0600> > I think you may be suffering from the latest LL_TEMAC packet loss> problem. (NFS/UDP really does not like packet loss)> > > Let me guess. > You are using a base system from "Base System Builder Wizard"?> EDK 9.2i. Default syntheses/P&R options.> > I have seen a massive packet loss problems on my ML403 and two other> boards I have with an FX60.> > 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.> > > 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. > > > Are you on a GigE switch?> > > > Rob.> > > > > > > On Tue, 2008-04-01 at 16:15 +0000, MingLiu wrote:> > Dear John,> > > > Thank you for your replying. > > > > >It’s not obvious to me what the problem is as I don’t see any driver> > failures. Have you >tried using a ramdisk and then seeing if the> > network is working before using NFS root? > > > > Not yet. I will try it soon. However from the information on the> > LL_TEMAC, it seems everything is fine and it should work. > > > > > > > > >And I’m assuming you have used the NFS root before so you know that> > it’s good for sure.> > > > > > > > >I test on the ML405 with NFS root and haven’t seen this problem, but> > my setup is a little different. I use DHCP rather than >a static IP,> > but other than that it’s similar.> > > > > > > > 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. > > > > > > > > >How long has it been since you pulled from the Xilinx Git tree?> > > > > > > > I just pulled the Xilinx tree quite recently. I am using a latest> > kernel.> > > > > > > > BR > > > > Ming> > > > > > > > > > > > And I’m assuming you have used the NFS root before so you know> > that it’s good for sure.> > > > > > > > I test on the ML405 with NFS root and haven’t seen this> > problem, but my setup is a little different. I use DHCP> > rather than a static IP, but other than that it’s similar.> > > > > > > > I’m assuming that you accidentally got 2 different powerup> > outputs in the message below as the 1st stops and a 2nd starts> > in the middle.> > > > > > > > How long has it been since you pulled from the Xilinx Git> > tree?> > > > > > > > Thanks,> > > > John> > > > > > > > > > ______________________________________________________________> > From: linuxppc-embedded-bounces> > +john.linn=xilinx.com@ozlabs.org> > [mailto:linuxppc-embedded-bounces> > +john.linn=xilinx.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> > > > > > > > > > Dear friends,> > > > 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. > > Thanks a lot!> > > > > > loaded at: 00400000 0059F19C> > board data at: 0059D120 0059D19C> > relocated to: 004050C8 00405144> > zimage at: 00405F3F 0059C025> > avail ram: 005A0000 08000000> > > > Linux/PPC load: root=/dev/nfs> > ip=192.168.0.4:192.168.0.3:192.168.0.3:255.255.255.0 rw> > nfsroot=192.168.0.3:/home/mingliu/ml403_rootfs console=ttyUL0,38400> > mem=32M> > 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> > > > Normal 8192 -> 8192> > > > 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=/de v/nfs> > ip=192.168.0.4:192.168.0.3:192.168.0.3:255.255.255.0 rw> > nfsroot=192.168.0.3:/home/mingliu/ml403_rootfs console=ttyUL0,38400> > mem=32M> > 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=11, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1> > 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 = 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=2> > 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> > > > Xilinx Generic PowerPC board support package (Xilinx ML405)> > (Virtex-4 FX)> > > > 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=/dev/nfs> > ip=192.168.0.4:192.168.0.3:192.168.0.3:255.255.255.0 rw> > nfsroot=192.168.0.3:/home/mingliu/ml403_rootfs console=ttyUL0,38400> > mem=32M> > 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=11, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1> > 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 = 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="FONT-SIZE: 12pt">to 0xC3004000, irq=2> > 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 = 24, Receive Threshold = 4> > eth0: XLlTemac: Send Wait bound = 254, Receive Wait bound = 254> > IP-Config: Complete:> > > > device=eth0, addr=192.168.0.4, mask=255.255.255.0, gw=192.168.0.3,> > host=192.168.0.4, domain=, nis-domain=(none),> > bootserver=192.168.0.3, rootserver=192.168.0.3, rootpath=> > 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=" boot option; here are > > the available> > partitions:> > Kernel panic - not syncing: VFS: Unable to mount root fs on> > unknown-block(2,0)> > Rebooting in 180 seconds..> > > > > > BR> > Ming> > > > > > > > > > ______________________________________________________________> > Windows Live Writer，支持离线撰写博客内容，随时随地想写就写。> > 立即使用！> > > > > > > > > > ______________________________________________________________________> > 使用新一代 Windows Live Messenger 轻松交流和共享！ 立即体验！ > > _______________________________________________> > Linuxppc-embedded mailing list> > Linuxppc-embedded@ozlabs.org> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded>
_________________________________________________________________
MSN 中文网，最新时尚生活资讯，白领聚集门户。
http://cn.msn.com
[-- Attachment #2: Type: text/html, Size: 16652 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2 v5] Add DIU platform code for MPC8610HPCD
From: Andrew Morton @ 2008-04-01 21:00 UTC (permalink / raw)
To: York Sun
Cc: timur, linux-fbdev-devel, a.p.zijlstra, linux-kernel,
linuxppc-dev, scottwood, yorksun
In-Reply-To: <12069806051291-git-send-email-yorksun@freescale.com>
On Mon, 31 Mar 2008 11:23:25 -0500
York Sun <yorksun@freescale.com> wrote:
> Add platform code to support Freescale DIU. The platform code includes
> framebuffer memory allocation, pixel format, monitor port, etc.
>
> Signed-off-by: York Sun <yorksun@freescale.com>
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
> This patch addes platform support for Freescale DIU driver, targeting 2.6.26 kernel.
>
> arch/powerpc/configs/mpc8610_hpcd_defconfig | 198 +++++++++++++++++++++++----
> arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 190 ++++++++++++++++++++++++--
> arch/powerpc/sysdev/fsl_soc.c | 41 ++++++
> arch/powerpc/sysdev/fsl_soc.h | 23 +++
> 4 files changed, 413 insertions(+), 39 deletions(-)
The defconfig change gets almost 100% rejects and probably isn't
appropriate here and isn't very important. I dropped that part of the
patch.
^ permalink raw reply
* Access physical memory via mmap() on ppc440epx.
From: Leonid @ 2008-04-01 21:12 UTC (permalink / raw)
To: linuxppc-embedded
Hi:
I am trying to read from NOR flash, located on address 0xfc000000, on my
ppc440epx board (similar to Sequoia) from user space. Mmap call returns
fine, but actual access fails - here is GDB output:
Breakpoint 1, f_EVLOG_GetSectorInfo (sector=3D18, si=3D0x1004a398)
at
/home/leonid/LM300/software/u-boot/apps/diags/common/event_log.c:1580
1580
/home/leonid/LM300/software/u-boot/apps/diags/common/event_log.c: No
such file or di.
in
/home/leonid/LM300/software/u-boot/apps/diags/common/event_log.c
(gdb) p sector
$1 =3D 18
(gdb) p/x buf
$2 =3D 0x30028000
(gdb) x/10 0x30028000
0x30028000: Cannot access memory at address 0x30028000
(gdb) x/10 0x30028200
0x30028200: Cannot access memory at address 0x30028200
(gdb)
0x30028200 is mmap() result, next step leads to crash:
(gdb)
Machine check in kernel mode.
Data Read PLB Error
OPB to PLB3: BSTAT=3D 0x00000000
PLB3 to PLB4: BEAR=3D0x5c00819442310a80 BESR0=3D0x00000000 =
BESR1=3D0x00000000
PLB4 to PLB3: BEAR=3D0xa5876840c012269b BESR0=3D0x00000000 =
BESR1=3D0x00000000
PLB3 to OPB: BEAR=3D0xf0dffd99 BESR0=3D0x00000000 BESR1=3D0x00000000
PLB3 arbiter: BEAR=3D0xc1fcef0c ACR=3D0x90000000 BESR=3D0x00000000
PLB4 to OPB1: BEAR=3D0x0000000b9fbdfdb8 BESR0=3D0x00000000 =
BESR1=3D0x00000000
PLB40 Arbiter: BEAR=3D0x00000000fc240000 ACR=3D0xde000000 =
BESR0=3D0x0f000000
PLB41 Arbiter: BEAR=3D0xe7fb1dfdf3820fcb ACR=3D0xdf000000 =
BESR0=3D0x00000000
POB0: BEAR=3D0xc27e3194f0dffd99 BESR0=3D0x00000000 BESR1=3D0x00000000
OPB0: BEAR=3D0x0000000000000000 BSTAT=3D0x00000000
Oops: machine check, sig: 7 [#6]
NIP: C0000DF8 LR: 10010474 CTR: 00000000
REGS: c02acf50 TRAP: 0202 Not tainted (2.6.19)
MSR: 00001000 <ME> CR: 40000044 XER: 20000000
TASK =3D cfc00bf0[77] 'diags_server' THREAD: cf9de000
GPR00: 00000000 CF9DFF40 3001F040 30028000 7FB5FA00 00000000 61736800
FEFEFEFF
GPR08: 00000000 0002D200 10010474 CF9DFF40 10010494 1004B074 10360000
44004042
GPR16: 10413BFC 7FAF1F5F 7FAF1F5F 00000000 00000001 10440000 00000000
00000000
GPR24: 1016B924 00000002 00000000 30026E5C 30027A18 10027B4C 0FFEA73C
7FB5FA20
NIP [C0000DF8] Debug+0x78/0x130
LR [10010474] 0x10010474
Call Trace:
[CF9DFF40] [C00026EC] do_user_signal+0x74/0xc4 (unreliable)
Instruction dump:
7d4802a6 914b00a0 7d9d0aa6 918b00b4 7d3e0aa6 912b00b8 7d9a0aa6 902b0014
7d3b0aa6 902b0000 7d615b78 55290398 <900b0010> 906b001c 908b0020
90ab0024
Program terminated with signal SIGBUS, Bus error.
The program no longer exists.
I suspect it has something to do with memory configiration. Note that
Linux kernel is loaded by u-boot where all peripherals (NOR flash
included) configured properly and work.
I have BDI2000 connected and can (after stopping the board) see
registers and TLB entries:
440EPx>rd ebc0_b0cr
ebc0_b0cr: 0xfc0da000 -66215936
BUS configuration looks OK.
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
4 : 00 80000000 256MB V0 -> 1_80000000 U:0000 -I-G- -WR-WR
5 : 00 90000000 256MB V0 -> 1_90000000 U:0000 -I-G- -WR-WR
6 : 00 a0000000 256MB V0 -> 1_a0000000 U:0000 -I-G- -WR-WR
7 : 00 b0000000 256MB V0 -> 1_b0000000 U:0000 -I-G- -WR-WR
8 : 00 d0000000 1KB V0 -> 1_d0000000 U:0000 -I-G- XWRXWR
9 : 00 e0000000 16MB V0 -> 0_e0000000 U:0000 -I--- XWRXWR
10 : 00 ea000000 1MB V0 -> 1_ea000000 U:0000 -I-G- XWRXWR
On Linux stage it looks rather different:
440EPx>tlb 0 40
IDX TID EPN SIZE VTS RPN USER WIMGE USRSVC
0 : 26 0ff9d000 4KB V0 -> 0_0fdc8000 U:0000 --MG- X-RX-R
1 : 26 30017000 4KB V0 -> 0_0fe3e000 U:0000 --MG- --R-WR
2 : 2a 10165000 4KB V0 -> 0_0028d000 U:0000 --MG- -WR-WR
3 : 2a 100a4000 4KB V0 -> 0_00767000 U:0000 ---G- X-RX-R
4 : 2a 1016b000 4KB V0 -> 0_00290000 U:0000 --MG- -WR-WR
5 : 2a 10077000 4KB V0 -> 0_007ac000 U:0000 ---G- X-RX-R
6 : 2a 10164000 4KB V0 -> 0_00295000 U:0000 --MG- --R-WR
7 : 2a 1019c000 4KB V0 -> 0_00536000 U:0000 --MG- -WR-WR
8 : 2a 100be000 4KB V0 -> 0_00774000 U:0000 ---G- X-RX-R
9 : 2a 10114000 4KB V0 -> 0_007b7000 U:0000 ---G- --R--R
10 : 2a 00000000 1KB -0 -> 0_007ef000 U:0000 ---G- --R--R
11 : 2a 10057000 4KB V0 -> 0_007ef000 U:0000 ---G- X-RX-R
12 : 2a 10117000 4KB V0 -> 0_007ba000 U:0000 ---G- --R--R
13 : 2a 10097000 4KB V0 -> 0_00792000 U:0000 ---G- X-RX-R
14 : 2a 10048000 4KB V0 -> 0_0fc27000 U:0000 ---G- X-RX-R
15 : 2a 10087000 4KB V0 -> 0_007db000 U:0000 ---G- X-RX-R
16 : 2a 10166000 4KB V0 -> 0_00299000 U:0000 --MG- -WR-WR
17 : 2a 10086000 4KB V0 -> 0_007da000 U:0000 ---G- X-RX-R
18 : 2a 1013c000 4KB V0 -> 0_00754000 U:0000 ---G- --R--R
19 : 2a 1008e000 4KB V0 -> 0_007a9000 U:0000 ---G- X-RX-R
20 : 2a 30000000 4KB V0 -> 0_00704000 U:0000 --MG- -WR-WR
21 : 2a 7fa1c000 4KB V0 -> 0_0fe37000 U:0000 --MG- -WR-WR
22 : 2a 1008d000 4KB V0 -> 0_007a8000 U:0000 ---G- X-RX-R
23 : 2a 1008c000 4KB V0 -> 0_007a7000 U:0000 ---G- X-RX-R
24 : 2a 100bd000 4KB V0 -> 0_00773000 U:0000 ---G- X-RX-R
25 : 00 fdfec000 4KB V0 -> 1_ef600000 U:0000 -IMG- ----WR
26 : 00 d1050000 4KB V0 -> 1_ef600000 U:0000 -IMG- ----WR
27 : 00 d1054000 4KB V0 -> 1_ef600000 U:0000 -IMG- ----WR
28 : 00 d1056000 4KB V0 -> 0_e0000000 U:0000 -IMG- ----WR
29 : 00 ff100000 4KB V0 -> 0_006b0000 U:0000 -IMG- ---XWR
30 : 26 10027000 4KB V0 -> 0_0fe80000 U:0000 --MG- --R-WR
...........................
Probably under MMU it should look this way? How to use mmap() then?
Thanks,
Leonid.
^ permalink raw reply
* Re: [PATCH 2/8] powerpc: replace `__attribute' by `__attribute__'
From: Paul Mackerras @ 2008-04-01 21:36 UTC (permalink / raw)
To: Roel Kluin; +Cc: linuxppc-dev, trivial, lkml
In-Reply-To: <47F27155.1000103@tiscali.nl>
Roel Kluin writes:
> replace `__attribute' by `__attribute__'
Why? Your commit message doesn't give any motivation.
Paul.
^ permalink raw reply
* Re: [PATCH 2/2 v5] Add DIU platform code for MPC8610HPCD
From: Timur Tabi @ 2008-04-01 21:36 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-fbdev-devel, a.p.zijlstra, linux-kernel, linuxppc-dev,
scottwood, York Sun
In-Reply-To: <20080401140029.be918d87.akpm@linux-foundation.org>
Andrew Morton wrote:
> The defconfig change gets almost 100% rejects and probably isn't
> appropriate here and isn't very important.
It's weird that you get rejects, but otherwise you're correct. defconfigs are
just a convenience, anyway.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 04/11 v2] [POWERPC] Remove and replace uses of PPC_MEMSTART with memstart_addr
From: Kumar Gala @ 2008-04-01 21:49 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18418.4984.671485.346817@cargo.ozlabs.ibm.com>
On Apr 1, 2008, at 5:50 AM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>> For the sub-arches that support relocatable interrupt vectors (book-
>> e) its
>> reasonable to have memory start at a non-zero physical address.
>> For those
>> cases use the variable memstart_addr instead of the #define
>> PPC_MEMSTART
>> since the only uses of PPC_MEMSTART are for initialization and in the
>> future we can set memstart_addr at runtime to have a relocatable
>> kernel.
>
> In those cases, is it still true that the kernel sits at the start of
> the usable memory, or might there be usable memory before _stext?
> In other words, is PAGE_OFFSET == KERNELBASE still true or not?
Both cases are possible.
Here are the four cases I see:
* Normal kernel (kernel at physical 0)
* kexec kernel (kernel at physical 32M, but still has access to memory
from physical 0 to 32M)
* cAMP kernel (kernel at non-zero offset) [eg. 256M offset]
* kexec cAMP kernel (kernel at 256M+32M, but has access to 256M + size)
- k
^ permalink raw reply
* Re: [PATCH 01/11] [POWERPC] bootwrapper: Allow specifying of image physical offset
From: Kumar Gala @ 2008-04-01 21:52 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18418.2460.594352.712502@cargo.ozlabs.ibm.com>
On Apr 1, 2008, at 5:08 AM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>> Normally we assume kernel images will be loaded at offset 0. However
>> there are situations, like when the kernel itself is running at a
>> non-zero
>> physical address, that we don't want to load it at 0.
>>
>> Allow the wrapper to take an offset. We use this when building u-
>> boot images.
>
> This makes it a bit harder to build a kernel and then wrap it later
> on, since one would have to know what -m value to give. Would it
> possible for either the wrapper script or mkimage to peek in the ELF
> header of the vmlinux to work out what physical address to use?
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?
- k
^ permalink raw reply
* Re: [PATCH] [POWERPC] Move phys_addr_t definition into asm/types.h
From: Kumar Gala @ 2008-04-01 22:08 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18417.44855.137234.450478@cargo.ozlabs.ibm.com>
On Mar 31, 2008, at 10:42 PM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>> Moved phys_addr_t out of mmu-*.h and into asm/types.h so we can use
>> it in
>> places that before would have caused recursive includes.
>>
>> For example to use phys_addr_t in <asm/page.h> we would have included
>> <asm/mmu.h> which would have possibly included <asm/mmu-hash64.h>
>> which
>> includes <asm/page.h>. Wheeee recursive include.
>
> In general this looks fine. I wonder if you should use u64 rather
> than unsigned long long. Since CONFIG_PHYS_64BIT=n on 64-bit machines
> (which is itself somewhat counterintuitive) we will actually use
> unsigned long on 64-bit machines, so it matters less than I originally
> thought, but it would be worth explaining that in a comment and/or the
> commit message.
We could change it to be:
/* Physical address used by some IO functions */
#if defined(CONFIG_PPC64) || defined(CONFIG_PHYS_64BIT)
typedef u64 phys_addr_t;
#else
typedef u32 phys_addr_t;
#endif
This seems a bit more self documenting which is always nice (and I can
add a comment in the commit message about CONFIG_PHYS_64BIT only
making sense on ppc32).
- k
^ permalink raw reply
* Re: Please pull powerpc.git merge branch
From: Paul Mackerras @ 2008-04-01 23:12 UTC (permalink / raw)
To: Bartlomiej Sieka; +Cc: linuxppc-dev, akpm, torvalds, linux-kernel
In-Reply-To: <47ED6BE5.9060807@semihalf.com>
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://...".
Paul.
^ permalink raw reply
* Virtex V5FX PPC 440 Support In Xilinx Git Tree
From: John Linn @ 2008-04-01 23:41 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 326 bytes --]
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.
A default kernel configuration file, ml507_defconfig, is provided in the
kernel tree to support the Xilinx ML507 board with the PowerPC 440.
Thanks,
John
[-- Attachment #2: Type: text/html, Size: 7503 bytes --]
^ permalink raw reply
* RE: xilinx Ml405 NFS mount problem
From: Robert Woodworth @ 2008-04-01 23:43 UTC (permalink / raw)
To: John Linn; +Cc: linuxppc-embedded
In-Reply-To: <20080401165329.D31E3AA008E@mail29-dub.bigfish.com>
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.
>
> I am also using the latest LL TEMAC with EDK 10.1.
>
> Thanks,
> John
>
> -----Original Message-----
> From: Robert Woodworth [mailto:rwoodworth@securics.com]
> Sent: Tuesday, April 01, 2008 10:50 AM
> To: MingLiu
> Cc: John Linn; linuxppc-embedded@ozlabs.org
> Subject: RE: xilinx Ml405 NFS mount problem
>
> I think you may be suffering from the latest LL_TEMAC packet loss
> problem. (NFS/UDP really does not like packet loss)
>
>
> Let me guess.
> You are using a base system from "Base System Builder Wizard"?
> EDK 9.2i. Default syntheses/P&R options.
>
> I have seen a massive packet loss problems on my ML403 and two other
> boards I have with an FX60.
>
> 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.
>
>
> 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.
>
>
> Are you on a GigE switch?
>
>
>
> Rob.
>
>
>
>
>
>
> On Tue, 2008-04-01 at 16:15 +0000, MingLiu wrote:
> > Dear John,
> >
> > Thank you for your replying.
> >
> > >It’s not obvious to me what the problem is as I don’t see any driver
> > failures. Have you >tried using a ramdisk and then seeing if the
> > network is working before using NFS root?
> >
> > Not yet. I will try it soon. However from the information on the
> > LL_TEMAC, it seems everything is fine and it should work.
> >
> >
> >
> > >And I’m assuming you have used the NFS root before so you know that
> > it’s good for sure.
> >
> >
> >
> > >I test on the ML405 with NFS root and haven’t seen this problem, but
> > my setup is a little different. I use DHCP rather than >a static IP,
> > but other than that it’s similar.
> >
> >
> >
> > 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.
> >
> >
> >
> > >How long has it been since you pulled from the Xilinx Git tree?
> >
> >
> >
> > I just pulled the Xilinx tree quite recently. I am using a latest
> > kernel.
> >
> >
> >
> > BR
> >
> > Ming
> >
> >
> >
> >
> >
> > And I’m assuming you have used the NFS root before so you know
> > that it’s good for sure.
> >
> >
> >
> > I test on the ML405 with NFS root and haven’t seen this
> > problem, but my setup is a little different. I use DHCP
> > rather than a static IP, but other than that it’s similar.
> >
> >
> >
> > I’m assuming that you accidentally got 2 different powerup
> > outputs in the message below as the 1st stops and a 2nd starts
> > in the middle.
> >
> >
> >
> > How long has it been since you pulled from the Xilinx Git
> > tree?
> >
> >
> >
> > Thanks,
> >
> > John
> >
> >
> >
> >
> > ______________________________________________________________
> > From: linuxppc-embedded-bounces
> > +john.linn=xilinx.com@ozlabs.org
> > [mailto:linuxppc-embedded-bounces
> > +john.linn=xilinx.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
> >
> >
> >
> >
> > Dear friends,
> >
> > 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.
> > Thanks a lot!
> >
> >
> > loaded at: 00400000 0059F19C
> > board data at: 0059D120 0059D19C
> > relocated to: 004050C8 00405144
> > zimage at: 00405F3F 0059C025
> > avail ram: 005A0000 08000000
> >
> > Linux/PPC load: root=/dev/nfs
> > ip=192.168.0.4:192.168.0.3:192.168.0.3:255.255.255.0 rw
> > nfsroot=192.168.0.3:/home/mingliu/ml403_rootfs console=ttyUL0,38400
> > mem=32M
> > 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
> >
> > Normal 8192 -> 8192
> >
> > 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=/de v/nfs
> > ip=192.168.0.4:192.168.0.3:192.168.0.3:255.255.255.0 rw
> > nfsroot=192.168.0.3:/home/mingliu/ml403_rootfs console=ttyUL0,38400
> > mem=32M
> > 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=11, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1
> > 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 = 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=2
> > 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
> >
> > Xilinx Generic PowerPC board support package (Xilinx ML405)
> > (Virtex-4 FX)
> >
> > 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=/dev/nfs
> > ip=192.168.0.4:192.168.0.3:192.168.0.3:255.255.255.0 rw
> > nfsroot=192.168.0.3:/home/mingliu/ml403_rootfs console=ttyUL0,38400
> > mem=32M
> > 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=11, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1
> > 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 = 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="FONT-SIZE: 12pt">to 0xC3004000, irq=2
> > 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 = 24, Receive Threshold = 4
> > eth0: XLlTemac: Send Wait bound = 254, Receive Wait bound = 254
> > IP-Config: Complete:
> >
> > device=eth0, addr=192.168.0.4, mask=255.255.255.0, gw=192.168.0.3,
> > host=192.168.0.4, domain=, nis-domain=(none),
> > bootserver=192.168.0.3, rootserver=192.168.0.3, rootpath=
> > 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=" boot option; here are
> > the available
> > partitions:
> > Kernel panic - not syncing: VFS: Unable to mount root fs on
> > unknown-block(2,0)
> > Rebooting in 180 seconds..
> >
> >
> > BR
> > Ming
> >
> >
> >
> >
> > ______________________________________________________________
> > Windows Live Writer，支持离线撰写博客内容，随时随地想写就写。
> > 立即使用！
> >
> >
> >
> >
> > ______________________________________________________________________
> > 使用新一代 Windows Live Messenger 轻松交流和共享！ 立即体验！
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>
^ permalink raw reply
* RE: xilinx Ml405 NFS mount problem
From: Rick Moleres @ 2008-04-01 23:54 UTC (permalink / raw)
To: Robert Woodworth, John Linn; +Cc: linuxppc-embedded
In-Reply-To: <1207093428.4830.79.camel@PisteOff>
Robert,
I saw an earlier email regarding v1.00b of xps_ll_temac. Besides the =
checksum offload issue in this version of the core, there is also an =
issue when receiving multicast packets where we've seen some ping =
packets lost around receipt of a multicast packets. So for example, we =
saw this issue when attached to a switch/router that sends out STP =
packets. When attached directly between target and host the issue =
disappeared. I believe this issue is fixed in v1.01a of the core being =
released in EDK 10.1. I also think there's an answer record on how to =
work around this issue, but I don't have that AR number handy (search =
the Xilinx website and let me know if you don't find it - if you think =
this applies to you at all).
The issue you describe below doesn't appear to match the multicast =
issue, as you should see that regardless of which part you're in. You =
may want to talk to your FAE as to possible hw timing issues.
Thanks,
Rick
-----Original Message-----
From: linuxppc-embedded-bounces+moleres=3Dxilinx.com@ozlabs.org =
[mailto:linuxppc-embedded-bounces+moleres=3Dxilinx.com@ozlabs.org] On =
Behalf Of Robert Woodworth
Sent: Tuesday, April 01, 2008 5:44 PM
To: John Linn
Cc: 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
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* 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
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