2010-07-22 12:21:23     Network control from within uCLinux

Document created by Aaronwu Employee on Aug 22, 2013
Version 1Show Document
  • View in full screen mode

2010-07-22 12:21:23     Network control from within uCLinux

Wojtek Skulski (UNITED STATES)

Message: 91596   

 

Hi:

 

is there a way to control network from within uCLinux, once it is runnig? I loaded uClinux via RS-232 (because U-Boot has a networking problem) and I am trying to test the networking from within. The content of embedded /etc is of course completely different from full-blown Debian and there is no pico editor on the board. So managing this stuff is different from coLinux. Can I mange the network from within uCLinux and how?

 

Here is the output from ifconfig copied from the serial console. The board's ether is not set. How to set it up? Is it documented anywhere on Wiki? If this cannot be done from within, then where are the files on the host computer to set this up?

 

root:/> ifconfig

lo        Link encap:Local Loopback

          inet addr:127.0.0.1  Mask:255.0.0.0

          UP LOOPBACK RUNNING  MTU:16436  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0

          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

 

root:/> cd /etc

QuoteReplyEditDelete

 

 

2010-07-22 12:32:19     Re: Network control from within uCLinux

Mike Frysinger (UNITED STATES)

Message: 91598   

 

changing the network under Linux works exactly the same on the Blackfin as it does on your host

 

you already know the relevant wiki page:

  docs.blackfin.uclinux.org/doku.php?id=setting_up_the_network

QuoteReplyEditDelete

 

 

2010-07-22 12:53:42     Re: Network control from within uCLinux

Wojtek Skulski (UNITED STATES)

Message: 91600   

 

Mike: thanks. I am getting lost in the maze of pages. This one is not linked in the left column. Could you pls link it under "The Linux kernel"? I also suggest changing "The Linux kernel" to  "uCLinux kernel" or "Embedded kernel". There are too many unqualified "Linuxes" around and navigation is getting murky.

 

An unrelated note: on the page   docs.blackfin.uclinux.org/doku.php?id=bootloaders:u-boot:serial-flash change the following:

 

bfin> set sfboot 'sf read 0x2000000 0x300 0x100000; bootm 0x2000000'

 

 

to:

 

bfin> set sfboot 'sf probe 2; sf read 0x2000000 0x300 0x100000; bootm 0x2000000'

 

 

Without sf probe the sfboot command fails. It would also be helpful to parametrize with $(loadaddr) and $(filesize) or whatever variables are relevant.

QuoteReplyEditDelete

 

 

2010-07-22 13:19:05     Re: Network control from within uCLinux

Wojtek Skulski (UNITED STATES)

Message: 91601   

 

Mike: The very first command copied    docs.blackfin.uclinux.org/doku.php?id=setting_up_the_network: reports some sort of problem. However, the address has been assigned. However, the HW address is not setup, even though it was hardcoded in U-Boot. And ping does not work. I am afraid my only option is to wait for Analog Devices hardware and verify if all this is working with your boards.

 

root:/etc> ifconfig eth0 169.254.144.145 netmask 255.255.255.0 up

ifconfig: SIOCSIFFLAGS: Cannot assign requested address

root:/etc> ifconfig eth0

eth0      Link encap:Ethernet  HWaddr 00:00:00:00:00:00

          inet addr:169.254.144.145  Bcast:169.254.255.255  Mask:255.255.0.0

          BROADCAST MULTICAST  MTU:1500  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

          Interrupt:83

 

root:/etc> ping 169.254.144.144

PING 169.254.144.144 (169.254.144.144): 56 data bytes

ping: sendto: Network is unreachable

QuoteReplyEditDelete

 

 

2010-07-22 13:24:20     Re: Network control from within uCLinux

Mike Frysinger (UNITED STATES)

Message: 91603   

 

no, it is not the uClinux kernel.  there is no such thing.  there is only the Linux kernel.  there is a uClinux distribution, but that is still not a kernel.

 

i'll update the serial flash page as you suggested.

QuoteReplyEditDelete

 

 

2010-07-22 13:28:39     Re: Network control from within uCLinux

Mike Frysinger (UNITED STATES)

Message: 91604   

 

u-boot setting up the mac doesnt have too much bearing on the kernel.  you'll have to review the axis driver to see how it supports custom macs if `ifconfig hw` and `macchanger` dont work.  or program the MAC into the hardware itself.

 

if you dont have a valid MAC, then there's no point in attempting to setup layer 3 of the network.

QuoteReplyEditDelete

 

 

2010-07-22 14:10:14     Re: Network control from within uCLinux

Wojtek Skulski (UNITED STATES)

Message: 91605   

 

Mike:

 

I have plenty of MAC numbers from broken networking cards under my desk which I collected for such occassions. These are valid MACs, I suppose. I was just trying to read about the macchanger. The info on your page only says how it can examine existing MAC, but I suppose it can also set a MAC. I will try to find out.

 

