• Home
  • Help
  • Search
  • Login
  • Register
  Show Posts
Pages: [1] 2 3 ... 5
1  Linux Stuff / Kernel / Re: Problems cross-building 2.6.38.3 (solved) on: April 27, 2011, 12:33:27 PM
The Michlmayr procedure is excellent.  But if you rebuild a different kernel after using it, you have to modify u-boot parameters to ignore the uInitrd that came with the Debian upgrade.  Otherwise, the kernel and the uInitrd image are both invoked and the new kernel is incompatible with the stale uInitrd.
2  Linux Stuff / Linux distributions / Re: ARP broken after IP address change (squeeze) - Solved on: April 27, 2011, 12:26:27 PM
Turns out that the problem was not limited to ARP.  The root problem was that all incoming packets were being dropped.

I learned how to rebuild a compatible kernel for this distribution (thanks pingtoo and cbxbiker61) and instrumented the ethernet driver so I could see what was causing the dropped packets.  The Receive Descriptor Command/Status register indicated a CRC Error on every receive packet.  I had earlier decided that the hub could not be bad because other devices connected to it work perfectly.  Here are the results of different connection setups (the PC connection in all these tests is via a Trendnet TU-ET100C USB to Ethernet Adapter):

1. Netgear DS104 hub - CRC error on every RX packet (tried two different ones).
2. Netgear EN104TP hub - CRC error on every RX packet.
3. Watchguard SOHO WG2500 - CRC error on every packet.
4. Crossover cable - No errors.
5. Netgear DS108 hub - No errors.
6. Kingston EtheRx Pro Series 24-port 10/100 dual speed hub - No errors.
7. Cisco BEFSR41 - No errors.
8. Netgear GS105 - No errors.

Alternate configuration that also worked:  Trendnet to DS104, DS104 to GS105, GS105 to plug.

Summary: Plug MAC doesn't seem to like some older network gear.
3  Linux Stuff / Linux distributions / Re: How can I install Debian or Ubuntu on USB Drive? on: April 19, 2011, 06:42:34 AM
http://www.cyrius.com/debian/kirkwood/sheevaplug/

I've used the procedure documented above on my two plugs where the target of the install was an SD card.  This procedure talks about support for USB installs but I have not done it myself.  I don't know how different the Guruplug is from my older ones but I see there is a section in the above link discussing which devices are supported.

4  Linux Stuff / Kernel / Problems cross-building 2.6.38.3 on: April 16, 2011, 03:03:26 PM
I have two SheevaPlugs.  I recently used Martin Michelmayr's procedure to upgrade them to Debian Squeeze.  ARP worked on the original network but both absolutely refuse to ARP when simply moved to another network (see separate thread if you're interested).  Since no solution has emerged from my experiments or responses to my original post, I decided to try to cross build the kernel, get it running, and then put kprintf's in the ARP code to try to debug the problem.  I used the instructions from here (may be slightly stale but they're the best I could find) to build the latest stable kernel: http://computingplugs.com/index.php/Building_a_custom_kernel#Getting_U-Boot.27s_mkimage

I cross built the kernel with the CodeSourcery tool chain and then copied uImage and lib/modules to the plug's SD card.  Here is the interesting output from the not-so-excellent results.  Any suggestions?  Note: I can switch the SD card to one that I didn't copy the newly build components to and then the plug boots fine.  This fact should resolve any suspicions about my u-boot boot parameters.

Root-NFS: no NFS server address
VFS: Unable to mount root fs via NFS, trying floppy.
VFS: Cannot open root device "(null)" or unknown-block(2,0)
Please append a correct "root=" boot option; here are the available partitions:
1f00            1024 mtdblock0  (driver?)
1f01            4096 mtdblock1  (driver?)
1f02          519168 mtdblock2  (driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)
[<c002b5e4>] (unwind_backtrace+0x0/0xe0) from [<c034245c>] (panic+0x68/0x18c)
[<c034245c>] (panic+0x68/0x18c) from [<c0008ec0>] (mount_block_root+0x1bc/0x1fc)
[<c0008ec0>] (mount_block_root+0x1bc/0x1fc) from [<c0008fa0>] (mount_root+0xa0/0xc0)
[<c0008fa0>] (mount_root+0xa0/0xc0) from [<c00090e0>] (prepare_namespace+0x120/0x174)
[<c00090e0>] (prepare_namespace+0x120/0x174) from [<c0008b18>] (kernel_init+0x108/0x148)
[<c0008b18>] (kernel_init+0x108/0x148) from [<c0027550>] (kernel_thread_exit+0x0/0x8)
5  Linux Stuff / Linux distributions / Re: ARP broken after IP address change (squeeze) on: April 04, 2011, 02:21:10 PM
There are no firewall rules so I think the firewall is turned off.

root@sheeva1:/etc/init.d# /sbin/iptables -L
[339996.462728] ip_tables: (C) 2000-2006 Netfilter Core Team
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination 
6  Linux Stuff / Linux distributions / Re: ARP broken after IP address change (squeeze) on: April 02, 2011, 02:59:44 PM
I modified it as well.  No joy.  Good catch though, birdman.  I didn't think of that one at first and found it by grepping for the IP address string.
7  Linux Stuff / Linux distributions / ARP broken after IP address change (squeeze) on: March 31, 2011, 11:04:07 AM
Followed these instructions for putting Debian Squeeze on my plug: http://www.cyrius.com/debian/kirkwood/sheevaplug/install.html

Works great.  Configured networking for one that has access to the internet for the installation.  Tested ARP, PING, and tftp functionality after the install completed.  Everything worked.

Modified /etc/network/interfaces and /etc/networks to point to the deployment private network.  Now the plug won't respond to ARP and appears to discard responses to its own ARP requests.  Verified with Wireshark that the ARP packets are valid.
8  Hardware and U-Boot firmware / U-Boot stuff / Whither 3.4.25? on: December 22, 2009, 07:44:49 AM
3.4.25 was advertised to be in QA on 11/22/09.  Any news on its progress?  A blessed binary and some source would be an excellent holiday gesture.
9  Hardware and U-Boot firmware / U-Boot stuff / Re: Network Issues after U-Boot Update 3.4.24 Downgrade 3.4.19 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.
10  Hardware and U-Boot firmware / U-Boot stuff / Re: Network Issues after U-Boot Update 3.4.24 Downgrade 3.4.19 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
11  Hardware and U-Boot firmware / U-Boot stuff / Re: Network Issues after U-Boot Update 3.4.24 Downgrade 3.4.19 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.
12  Hardware and U-Boot firmware / U-Boot stuff / Re: Network Issues after U-Boot Update 3.4.24 Downgrade 3.4.19 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
13  Hardware and U-Boot firmware / U-Boot stuff / Re: Network Issues after U-Boot Update 3.4.24 Downgrade 3.4.19 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.
14  Hardware and U-Boot firmware / U-Boot stuff / Re: Network Issues after U-Boot Update 3.4.24 Downgrade 3.4.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?
15  Hardware and U-Boot firmware / U-Boot stuff / Re: Network Issues after U-Boot Update 3.4.24 Downgrade 3.4.19 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.
Pages: [1] 2 3 ... 5