• Home
  • Help
  • Search
  • Login
  • Register
Pages: 1 [2]
Author Topic: Network Issues after U-Boot Update 3.4.24 Downgrade 3.4.19  (Read 7808 times)
samweber
Jr. Member
**

Karma: 0
Posts: 61


View Profile
« Reply #15 on: November 24, 2009, 06:01:43 AM »

I recently upgraded to v3.4.25 u-boot and the latest kernel (2.6.31.6).  When I boot normally, I can't ping.  Running "/etc/init.d/networking restart" does not help.  In this condition, the plug won't respond to ARP requests and throws them away when it receives them.  But if I interrupt the boot process and ping an address from u-boot before allowing the plug to boot linux, everything works beautifully.  Any idea what is going on?
Logged

odoll
Full Member
***

Karma: 0
Posts: 148


View Profile
« Reply #16 on: November 25, 2009, 10:16:13 AM »

hm, since my plug was already on u-boot 3.4.25 and I couldn't boot fron SD any longer but from NAND I decided to test your ping issue and updated my spare plug from 2.6.31.1 in NAND to 2.6.31.6 (http://plugcomputer.org/plugforum/index.php?topic=921.msg5861#msg5861)

Unfortunately it doesn't boot any longer from NAND neither, now. I get a "Bad Magic Number" message. Couldn't get it solved so far (only limited time). Looks like I've to recover as explained in http://plugcomputer.org/plugforum/index.php?topic=921.msg5979#msg5979!?

Or would it be more easy to do a NAND 1-to-1 dump from my primary to my spare plug (going back to 3.4.19 and 2.6.31.1 in NAND in one go)?
« Last Edit: November 25, 2009, 10:20:45 AM by odoll » Logged

samweber
Jr. Member
**

Karma: 0
Posts: 61


View Profile
« Reply #17 on: November 25, 2009, 10:36:23 AM »

I REALLY appreciate someone trying to help with my ping issue.  Thanks.

I abandoned booting from nand after I had the same problem you note below with "Bad Magic Number".  If I had to revert, I'd use the recipe from the user's manual that I followed to set up the plug originally.
Logged

mgillespie
Full Member
***

Karma: 7
Posts: 239



View Profile
« Reply #18 on: November 25, 2009, 02:54:45 PM »

Not sure how much I can help, but I have the 3.4.25 u-boot, kernel 2.6.31.6 (sheeva-with-linux) and debian squeeze on internal NAND (using my alternative method), and ping works just fine regardless of what I do.
Logged

samweber
Jr. Member
**

Karma: 0
Posts: 61


View Profile
« Reply #19 on: November 25, 2009, 05:19:51 PM »

Since things work if I first ping from u-boot, that means that the ping or the ARP that precedes it fixes or initializes something.  Linux can't know that I did a ping before booting so the u-boot ping is  either initializing the hardware or setting up or cleaning something in RAM.  Okay, fine.  How would you debug such a thing?  How can I determine why, when the system is in the stupid state, it receives packets but throws them the floor?
Logged

DamonHD
Full Member
***

Karma: 4
Posts: 169


View Profile WWW
« Reply #20 on: November 26, 2009, 02:19:43 AM »

Hi,

When you run tcpdump (promiscuous mode) with the machine in 'stupid' mode, what do you see of traffic arriving at the hardware interface?

Rgds

Damon
Logged

samweber
Jr. Member
**

Karma: 0
Posts: 61


View Profile
« Reply #21 on: November 26, 2009, 05:01:43 AM »

Thanks for the suggestion.  It is a good one.  Everything I know so far about the problem has been learned by running Ethereal and seeing that the plug generates ARP's but apparently throws away any packet it receives.  Pursuing the problem with a network tool inside the device sounds right.  I see that tcpdump is not a part of my RFS so I'll have to find it and cross-compile for the plug.  I'll post when I know something.
Logged

samweber
Jr. Member
**

Karma: 0
Posts: 61


View Profile
« Reply #22 on: November 26, 2009, 07:03:36 AM »

My tcpdump capture appears below.  Summary: No rx packets are seen by tcpdump.  While simultaneously watching the network with WireShark, I can see that 192.168.76.43 does respond to the ARP but the plug (192.168.76.42, salient) ignores it.

------------

root@salient:~# /sbin/ifconfig
eth0      Link encap:Ethernet  HWaddr 00:50:43:01:c3:b2
          inet addr:192.168.76.42  Bcast:192.168.76.255  Mask:255.255.255.0
          inet6 addr: fe80::250:43ff:fe01:c3b2/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1307 errors:1307 dropped:1307 overruns:0 frame:0
          TX packets:132 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:86483 (86.4 KB)  TX bytes:5760 (5.7 KB)
          Interrupt:11

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:135 errors:0 dropped:0 overruns:0 frame:0
          TX packets:135 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:14656 (14.6 KB)  TX bytes:14656 (14.6 KB)