There are promising apps in the kernel build list such as mii-tool or mii-tool-fec. I am looking for the documentation of these. If you know where it is then please point out.

 

If you have other suggestions which apps can possibly probe the network traffic, then please suggest. At this point I only need to determine whether the hardware is working. I am holding off building more hardware until I know that the proto board is not broken.

 

I can hold off with higher networking layers till later. At this point I only need to know whether the HW is working at the physical layer. Anything will be useful which helps determine this.

QuoteReplyEditDelete

 

 

2010-07-22 14:38:14     Re: Network control from within uCLinux

Robin Getz (UNITED STATES)

Message: 91606   

 

Wojtek:

 

On your host - use wireshark - as long as you don't have a switch between you and the board - you should see all traffic.

 

  www.wireshark.org/

 

-Robin

QuoteReplyEditDelete

 

 

2010-07-22 18:24:38     Re: Network control from within uCLinux

Wojtek Skulski (UNITED STATES)

Message: 91619   

 

Robin:

 

thanks a lot. WireShark seems even more useful than the activity LED, especially if the two are consistent. With here is no traffic on my dedicated card, and the reason is this:

 

root:/etc> ifconfig eth0 up

ax88180: The MAC address is 00:12:34:56:78:9a

ax88180: Unknown PHY chipset!!

ax88180: Waiting for auto-negotiation completion......

ax88180: name=eth0, Phy_MemBase=0x2c000000, IRQ=83, media=0, jumbo=1

ax88180: The AX88180 driver is loaded successfully.

root:/etc>

 

 

The "unknown chipset" is strange, because I selected both AX88180 and Marvell PHY drivers, which are a separate item in menuconfig.

 

The Linux kernel behaves inconsistently with U-Boot, which reports (via debug printouts):

 

Net:   ax88180_phy_initial: Found Marvell Alaska PHY family. (PHY Addr=0x18)

ax88180_phy_initial: Default to 88E1111 Phy

ax88180_phy_initial: found RGMII_COPPER_MODE

ax88180

 

 

I wish I could somehow probe MII bus, but Mike said this does not work in U-Boot. I wonder if I could do this in uCLinux?

QuoteReplyEditDelete

 

 

2010-07-22 18:31:14     Re: Network control from within uCLinux

Mike Frysinger (UNITED STATES)

Message: 91620   

 

more specifically, it doesnt work for that driver in u-boot

 

i dont think there are any low level mii tools under Linux like u-boot.  most tools allow you to poke specific mii bits, but not do raw bit banging of registers and see the result.

 

you can see the marvell phys actually supported n drivers/net/phy/marvell.c

QuoteReplyEditDelete

 

 

2010-07-22 19:19:07     Re: Network control from within uCLinux

Wojtek Skulski (UNITED STATES)

Message: 91625   

 

Mike: this PHY type m88e1111 is of course supported under Linux in the file drivers/net/phy/marvell.c.

 

 

 

One thing that gives me hope is this. I have two network cards, a 10/100 Linksys which I am using for tests and and a very old 10 mbps SVEC, which does not even have Windows XP driver. When I used Linksys, the Link100 and FullDuplex LEDs lights up and U-Boot reports:

 

bfin> ping 169.254.144.144

ax88180: BMSR=0x796d

ax88180: Auto-negotiation is enabled. Waiting for NWay completion..

ax88180: BMCR=0x1000, BMSR=0x796d

ax88180: 100Mbps Full-duplex mode.

Using ax88180 device

 

 

When I plugged the cable into SVEC, the Link10 LED lit up. The FullDuplex is dark. U-Boot reported:

 

bfin> ping 169.254.144.144

ax88180: BMSR=0x796d

ax88180: Auto-negotiation is enabled. Waiting for NWay completion..

ax88180: BMCR=0x1000, BMSR=0x796d

ax88180: 10Mbps Half-duplex mode.

 

 

The autonegotiation is performed by PHY, so if this info makes it into the terminal, there must have been communication from the PHY --> MAC chip --> CPU under U-Boot.

 

My conclusion: ucLinux kernel is further away from supporting this chipset than U-Boot. It looks like a software problem to me.

QuoteReplyEditDelete

 

 

2010-07-23 01:50:19     Re: Network control from within uCLinux

Wojtek Skulski (UNITED STATES)

Message: 91631   

 

Mike:

 

I am attaching two files. The first is the AX88180 driver for U-Boot with MII support. I hacked it into two places: near the top of the file under comment "MII handler added by WS", and at the very end where miiphy_register is called. The hack consists of using a static global variable "static struct eth_device * dev_global;" (i.e., a singleton). I did this because the calling parameters of miiphy_ are incompatible with ax88180_mdio_ which are actually implementing the work. In one case it is the device name, in the other the pointer to the device descriptor. The implementation would have been easy if the MII framework provided a method to retrieve the device descriptor by name. It does not, as far as I can tell. The global variable is a workaround.

 

