[uClinux-dev] FEC freezes on m5235evb from flash

Stefano Caioli caioli at infstudio.it
Wed Oct 19 10:07:26 EDT 2005


Hi Greg,
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.
However i get the usual message:

FEC ENET Version 0.2
eth0: ethernet bf:ff:ef:7e:ff:be
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? 

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/




More information about the uClinux-dev mailing list