root@salient:~# /sbin/ifconfig eth0 promisc
root@salient:~# /sbin/ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:50:43:01:c3:b2
          inet addr:192.168.76.42  Bcast:192.168.76.255  Mask:255.255.255.0
          inet6 addr: fe80::250:43ff:fe01:c3b2/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:1326 errors:1326 dropped:1326 overruns:0 frame:0
          TX packets:132 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:88104 (88.1 KB)  TX bytes:5760 (5.7 KB)
          Interrupt:11

root@salient:~# tcpdump -A -v &
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
[4] 1612
root@salient:~# ping 192.168.76.43
PING 192.168.76.43 (192.168.76.43) 56(84) bytes of data.
17:13:46.795592 arp who-has 192.168.76.43 tell salient
.........PC.....L*........L+
17:13:46.795592 arp who-has 192.168.76.43 tell salient
.........PC.....L*........L+
17:13:46.795592 arp who-has 192.168.76.43 tell salient
.........PC.....L*........L+
17:13:46.795592 arp who-has 192.168.76.43 tell salient
.........PC.....L*........L+
17:13:47.795580 arp who-has 192.168.76.43 tell salient
.........PC.....L*........L+
17:13:47.795580 arp who-has 192.168.76.43 tell salient
.........PC.....L*........L+
17:13:47.795580 arp who-has 192.168.76.43 tell salient
.........PC.....L*........L+
17:13:47.795580 arp who-has 192.168.76.43 tell salient
.........PC.....L*........L+
17:13:48.795576 arp who-has 192.168.76.43 tell salient
.........PC.....L*........L+
17:13:48.795576 arp who-has 192.168.76.43 tell salient
.........PC.....L*........L+
17:13:48.795576 arp who-has 192.168.76.43 tell salient
.........PC.....L*........L+
17:13:48.795576 arp who-has 192.168.76.43 tell salient
.........PC.....L*........L+
From 192.168.76.42 icmp_seq=1 Destination Host Unreachable
From 192.168.76.42 icmp_seq=2 Destination Host Unreachable
From 192.168.76.42 icmp_seq=3 Destination Host Unreachable
17:13:49.805578 arp who-has 192.168.76.43 tell salient
.........PC.....L*........L+
17:13:49.805578 arp who-has 192.168.76.43 tell salient
.........PC.....L*........L+
17:13:49.805578 arp who-has 192.168.76.43 tell salient
.........PC.....L*........L+
17:13:49.805578 arp who-has 192.168.76.43 tell salient
.........PC.....L*........L+
17:13:50.805576 arp who-has 192.168.76.43 tell salient
.........PC.....L*........L+
17:13:50.805576 arp who-has 192.168.76.43 tell salient
.........PC.....L*........L+
17:13:50.805576 arp who-has 192.168.76.43 tell salient
.........PC.....L*........L+
17:13:50.805576 arp who-has 192.168.76.43 tell salient
.........PC.....L*........L+
17:13:51.805576 arp who-has 192.168.76.43 tell salient
.........PC.....L*........L+
17:13:51.805576 arp who-has 192.168.76.43 tell salient
.........PC.....L*........L+
17:13:51.805576 arp who-has 192.168.76.43 tell salient
.........PC.....L*........L+
17:13:51.805576 arp who-has 192.168.76.43 tell salient
.........PC.....L*........L+
From 192.168.76.42 icmp_seq=5 Destination Host Unreachable
From 192.168.76.42 icmp_seq=6 Destination Host Unreachable
From 192.168.76.42 icmp_seq=7 Destination Host Unreachable
17:13:53.805577 arp who-has 192.168.76.43 tell salient
.........PC.....L*........L+
17:13:53.805577 arp who-has 192.168.76.43 tell salient
.........PC.....L*........L+
17:13:53.805577 arp who-has 192.168.76.43 tell salient
.........PC.....L*........L+
17:13:53.805577 arp who-has 192.168.76.43 tell salient
.........PC.....L*........L+
17:13:54.805576 arp who-has 192.168.76.43 tell salient
.........PC.....L*........L+
17:13:54.805576 arp who-has 192.168.76.43 tell salient
.........PC.....L*........L+
17:13:54.805576 arp who-has 192.168.76.43 tell salient
.........PC.....L*........L+
17:13:54.805576 arp who-has 192.168.76.43 tell salient
.........PC.....L*........L+
^C
--- 192.168.76.43 ping statistics ---
9 packets transmitted, 0 received, +6 errors, 100% packet loss, time 8015ms
, pipe 3
Logged

DamonHD
Full Member
***

Karma: 4
Posts: 169


View Profile WWW
« Reply #23 on: November 26, 2009, 09:55:26 AM »

And have you tested that sending a ping (or some other raw packet out) gets something out on to the wire?

Could it be something like failing to negotiate the connection type (10/100/1000Mbps full/half duplex)?

Rgds

Damon
Logged

samweber
Jr. Member
**

Karma: 0
Posts: 61


View Profile
« Reply #24 on: November 26, 2009, 02:56:19 PM »

Yes, I can see in WireShark when I ping that ARP's are getting from the plug to the network.  They must be well formed because each ARP gets a response from the device of interest.  The RX packets, however, are never seen by the plug.
Logged

pingtoo
Sr. Member
****

Karma: 15
Posts: 318


View Profile
« Reply #25 on: November 26, 2009, 04:35:16 PM »

