Help needed Linux-2.6 - MPC8541
Junita Ajith
junita_ppc at yahoo.com
Thu Apr 14 06:58:39 EST 2005
Hello Clement Koller,
Thanks for your response.
We have both Marvel & Intel's phy in our 8541 board.
As of now in the kernel we have just enabled support for Marvel's PHY.
It doesnt even come to the point of detecting the PHY ID (88E1011S). It just reads the PHy Address(Board specific) correclty.
Even before it gets into gianfar_phy.c it hangs at gianfar.c.
This is the screen dump.
---------------------------------------
Board: PCI-G8500 [PowerQUICC III]
CPU: 825 MHz
CCB: 330 MHz
DDR: 165 MHz
LBC: 82 MHz
L1 D-cache 32KB, L1 I-cache 32KB enabled.
I2C: ready
DRAM: 256 MB
RMCG8400 in PCI Host Mode.
RMCG8400 is the PCI Arbiter.
FLASH: 8 MB
L2 cache enabled: 256KB
In: serial
Out: serial
Err: serial
Net: MOTO ENET0: PHY is Marvell 88E1011S (1410c67)
MOTO ENET2: PHY is Intel LXT971A (1378e2)
MOTO ENET0, MOTO ENET2
Hit any key to stop autoboot: 0
RMCG8500#>tftp 2000000 8541/vmlinux.img
Speed: 1000, full duplex
Using MOTO ENET0 device
TFTP from server 192.168.201.11; our IP address is 192.168.201.191
Filename '8541/vmlinux.img'.
Load address: 0x2000000
Loading: #################################################################
#################################################################
###########################################
done
Bytes transferred = 883219 (d7a13 hex)
RMCG8500#>tftp 3000000 8541/ramdisk.image-8541.hdr
Speed: 1000, full duplex
Using MOTO ENET0 device
TFTP from server 192.168.201.11; our IP address is 192.168.201.191
Filename '8541/ramdisk.image-8541.hdr'.
Load address: 0x3000000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
##################
done
Bytes transferred = 2751871 (29fd7f hex)
RMCG8500#>bootm 2000000 3000000
## Booting image at 02000000 ...
Image Name: PCIG8400-Rel-1.1
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 883155 Bytes = 862.5 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at 03000000 ...
Image Name: PCIG8400
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 2751807 Bytes = 2.6 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Ramdisk to 0fd12000, end 0ffb1d3f ... OK
Memory CAM mapping: CAM0=256Mb, CAM1=0Mb, CAM2=0Mb residual: 0Mb
Linux version 2.6.11 (pari at sjswsvr11) (gcc version 3.3.2) #16 Tue Apr 5 11:19:57
PDT 2005
Built 1 zonelists
Kernel command line: console=ttyS0,115200 root=/dev/ram rw doPci=1
OpenPIC Version 1.2 (1 CPUs and 44 IRQ sources) at fcfbb000
PID hash table entries: 2048 (order: 11, 32768 bytes)
Console: colour dummy device 80x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 254720k available (1252k kernel code, 444k data, 292k init, 0k highmem)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
Freeing initrd memory: 2687k freed
NET: Registered protocol family 16
PCI: Probing PCI hardware
devfs: 2004-01-31 Richard Gooch (rgooch at atnf.csiro.au)
devfs: boot_options: 0x0
Serial: 8250/16550 driver $Revision: 1.90 $ 1 ports, IRQ sharing enabled
ttyS0 at MMIO 0xfdf04500 (irq = 90) is a 16550A
io scheduler noop registered inside elv_register()
RAMDISK driver initialized: 16 RAM disks of 32768K size 1024 blocksize
Inside gfar_probe() of gianfar.c
*************************************
Inside alloc_etherdev() for eth-1072721460
PHY base Addr is 0xd1002000
Before DMA engine stop for IEVENT
value of DMACTRL reg before writing to it : 0x0
value to be written to DMACTRL reg : 0x18
value of DMACTRL reg after writing to it : 0x80000000
value of IEVENT reg : 0x80000000
***************************************************************************
And after this it just gets into the loop where it looks if the 'Gracious receive and Gracious stop' bits of the IEVENT register are set.
In our case it doesnt get set and so the kernel hangs at that point.
Thanks
Junita
Clemens Koller <clemens.koller at anagramm.de> wrote:
Hi, Junita!
What PHYs do you use on the 8541?
Check if they are supported in gianfar_phy or if they
can be used with Generic MII
Check if you get the the phy_id is correct.
Some more debug-output would be nice.
I had to add Intel LXT971 support to the gianfar_phy
for my platform which is a 100MBit MII PHY only.
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19
Junita Ajith wrote:
> Andy
>
> 1. The code hangs exaclty at the point where it looks for the 'graceful transmit/receive' bits set in the IEVENT register. (IEVENT_GRSC , IEVENT_GTSC) .
> File - (linux-2.6/drivers/net/gianfar.c)
> Function - static int gfar_probe(struct device *device) ;
>
> In that ,we write Graceful Receive Stop and Graceful Transmit Stop, and then wait until the corresponding bits in IEVENT indicate the stops have completed.
>
> This never happens and hence hangs at the 'while' loop inside that function.
>
> 2. We are using Linux-2.6.11
>
> Here's the serial output dump with a few debug messages.
>
> ## Booting image at 02000000 ...
> Image Name: PCIG8400-Rel-1.1
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 883221 Bytes = 862.5 kB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
> ## Loading RAMDisk Image at 03000000 ...
> Image Name: PCIG8400
> Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
> Data Size: 2751807 Bytes = 2.6 MB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Loading Ramdisk to 0fd12000, end 0ffb1d3f ... OK
> Memory CAM mapping: CAM0=256Mb, CAM1=0Mb, CAM2=0Mb residual: 0Mb
> Linux version 2.6.11 (pari at sjswsvr11) (gcc version 3.3.2) #16 Tue Apr 5 11:19:57
> PDT 2005
> Built 1 zonelists
> Kernel command line: console=ttyS0,115200 root=/dev/ram rw doPci=1
> OpenPIC Version 1.2 (1 CPUs and 44 IRQ sources) at fcfbb000
> PID hash table entries: 2048 (order: 11, 32768 bytes)
> Console: colour dummy device 80x25
> Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
> Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
> Memory: 254720k available (1252k kernel code, 444k data, 292k init, 0k highmem)
> Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
> checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
> Freeing initrd memory: 2687k freed
> NET: Registered protocol family 16
> PCI: Probing PCI hardware
> devfs: 2004-01-31 Richard Gooch (rgooch at atnf.csiro.au)
> devfs: boot_options: 0x0
> Serial: 8250/16550 driver $Revision: 1.90 $ 1 ports, IRQ sharing enabled
> ttyS0 at MMIO 0xfdf04500 (irq = 90) is a 16550A
> io scheduler noop registered inside elv_register()
> RAMDISK driver initialized: 16 RAM disks of 32768K size 1024 blocksize
> Inside gfar_probe()
> einfo Phy ID 7
> gfar 1: additional data!
> Inside alloc_etherdev() for eth-1072721560
> start e0024000
> Resetting MAC........
> --2--MACCFG1 is 0x80000000
> MACCFG2 is 0x 0
> -2- tempval 000000db
> -3- tempval 00000000
> -4-1- tempval 00000000
> -4-2- tempval 00000000
> -4-2-a tempval 00000000
> -4-3 tempval 00000000
> -4-4 tempval 00000000
> Before loop -5- after writing to IEVENT tempval
> -5- after writing to IEVENT tempval 80000000
> -5- after writing to IEVENT tempval 80000000
> -5- after writing to IEVENT tempval 80000000
> -5- after writing to IEVENT tempval 80000000
> -5- after writing to IEVENT tempval 80000000
> -5- after writing to IEVENT tempval 80000000
> -5- after writing to IEVENT tempval 80000000
>
>
>
> thanks,
> Junita
> Andy Fleming wrote:
>
> Could you send me what the kernel prints up to the point of the hang?
>
> Also, what version of 2.6 are you using? The board interface for the
> driver changed recently to support the new driver model.
>
> Andy
>
> On Apr 12, 2005, at 12:38, Junita Ajith wrote:
>
>
>>Hi
>>We are trying to port Linux-2.6 for our custom
>>MPC8541 board.
>>
>>We have a TSEC and an FEC in the board.
>>
>>With the "Networking Support" disabled in the Kernel,
>>the board boots up fine and gets to the prompt.
>>
>>But with the "Networking Support" enabled in the
>>kernel the board hangs where it identifies the PHY,
>>inspite of giving the corrct PHY ID.
>>
>>
>>Any help is greatly appreciated.
>>
>>PS:
>>We have linux-2.4 ported for the same board and so
>>taking that as reference trying to port Linux-2.6 ,
>>but havent succeeded yet.
>>
>>Thanks
>>Junita
>>
>>
>>
>>__________________________________
>>Do you Yahoo!?
>>Make Yahoo! your home page
>>http://www.yahoo.com/r/hs
>>_______________________________________________
>>Linuxppc-embedded mailing list
>>Linuxppc-embedded at ozlabs.org
>>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>
>
>
>
>
> ---------------------------------
> Do you Yahoo!?
> Yahoo! Small Business - Try our new resources site!
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050413/7d0ca4f4/attachment.htm
More information about the Linuxppc-embedded
mailing list