[uClinux-dev] MCF5275EVB & UC Linux
Michael Broughton
mbobowik at telusplanet.net
Tue Jan 16 14:46:33 EST 2007
It does apply to a few other Coldfires (520x, 523x, 527x, 528x, 532x).
Also, you aren't supposed to write to the 'Receive Control Register'
while the Ethernet module is enabled. This could cause problems for
people wanting to use promiscuous mode.
If you want to see my version of set_multicast_list, look a few posts
down when I last posted my big mcf_fec.patch. You won't be able to do a
straight copy over to the old fec driver (2.4 or 2.6) but it should give
you a good idea of what needs to be done.
Mike
Andrew Webster wrote:
> On the subject of fec.c, it looks like the multicast setup is
> incorrect. When multicast addresses are added, they should be added
> to the group hash table (fec_grp_hash_table_high and
> fec_grp_hash_table_low) but the addresses are added to the individual
> hash table instead (fec_hash_table_high and fec_hash_table_low). This
> leaves the group hash table uninitialized which can cause multicast
> packets on some addresses to be ignored.
>
> I noticed this on 2.4.27 running on a 5208. I'm not sure if this
> change applies to all coldfires, but it looks like it is at least a
> problem on the 5275 as well.
>
> Here is my diff from 2.4.27.
>
> Index: fec.c
> ===================================================================
> --- fec.c (revision 219)
> +++ fec.c (revision 220)
> @@ -2275,13 +2275,13 @@
> /* Catch all multicast addresses, so set the
> * filter to all 1's.
> */
> - ep->fec_hash_table_high = 0xffffffff;
> - ep->fec_hash_table_low = 0xffffffff;
> + ep->fec_grp_hash_table_high = 0xffffffff;
> + ep->fec_grp_hash_table_low = 0xffffffff;
> } else {
> /* Clear filter and add the addresses in hash register.
> */
> - ep->fec_hash_table_high = 0;
> - ep->fec_hash_table_low = 0;
> + ep->fec_grp_hash_table_high = 0;
> + ep->fec_grp_hash_table_low = 0;
>
> dmi = dev->mc_list;
>
> @@ -2310,9 +2310,9 @@
> hash = (crc >> (32 - HASH_BITS)) & 0x3f;
>
> if (hash > 31)
> - ep->fec_hash_table_high |= 1 << (hash - 32);
> + ep->fec_grp_hash_table_high |= 1 << (hash - 32);
> else
> - ep->fec_hash_table_low |= 1 << hash;
> + ep->fec_grp_hash_table_low |= 1 << hash;
> }
> }
> }
> @@ -2406,6 +2406,8 @@
> FEC_ENET_RXF | FEC_ENET_RXB | FEC_ENET_MII);
> fecp->fec_hash_table_high = 0;
> fecp->fec_hash_table_low = 0;
> + fecp->fec_grp_hash_table_high = 0;
> + fecp->fec_grp_hash_table_low = 0;
> fecp->fec_r_buff_size = PKT_MAXBLR_SIZE;
> //fecp->fec_ecntrl = 2; // this is too early PSW
> fecp->fec_r_des_active = 0x01000000;
>
>
>
> On 1/16/07, *Mike Cruse* <mcruse at definium.net
> <mailto:mcruse at definium.net>> wrote:
>
> Hi Greg,
>
> I managed to get my board booting with uClinux-dist-test-20070108 just
> fine. I did not make any config changes as I did not want to
> change to
> many variables.
>
> Attached is a slightly different fec.c. There have been some include
> file changes since 2.6.17 it seems plus I had one other problem in the
> code.
>
> Anyway this version detects both National DP83848 PHY's and I
> managed to
> get eth1 working just fine but... eth0 was dead, bugger.
>
> After messing around for a while trying to get it working the
> following
> popped up.
>
> /> dhcpcd
> eth0: config: auto-negotiation on, 100FDX, 100HDX, 10FDX, 10HDX.
>
> Nov 30 00:56:25 dhcpcd[22]: timed out waiting for a valid DHCP server
> response
>
> /> />
> />
> /> ifconfig eth0
> eth0 Link encap:Ethernet HWaddr 00:08:E4:00:00:02
> BROADCAST MTU:1500 Metric:1
> RX packets:2001 errors:0 dropped:0 overruns:0 frame:0
> TX packets:411 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> Base address:0x1000
>
> /> ifconfig eth0 192.168.1.92 <http://192.168.1.92>
> eth0: config: auto-negotiation on, 100FDX, 100HDX, 10FDX, 10HDX.
> /> ping 192.168.1.2 <http://192.168.1.2>
> PING 192.168.1.2 <http://192.168.1.2> (192.168.1.2
> <http://192.168.1.2>): 56 data bytes
> NETDEV WATCHDOG: eth0: transmit timed out
> eth0: transmit timed out.
> Ring data dump: cur_tx 3880d8 (full), dirty_tx 3880d8 cur_rx: 388010
> tx: 16 buffers
> 00388080: 9c00 024e 00391000
> 00388088: 9c00 024e 00391800
> 00388090: 9c00 024e 00392000
> 00388098: 9c00 024e 00392800
> 003880a0: 9c00 002a 00393000
> 003880a8: 9c00 002a 00393800
> 003880b0: 9c00 002a 00394000
> 003880b8: 9c00 002a 00394800
> 003880c0: 9c00 002a 00395000
> 003880c8: 9c00 002a 00395800
> 003880d0: 9c00 002a 00396000
> 003880d8: 9c00 024e 00396800
> 003880e0: 9c00 024e 00397000
> 003880e8: 9c00 024e 00397800
> 003880f0: 9c00 024e 00398000
> 003880f8: bc00 024e 00398800
> rx: 16 buffers
> 00388000: 8880 0040 00389000
> 00388008: 8880 0040 00389800
> 00388010: 8880 0040 0038a000
> 00388018: 8880 0040 0038a800
> 00388020: 8880 0040 0038b000
> 00388028: 8880 0040 0038b800
> 00388030: 8880 0040 0038c000
> 00388038: 8880 0040 0038c800
> 00388040: 8880 0252 0038d000
> 00388048: 8880 0040 0038d800
> 00388050: 8880 0252 0038e000
> 00388058: 8880 0040 0038e800
> 00388060: 8880 0040 0038f000
> 00388068: 8880 0040 0038f800
> 00388070: 8880 0040 00390000
> 00388078: a880 0040 00390800
> 64 bytes from 192.168.1.2 <http://192.168.1.2>: icmp_seq=9 ttl=64
> time=1.8 ms
> 64 bytes from 192.168.1.2 <http://192.168.1.2>: icmp_seq=10 ttl=64
> time=1.3 ms
> 64 bytes from 192.168.1.2 <http://192.168.1.2>: icmp_seq=11 ttl=64
> time=1.3 ms
> 64 bytes from 192.168.1.2 <http://192.168.1.2>: icmp_seq=12 ttl=64
> time=1.3 ms
>
>
> As you can see eth0 was dead and timing out but once the ring buffer
> dump occurred I configured eth1 and everything started working.
>
> It is possible that there is a hardware problem on my board so I am
> having another board shipped to me so I can verify that one way or the
> other.
>
> If it is not hardware then perhaps the ring buffer dump followed by a
> working port is a clue.
>
> I'll let you know how my test goes.
>
> Mike Cruse
> Definium Technologies Inc.
>
> On Mon, 2007-01-15 at 16:54 +1000, Greg Ungerer wrote:
> > Hi Mike,
> >
> > Mike Cruse wrote:
> > > I am doing some work with the 5274 (5275 without crypto).
> > >
> > > I have the 2.6 kernel up and running reasonably well.
> >
> > Which version 2.6 kernel?
> >
> >
> > > I found the config process quite fragile in that while I
> essentially
> > > could build and run out of the box, once I started to make
> kernel or
> > > userland config changes I started to get these messages on boot
> > >
> > > Warning: unable to open an initial console.
> > > Kernel panic - not syncing: Attempted to kill init!
> >
> > I have used this configuration system for years, and it is
> > in no way fragile. It does exactly what you tell it to.
> >
> >
> > > I am no stranger to Linux and understand some of the things
> that cause
> > > these problems. However I did not understand why turning on ext3,
> > > enabling the second FEC and building an extra userland program
> would
> > > cause this to happen.
> >
> > It is possibly a bug.
> >
> > But I had no problems enabling those options and still loading
> > and running on the M5275EVB board (I used
> uClinux-dist-test-20070108,
> > with 2.6.19-uc1 kernel).
> >
> > If you post your full kernel boot trace and kernel configuration
> > we might be able to help.
> >
> > The most common cause of this type of problem is the romfs
> generation,
> > double check that the device nodes are being created correctly in
> > the romfs.
> >
> >
> > > Once the problem occurs I have to blow away the source tree
> and start
> > > again as I can't seem to reverse the problem.
> > >
> > > Any clues on this?
> > >
> > > Serial ports seem to work well. At least the console does.
> > > Haven't used USB or QSPI.
> > >
> > > Ethernet seems flakey. Especially when trying to use the
> second FEC.
> > > That code just does not seem complete and PHY detection just
> would not
> > > work without changes.
> > >
> > > Beyond getting both PHY's going things were still broken. eth0
> would
> > > work most of the time but while you could ping a configured
> eth1, a TCP
> > > connection could not be established. Inbound or outbound.
> >
> > I just tried with 2.6.19-uc1 and I could telnet into and out of
> > eth0 on the M5275EVB with no problems at all.
> >
> >
> > > Using Wireshark it appeared that received packets were just
> ignored.
> > >
> > > I could use some help here. Has anybody gotten both FEC's up
> and running
> > > on the 5274/5? If so how? I am using National DP83848 PHY's.
> >
> > 2.6.19-uc1 is not detecting the PHY on eth1, so there does look
> to be
> > a problem there. I can't get any data on eth1 either. I'll look
> into
> > that when I get a minute.
> >
> >
> > > That is about as much as I have played with so far.
> > >
> > > My setup is as follows:
> > >
> > > Toolchain: m68k-uclinux-tools-20060615
> > > uClinux: uClinux-dist-20060803
> > > Bootloader: colilo
> > >
> > > On the subject of bootloaders... All the bootloader links on
> uclinux.org <http://uclinux.org>
> > > are broken. It does seem that uboot is the way to go anyway
> but it seems
> > > many people have problems compiling it.
> > >
> > > Can someone tell me what toolchain to use to compile uboot?
> > >
> > > Thanks for any help in advance!
> >
> > Regards
> > Greg
> >
> >
> >
> ------------------------------------------------------------------------
> > Greg Ungerer -- Chief Software Dude EMAIL:
> gerg at snapgear.com <mailto:gerg at snapgear.com>
> > SnapGear -- a Secure Computing 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 <mailto:uClinux-dev at uclinux.org>
> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > This message was resent by uclinux-dev at uclinux.org
> <mailto:uclinux-dev at uclinux.org>
> > To unsubscribe see:
> > http://mailman.uclinux.org/mailman/options/uclinux-dev
> >
>
>
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org <mailto:uClinux-dev at uclinux.org>
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> <http://mailman.uclinux.org/mailman/listinfo/uclinux-dev>
> This message was resent by uclinux-dev at uclinux.org
> <mailto:uclinux-dev at uclinux.org>
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev
> <http://mailman.uclinux.org/mailman/options/uclinux-dev>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev
More information about the uClinux-dev
mailing list