Could you please add this MII support to U-Boot after fixing the global variable, which is not compatible with the MULTI design? I am not sure how this can be done, but you know the MULTI much better than I do.

 

The other file is a record of probing the MII bus under U-Boot. As one can see, there are registers there. I will try to dissect the situation using the MII probe.

 

An immediate conclusion from this work is that the ucLinux kernel support is broken for the AX88180 chip in the kernel which I am using. The kernel does not recognize the PHY, which most definitely is there. This kernel comes from the following .bz2 file: uClinux-dist-2009R1.1-RC4.tar.bz2.

 

The U-Boot from the u-boot-2008.10-2009R1.1-rc1.tar.bz2 also had the problem with AX88180. These two .bz2 files were released together. It seems quite likely that some related work broke the AX88180 both in the kernel and in U-boot. It is just a  plausible guess, of course.

 

PHY.txt

ax88180_July23_2010.c

QuoteReplyEditDelete

 

 

2010-07-23 02:19:22     Re: Network control from within uCLinux

Mike Frysinger (UNITED STATES)

Message: 91632   

 

look at drivers/net/fec_mxc.c's fec_miiphy_read() to see how to do it the right way

QuoteReplyEditDelete

 

 

2010-07-24 15:58:16     Re: Network control from within uCLinux

Wojtek Skulski (UNITED STATES)

Message: 91682   

 

Robin and Mike:

 

I gathered more info. The problem looks mysterious. First, the autonegotiation works. Second, all HW signals between the MAC and the PHY probe OK with the scope. The RGMII is working in both directions. The RGMII strobes are strobing, both TX and RX. The clocks are clocking, and all four wires are toggling in both directions, both RX and TX. Third, packet capture works OK at the Blackfin side. I printed the packets with debug statements from within the U-Boot receive function. The content matches the content shown with WireShark at the PC side, byte by byte. (There is one difference: the packet length in bytes reported at the Blackfin side is always +4 larger than what WireShark is showing. That is a minor problem and probably inconsequential.)

 

From the above I conclude that receiving is fully working both in hardware and in software. The transmission from Blackfin to PC seems to work, but only in low-level hardware.

 

Transmission BF --> PC looks mystifying. Every time I issue "ping", the activity LEDs are blinking at both sides. The Blackfin side, which has a TX LED, blinks that LED. The PC side, which has "activity LED", blinks its LED. However, WireShark shows no packets arriving from the board. I put WireShark at promiscuous mode. It is not showing anything.

 

How is this possible, that PC blinks its LED, but WireShark is not showing the packet? Is there any trick to play with the packet capture to print the received data?

 

At this point I only want to see any bytes sent from the board to the PC. I am only concerned with hardware in order to decide on the production run of these boards.

QuoteReplyEditDelete

 

 

2010-07-24 20:25:56     Re: Network control from within uCLinux

Mike Frysinger (UNITED STATES)

Message: 91683   

 

dont know which +4 you're talking about, but the mac peripheral will transfer some metadata for software to process

QuoteReplyEditDelete

 

 

2010-07-24 21:35:56     Re: Network control from within uCLinux

Wojtek Skulski (UNITED STATES)

Message: 91684   

 

Regarding +4, there are no clues in the ax88180 driver, but in the smc91111.c there is a comment that the first two words are status and packet_length. In smc91111.c there is also the following program statement "packet_length -= 4;". There is no corresponding such adjustment in the ax88180.c Not that I am saying it is needed. Maybe not. I noticed the difference while comparing the two drivers.

 

On the transmit side, in smc91111.c there is a comment that packet size for allocating is data length +6 (for additional status words, length and ctl). In smc91111.c under the 32-bit version of code they do this:

    SMC_outl (dev, (length + 6) << 16, SMC91111_DATA_REG);

 

There is no similar adjustment in the ax88180 driver. Again, I am not saying it is needed. I do not know. These are different chips after all.

 

At this point I am trying to see any data at the PC side. I am just wondering what can be the mechanism that the packets are being dropped despite LEDs happily blinking.

 

I looked at the AX88180 TX status register and the error count. There are such registers already defined in the .h file. Both registers report successful transmission. The code is simple:

 

        tx_status = INW (dev, TXST);  /*TX status, AX88180 Data Sheet p.27*/

        debug ("ax88180_send: TX status register= %x (0 is success)\n", tx_status);

        tx_fail_ctr = INW (dev, TXFAILCNT);  /*Fail cntr, AX88180 Data Sheet p.28*/

        debug ("ax88180_send: TX fail cntr= %x (0 is good)\n",  tx_fail_ctr);

 

The runtime result is of course positive, despite the fact that nothing comes out the other cable end. :

 

ax88180_send: TX status register= 0 (0 is success)

ax88180_send: TX fail cntr= 0 (0 is good)

Outcomes