[uClinux-dev] FEC freezes on m5235evb from flash

Greg Ungerer gerg at snapgear.com
Thu Oct 20 21:43:46 EDT 2005


Hi Stefano,

Stefano Caioli wrote:
> when i boot from ram i get:
> 
> fec: PHY @ 0x1f, ID 0x00221619 -- KS8721BL
> 
> instead of:
> 
> FEC: No PHY device found.
> 
> when i boot from flash.
> 
> Do you think this is a problem?

Well, it is certainly a problem :-)
It should be detecting the PHY. You will need to add
some debug to the code that detects the PHY, and try
to determine where it is going wrong.

Regards
Greg


> About the MAC address Heiko was right: dBug initializes the FEC
> MAC register ONLY when you download the image(i.e. you use the ethernet port), 
> if you put the image throught BDM cable then move to memory
> the MAC is not inizialized at all.
> 
> In order to solve the problem, i put in the colilo
> initialization of the board two instruction to write
> low and high MAC register of the FEC and now i have
> the right MAC.
> In the next days i'm gonna modify dBug to fix the problem
> of the ethernet init.
> Up to now the system seems to work properly.
> Thank you for the support.
> Regards,
> 
> 
>                          Stefano
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Thu, 20 Oct 2005 10:59:55 +1000, Greg Ungerer wrote
> 
>>Hi Stefano,
>>
>>Stefano Caioli wrote:
>>
>>>I tried the patch. Now thesystem seems to boot, even if
>>>i don't know if this behavior is just a case or it is stable.
>>
>>If you can test it some more that would be good.
>>It also fixes a problem I have had on the 5275 (sometimes the
>>second FEC would lock up during boot).
>>
>>
>>>However i get the usual message:
>>>
>>>FEC ENET Version 0.2
>>>eth0: ethernet bf:ff:ef:7e:ff:be
>>
>>The default behavior is that the FEC driver does not update
>>the MAC address registers - just reading back what they contain
>>(which ofcourse works fine when launched from dBUG).
>>If your board has some way to get at the MAC address
>>(in flash or whetever) then you need to add code support
>>for that.
>>
>>
>>>PPP generic driver version 2.4.2
>>>FEC: No PHY device found.
>>>physmap flash device: 200000 at ffe00000
>>>
>>>Do you think i can rely on it?
>>>And what about the MAC bf:ff:ef:7e:ff:be?
>>
>>What type of PHY do you have hooked up?
>>The driver couldn't find one (may or may not be a problem.
>>I know some switch devices do not appear to have a PHY
>>ID in the conventional sense).
>>
>>Regards
>>Greg
>>
>>
>>>Happy to try everything you think usefull.
>>>Regards,
>>>
>>>
>>>         Stefano.
>>>
>>>
>>>
>>>
>>>On Wed, 19 Oct 2005 23:22:43 +1000, Greg Ungerer wrote
>>>
>>>
>>>>Hi Stefano,
>>>>
>>>>Stefano Caioli wrote:
>>>>
>>>>
>>>>>i tried the patch but nothing happens.
>>>>>The boot process just stops again on the same istruction.
>>>>>However, i wish to tell you about my test:
>>>>>If i use dbug loading the image in ram at 0x20000 with DN command the FEC works fine.
>>>>>If i copy the image in flash at 0xff40000 (i.e. after dbug) then
>>>>>when dbug starts i copy from flash to ram at 0x20000 with the console command BM
>>>>>i have the same problem the FEC DOESN'T work.
>>>>>This is very strange , it looks like somewhat passing the uClinux image trought the
>>>>>flash altering the FEC behavior!
>>>>
>>>>I would think it is related to dBUG initializing the FEC hardware.
>>>>
>>>>
>>>>
>>>>>If i use colilo i get the same exact problem.
>>>>>After several tries, my system has sometime booted giving the
>>>>>message FEC: No PHY device found, but it seems to work!
>>>>>It looks like a random initialization of some FEC register.
>>>>>Just for the record: same behavior with the latest distro 20051014.
>>>>>I keep trying!
>>>>
>>>>I have been cleanly up the fec driver hardware init,
>>>>can you try this patch:
>>>>
>>>>--- fec.c.org   2005-09-26 17:03:49.000000000 +1000
>>>>+++ fec.c       2005-10-19 23:21:19.582341392 +1000
>>>>@@ -142,6 +142,10 @@
>>>> #define TX_RING_SIZE           16      /* Must be power of two */
>>>> #define TX_RING_MOD_MASK       15      /*   for this to work */
>>>>
>>>>+#if (((RX_RING_SIZE + TX_RING_SIZE) * 8) > PAGE_SIZE)
>>>>+#error "FEC: descriptor ring size contants too large"
>>>>+#endif
>>>>+
>>>> /* Interrupt events/masks.
>>>> */
>>>> #define FEC_ENET_HBERR ((uint)0x80000000)      /* Heartbeat error */
>>>>@@ -2144,6 +2148,14 @@
>>>>        if (index >= FEC_MAX_PORTS)
>>>>                return -ENXIO;
>>>>
>>>>+       /* Allocate memory for buffer descriptors.
>>>>+       */
>>>>+       mem_addr = __get_free_page(GFP_KERNEL);
>>>>+       if (mem_addr == 0) {
>>>>+               printk("FEC: allocate descriptor memory failed?\n");
>>>>+               return -ENOMEM;
>>>>+       }
>>>>+
>>>>        /* Create an Ethernet device instance.
>>>>        */
>>>>        fecp = (volatile fec_t *) fec_hw[index];
>>>>@@ -2156,16 +2168,6 @@
>>>>        fecp->fec_ecntrl = 1;
>>>>        udelay(10);
>>>>
>>>>-       /* Clear and enable interrupts */
>>>>-       fecp->fec_ievent = 0xffc00000;
>>>>-       fecp->fec_imask = (FEC_ENET_TXF | FEC_ENET_TXB |
>>>>-               FEC_ENET_RXF | FEC_ENET_RXB | FEC_ENET_MII);
>>>>-       fecp->fec_hash_table_high = 0;
>>>>-       fecp->fec_hash_table_low = 0;
>>>>-       fecp->fec_r_buff_size = PKT_MAXBLR_SIZE;
>>>>-        fecp->fec_ecntrl = 2;
>>>>-        fecp->fec_r_des_active = 0x01000000;
>>>>-
>>>>        /* Set the Ethernet address.  If using multiple Enets on the 8xx,
>>>>         * this needs some work to get unique addresses.
>>>>         *
>>>>@@ -2174,14 +2176,6 @@
>>>>         */
>>>>        fec_get_mac(dev);
>>>>
>>>>-       /* Allocate memory for buffer descriptors.
>>>>-       */
>>>>-       if (((RX_RING_SIZE + TX_RING_SIZE) * sizeof(cbd_t)) > PAGE_SIZE) {
>>>>-               printk("FEC init error.  Need more space.\n");
>>>>-               printk("FEC initialization failed.\n");
>>>>-               return 1;
>>>>-       }
>>>>-       mem_addr = __get_free_page(GFP_KERNEL);
>>>>        cbd_base = (cbd_t *)mem_addr;
>>>>        /* XXX: missing check for allocation failure */
>>>>
>>>>@@ -2259,6 +2253,16 @@
>>>>        */
>>>>        fec_request_intrs(dev);
>>>>
>>>>+       /* Clear and enable interrupts */
>>>>+       fecp->fec_ievent = 0xffc00000;
>>>>+       fecp->fec_imask = (FEC_ENET_TXF | FEC_ENET_TXB |
>>>>+               FEC_ENET_RXF | FEC_ENET_RXB | FEC_ENET_MII);
>>>>+       fecp->fec_hash_table_high = 0;
>>>>+       fecp->fec_hash_table_low = 0;
>>>>+       fecp->fec_r_buff_size = PKT_MAXBLR_SIZE;
>>>>+       fecp->fec_ecntrl = 2;
>>>>+       fecp->fec_r_des_active = 0x01000000;
>>>>+
>>>>        dev->base_addr = (unsigned long)fecp;
>>>>
>>>>        /* The FEC Ethernet specific entries in the device structure. */
>>>>
>>>>Regards
>>>>Greg
>>>>
>>>>
>>>>
>>>>>On Wed, 19 Oct 2005 11:45:06 +1000, Greg Ungerer wrote
>>>>>
>>>>>
>>>>>
>>>>>>Hi Stefano,
>>>>>>
>>>>>>Looking at the early setting of fec_r_des_active in fec_enet_init
>>>>>>I would say that is probably wrong (since the descriptors themselves
>>>>>>have not been initialized yet).
>>>>>>
>>>>>>Can you try this patch and see if it works any better:
>>>>>>
>>>>>>--- drivers/net/fec.c   26 Sep 2005 07:04:28 -0000      1.43
>>>>>>+++ drivers/net/fec.c   19 Oct 2005 01:44:14 -0000
>>>>>>@@ -2164,7 +2164,6 @@
>>>>>>       fecp->fec_hash_table_low = 0;
>>>>>>       fecp->fec_r_buff_size = PKT_MAXBLR_SIZE;
>>>>>>        fecp->fec_ecntrl = 2;
>>>>>>-        fecp->fec_r_des_active = 0x01000000;
>>>>>>
>>>>>>       /* Set the Ethernet address.  If using multiple Enets on the 8xx,
>>>>>
>>>>>
>>>>>>        * this needs some work to get unique addresses.
>>>>>>@@ -2253,6 +2252,7 @@
>>>>>>       */
>>>>>>       fecp->fec_r_des_start = __pa((uint)(fep->rx_bd_base));
>>>>>>       fecp->fec_x_des_start = __pa((uint)(fep->tx_bd_base));
>>>>>>+       fecp->fec_r_des_active = 0x01000000;
>>>>>>
>>>>>>       /* Install our interrupt handlers. This varies depending on
>>>>>>        * the architecture.
>>>>>>
>>>>>>Regards
>>>>>>Greg
>>>>>>
>>>>>>Greg Ungerer wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Stefano Caioli wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>Ok, i've done some trivial debug an i found that the problem is in
>>>>>>>>file fec.c function fec_enet_init.
>>>>>>>>The system freezes when trying the instruction:
>>>>>>>>
>>>>>>>>fecp->fec_r_des_active = 0x01000000;
>>>>>>>>
>>>>>>>>Hope this could help  a solution.
>>>>>>>
>>>>>>>That setting is done in a number of places, which exact one
>>>>>>>do you think is causing your problem?
>>>>>>>
>>>>>>>Regards
>>>>>>>Greg
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>On Tue, 18 Oct 2005 16:44:20 +1000, Greg Ungerer wrote
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>Hi Stefano,
>>>>>>>>>
>>>>>>>>>Stefano Caioli wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>Hi all,
>>>>>>>>>>I'm trying to boot uClinux from flash, but on FEC init the system 
>>>>>>>>>>freezes.
>>>>>>>>>>If i execute the same image from ram it works.
>>>>>>>>>>Any suggestions?
>>>>>>>>>>Thanks.
>>>>>>>>>>
>>>>>>>>>>          Stefano.
>>>>>>>>>>
>>>>>>>>>>This is the output:
>>>>>>>>>>
>>>>>>>>>>uClinux/COLDFIRE(m523x)
>>>>>>>>>>COLDFIRE port done by Greg Ungerer, gerg at snapgear.com
>>>>>>>>>>Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne
>>>>>>>>>>Motorola M5235EVB support (C)2005 Syn-tech Systems, Inc. (Jate 
>>>>>>>>>>Sujjavanich)<7>O6Built 1
>>>>>>>>>>zonelists
>>>>>>>>>>Kernel command line: root=1f00
>>>>>>>>>>PID hash table entries: 128 (order: 7, 2048 bytes)
>>>>>>>>>>Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
>>>>>>>>>>Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
>>>>>>>>>>Memory available: 14616k/16384k RAM, 0k/0k ROM (866k kernel code, 
>>>>>>>>>>147k data)
>>>>>>>>>>Mount-cache hash table entries: 512
>>>>>>>>>>NET: Registered protocol family 16
>>>>>>>>>>i8042.c: i8042 controller self test timeout.
>>>>>>>>>>ColdFire internal UART serial driver version 1.00
>>>>>>>>>>ttyS0 at 0x40000200 (irq = 77) is a builtin ColdFire UART
>>>>>>>>>>ttyS1 at 0x40000240 (irq = 78) is a builtin ColdFire UART
>>>>>>>>>>io scheduler noop registered
>>>>>>>>>>io scheduler cfq registered
>>>>>>>>>>RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
>>>>>>>>>>FEC ENET Version 0.2
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>When you RAM boot what is the next kernel subsystem to print
>>>>>>>>>out messages?
>>>>>>>>>
>>>>>>>>>If it is MTD then it may be that the MTD flash probe is killing
>>>>>>>>>your kernel running from flash...
>>>>>>>>>
>>>>>>>>>Regards
>>>>>>>>>Greg
>>>>>>>>>
>>>>>>>>>------------------------------------------------------------------------
>>>>>>>>>Greg Ungerer  --  Chief Software Dude       EMAIL:     gerg at snapgear.com
>>>>>>>>>SnapGear -- a CyberGuard Company            PHONE:       +61 7 3435 2888
>>>>>>>>>825 Stanley St,                             FAX:         +61 7 3891 3630
>>>>>>>>>Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com
>>>>>>>>>_______________________________________________
>>>>>>>>>uClinux-dev mailing list
>>>>>>>>>uClinux-dev at uclinux.org
>>>>>>>>>http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>>>>>>>>>This message was resent by uclinux-dev at uclinux.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>**********************************
>>>>>>>>
>>>>>>>>InfStudio
>>>>>>>>Consulenza Informatica e Elettronica
>>>>>>>>Via Pisana 267A/r
>>>>>>>>50142 Firenze
>>>>>>>>http://www.infstudio.it/
>>>>>>>>
>>>>>>>>_______________________________________________
>>>>>>>>uClinux-dev mailing list
>>>>>>>>uClinux-dev at uclinux.org
>>>>>>>>http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>>>>>>>>This message was resent by uclinux-dev at uclinux.org
>>>>>>>>
>>>>>>>
>>>>>>-- 
>>>>>>------------------------------------------------------------------------
>>>>>>Greg Ungerer  --  Chief Software Dude       EMAIL:     gerg at snapgear.com
>>>>>>SnapGear -- a CyberGuard Company            PHONE:       +61 7 3435 2888
>>>>>>825 Stanley St,                             FAX:         +61 7 3891 3630
>>>>>>Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com
>>>>>>_______________________________________________
>>>>>>uClinux-dev mailing list
>>>>>>uClinux-dev at uclinux.org
>>>>>>http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>>>>>>This message was resent by uclinux-dev at uclinux.org
>>>>>
>>>>>
>>>>>
>>>>>**********************************
>>>>>
>>>>>InfStudio
>>>>>Consulenza Informatica e Elettronica
>>>>>Via Pisana 267A/r
>>>>>50142 Firenze
>>>>>http://www.infstudio.it/
>>>>>
>>>>>_______________________________________________
>>>>>uClinux-dev mailing list
>>>>>uClinux-dev at uclinux.org
>>>>>http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>>>>>This message was resent by uclinux-dev at uclinux.org
>>>>>
>>>>
>>>>-- 
>>>>------------------------------------------------------------------------
>>>>Greg Ungerer  --  Chief Software Dude       EMAIL:     gerg at snapgear.com
>>>>SnapGear -- a CyberGuard Company            PHONE:       +61 7 3435 2888
>>>>825 Stanley St,                             FAX:         +61 7 3891 3630
>>>>Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com
>>>>_______________________________________________
>>>>uClinux-dev mailing list
>>>>uClinux-dev at uclinux.org
>>>>http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>>>>This message was resent by uclinux-dev at uclinux.org
>>>
>>>
>>>
>>>**********************************
>>>
>>>InfStudio
>>>Consulenza Informatica e Elettronica
>>>Via Pisana 267A/r
>>>50142 Firenze
>>>http://www.infstudio.it/
>>>
>>>_______________________________________________
>>>uClinux-dev mailing list
>>>uClinux-dev at uclinux.org
>>>http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>>>This message was resent by uclinux-dev at uclinux.org
>>>
>>
>>-- 
>>------------------------------------------------------------------------
>>Greg Ungerer  --  Chief Software Dude       EMAIL:     gerg at snapgear.com
>>SnapGear -- a CyberGuard Company            PHONE:       +61 7 3435 2888
>>825 Stanley St,                             FAX:         +61 7 3891 3630
>>Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com
>>_______________________________________________
>>uClinux-dev mailing list
>>uClinux-dev at uclinux.org
>>http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>>This message was resent by uclinux-dev at uclinux.org
> 
> 
> 
> **********************************
> 
> InfStudio
> Consulenza Informatica e Elettronica
> Via Pisana 267A/r
> 50142 Firenze
> http://www.infstudio.it/
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> 

-- 
------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Dude       EMAIL:     gerg at snapgear.com
SnapGear -- a CyberGuard Company            PHONE:       +61 7 3435 2888
825 Stanley St,                             FAX:         +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com



More information about the uClinux-dev mailing list