[uClinux-dev] FEC freezes on m5235evb from flash

Stefano Caioli caioli at infstudio.it
Thu Oct 20 03:33:02 EDT 2005


Hi Greg,
thank you for your support.
I'v just mofied tha MAC address and i'll keep on testing
the mods you made to fec drv.
I'll let you know the results.
Best 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/




More information about the uClinux-dev mailing list