samweber,

I guessing it is because the uboot did not initialize ethernet device correctly. when you ping in uboot it reinitialized the ethernet device. may be post your uboot env. we can check if something is unusual. may be post the env. right after power on.

I have one time experiencing a strange linux error, this is after I have refresh uboot using the sheeva-installer while putty also open the ttyUSB1 at same time. after the refresh, linux will boot half way then it stop. I realize then putty was sharing the ttyUSB1, so I refresh uboot everything work fine after refresh.
Logged

Good Luck Smiley

samweber
Jr. Member
**

Karma: 0
Posts: 61


View Profile
« Reply #26 on: November 27, 2009, 11:28:02 AM »

Here's my environment.  I compared the output of printenv before and after the pings in u-boot (I'm desperate).  They are the same.  Of course.

------------

Marvell>> printenv
baudrate=115200
loads_echo=0
rootpath=/mnt/ARM_FS/
netmask=255.255.255.0
run_diag=yes
console=console=ttyS0,115200 mtdparts=nand_mtd:0xc0000@0(uboot)ro,0x1ff00000@0x1
00000(root)
CASset=min
MALLOC_len=1
ethprime=egiga0
bootargs_root=root=/dev/nfs rw
bootargs_end=:::DB88FXX81:eth0:none
image_name=uImage
standalone=fsload 0x2000000 $(image_name);setenv bootargs $(console) root=/dev/m
tdblock0 rw ip=$(ipaddr):$(serverip)$(bootargs_end) $(mvPhoneConfig); bootm 0x20
00000;
ethmtu=1500
mvPhoneConfig=mv_phone_config=dev0:fxs,dev1:fxs
mvNetConfig=mv_net_config=(00:11:88:0f:62:81,0:1:2:3),mtu=1500
usb0Mode=host
yuk_ethaddr=00:00:00:EE:51:81
nandEcc=1bit
netretry=no
rcvrip=169.254.100.100
loadaddr=0x02000000
autoload=no
ethact=egiga0
serverip=192.168.76.100
ipaddr=192.168.76.42
bootargs=console=ttyS0,115200 root=/dev/mmcblk0p1 rw
bootcmd=mmcinit; nand read.e 0x00800000 0x00100000 0x00400000; bootm 0x00800000
arcNumber=2097
ethaddr=00:50:43:01:C3:B2
stdin=serial
stdout=serial
stderr=serial
mainlineLinux=yes
enaMonExt=no
enaCpuStream=no
enaWrAllo=no
pexMode=RC
disL2Cache=no
setL2CacheWT=yes
disL2Prefetch=yes
enaICPref=yes
enaDCPref=yes
sata_dma_mode=yes
netbsd_en=no
vxworks_en=no
bootdelay=3
disaMvPnp=no
enaAutoRecovery=yes
pcieTune=no

Environment size: 1241/131068 bytes
Logged

pingtoo
Sr. Member
****

Karma: 15
Posts: 318


View Profile
« Reply #27 on: November 27, 2009, 12:41:17 PM »

Will, I can not find any difference in the env. variables.

From the look of source code I notice there are several reference to led code during initialize phase, so when the plug just power on with the network cable plug in does the two leds on the rj45 come on? I guess without compile a debug version of uboot we will not able to find where it went wrong.

My suggest of work around will be, put the ping command in the bootcmd for example,
Code:
bootcmd=mmcinit; nand read.e 0x00800000 0x00100000 0x00400000; ping 192.168.76.42; bootm 0x00800000
or you can try to re-flash the uboot again may be this time the process will set register right.

Good luck Smiley
Logged

Good Luck Smiley

samweber
Jr. Member
**

Karma: 0
Posts: 61


View Profile
« Reply #28 on: November 28, 2009, 10:19:24 AM »

I've reloaded u-boot at least a dozen times and I'm sure I'll do it a dozen more.  If that fixes anything, I'll post.

I did try the suggested workaround and ended up learning something.  If I set the bootcmd to "mmcinit; ping 192.168.76.42; nand read.e 0x00800000 0x00100000 0x00400000; bootm 0x00800000", pinging works after I boot.  The new information is that 192.168.76.42 is the IP address of the plug, not an external device.  So just pinging itself from u-boot accomplishes the same initialization as pinging another device on the network.  It seems like a u-boot maintainer should be mighty interested in what is going on here.

Both ethernet lights do come on during u-boot's control phase, go out briefly during Linux start up, and are both lit again well before I login.
Logged

pingtoo
Sr. Member
****

Karma: 15
Posts: 318


View Profile
« Reply #29 on: November 28, 2009, 01:12:08 PM »

That kind of proved my point. for some reason your board is in wrong condition when kernel boot up. I think I read somewhere state that kernel require boot loader reset all peripherals before it load kernel.

I check uboot source code verified that ping will re-initialize ethernet device. however I just can not find when uboot first loaded where it reset the device. I suspect it was done during the flashing. in the installer the board configuration file show the sheevaplug_init call setup whole bunch of registers that is why I suggest re-flash may do something.

Logged

Good Luck Smiley

Pages: 1 [2]
Print
Jump to: