I goofed up and assigned the target and host the same ip. It works now. Thanks for the help. GKP ---------------------------------------------------------------------- Greg Prier Previously: A Mudder 3564 Boelter Hall Currently: A Bruin working UCLA CA 90095 towards a PhD (310) 825-8899 After that: No idea "Hell, there are no rules here. We're trying to accomplish something." Thomas Edison On Mon, 22 Apr 2002, Istvan Matyasovszki wrote:

Hi, Configure your eth0 interface on the BV board as 192.168.0.2 or some other IP from the same class but not 192.168.0.4 which is already allocated to eth1 on the PC. Then try this on the BV board:

root# route add default gw 192.168.0.4

hope this helps, -istvan

GP> Thank you all for the help. I didn't understand how all of this fit together GP> and was taking a completely incorrect approach.

GP> I was able to get the board to boot just fine with your suggestions. The PCI GP> network drivers seemed to install successfully. I am able to ping from the GP> target from the host but I can't ping the host from the target. The network GP> interfaces are set up as follows:

GP> Host:

6 >> ifconfig -a GP> eth0 Link encap:Ethernet HWaddr 00:06:5B:2F:24:44 GP> inet addr:131.179.187.20 Bcast:131.179.187.255 Mask:255.255.255.0 GP> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 GP> RX packets:5239573 errors:0 dropped:0 overruns:161 frame:0 GP> TX packets:1347440 errors:0 dropped:0 overruns:0 carrier:837 GP> collisions:2858 txqueuelen:100 GP> Interrupt:11 Base address:0xe880

GP> eth1 Link encap:Ethernet HWaddr AA:00:00:00:00:00 GP> inet addr:192.168.0.4 Bcast:192.168.0.255 Mask:255.255.255.0 GP> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 GP> RX packets:30 errors:0 dropped:0 overruns:0 frame:0 GP> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 GP> collisions:0 txqueuelen:100

GP> lo Link encap:Local Loopback GP> inet addr:127.0.0.1 Mask:255.0.0.0 GP> UP LOOPBACK RUNNING MTU:16436 Metric:1 GP> RX packets:46895 errors:0 dropped:0 overruns:0 frame:0 GP> TX packets:46895 errors:0 dropped:0 overruns:0 carrier:0 GP> collisions:0 txqueuelen:0

GP> -note: I removed the vmware interfaces-

GP> and for the target:

GP> [root@Linux /]$ifconfig -a GP> eth0 Link encap:Ethernet HWaddr AA:00:00:00:00:01 GP> inet addr:192.168.0.4 Bcast:192.168.0.255 Mask:255.255.255.0 GP> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 GP> RX packets:0 errors:0 dropped:0 overruns:0 frame:0 GP> TX packets:30 errors:0 dropped:0 overruns:0 carrier:0 GP> collisions:0 txqueuelen:100

GP> lo Link encap:Local Loopback GP> inet addr:127.0.0.1 Mask:255.0.0.0 GP> UP LOOPBACK RUNNING MTU:3924 Metric:1 GP> RX packets:24 errors:0 dropped:0 overruns:0 frame:0 GP> TX packets:24 errors:0 dropped:0 overruns:0 carrier:0 GP> collisions:0 txqueuelen:0

GP> Routing is setup as follows:

GP> Host:

7 >> route -n GP> Kernel IP routing table GP> Destination Gateway Genmask Flags Metric Ref Use Iface GP> 131.179.187.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 GP> 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 GP> 172.16.230.0 0.0.0.0 255.255.255.0 U 0 0 0 vmnet8 GP> 192.168.139.0 0.0.0.0 255.255.255.0 U 0 0 0 vmnet1 GP> 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo GP> 0.0.0.0 131.179.187.1 0.0.0.0 UG 0 0 0 eth0

GP> Target:

GP> [root@Linux /]$route -n GP> Kernel IP routing table GP> Destination Gateway Genmask Flags Metric Ref Use Iface GP> 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 GP> 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 eth0

GP> Any suggestions what could the be problem?

GP> Also, I wanted to clarify exactly how this system works. The host now has an GP> ethernet interface called eth1 that is really a link into the pci bus. This GP> interface talks to the target's interface (eth0) through the pci bus. These GP> packets never leave the network.

GP> Why did intel and Radisys decide to have this communication occur over ethernet GP> interfaces? Is this to make communication between the host and target easier?

GP> I assumed that ifconfig on the target would also show interfaces for each of the GP> four RJ-45 jacks that are on the card . Since they didn't show up I assume that GP> I access these through the strong arm? Do these ports get interfaces in linux?

GP> Thanks for the help.

GP> GKP

GP> ---------------------------------------------------------------------- GP> Greg Prier Previously: A Mudder GP> 3564 Boelter Hall Currently: A Bruin working GP> UCLA CA 90095 towards a PhD GP> (310) 825-8899 After that: No idea

GP> "Hell, there are no rules here. We're trying to accomplish something." GP> Thomas Edison

GP> On Wed, 17 Apr 2002, Brandewie, Dirk J wrote:

...

...

The ENP2505 does not have an on board 82559, the tftp option requires an ethernet card to be installed in the PMC site.

The firmware on the board you have is setup to boot the board by downloading the kernel and ramdisk over the PCI interface. There is a bug in the cygmon on the board that keeps the ethernet interface from working. This is my bug :-( but you are the first person of all the boards we have donated who has wanted to use tftp for download. You should have gotten a CD with the linux drivers needed to boot the board in a Linux host.

--Dirk

...

-----Original Message----- From: Gregory Prier [mailto:greg@lever.cs.ucla.edu] Sent: Tuesday, April 16, 2002 3:06 PM To: ixp1200@CS.Princeton.EDU Subject: [ixp1200] Booting Intel ixp boards from tftp

Our lab has two intel IXP 1200 evaluation boards. These fit in a standard PC (they have pci slots) and have serial access like an evaluation board. The boards are made by RadiSys and have the part number ENP2505. I have been trying for a few weeks to get them to boot linux via tftp and I haven't had any luck.

When the board starts it immediately boots into Cygmon. When HOST mode is enabled Cygmon then counts down and starts automatically booting linux. At this point I get this error message:

Failed to initialize TFTP transfer, check network connection and IP addr.

When I am in FTP mode I immediately get this message:

Press space bar to abort host download mode.... Press space bar to abort host download mode....

If I don't push space then this will continue forever.

The bootoptions are set as follows:

cygmon> bo [BootOptions]: 1 BOOTP/Manual (manual) 2 Local IP (131.179.187.21) 3 Remote IP (131.179.187.20) 4 Linux kernel file name (zImage) 5 Linux ramdisk file name (ramdisk_img.gz) 6 Linux kernel load offset (C4008000) 7 Linux boot command line string () 8 Countdown to auto-boot linux (60) 9 Starting SDRAM offset for host PCI access (0 MB) 10 SDRAM window size for host PCI access (256 MB) 11 Linux download mode [1] 0=FTP 1=HOST Enter option number (1 to 11), "q" to quit, "s" to save:

131.179.187.20 is a machine on the same ethernet segment as the ixp card. It is running a tftp server that has been tested and seems to work fine. Furthermore, I can run tcpdump on 131.179.187.20 and the ixp card never tries to get anything from the tftp server. It doesn't send any traffic onto the network, not even arp.

I tried using the System Monitor mode on the board but this just hung when the board tried to boot. I also can't get to the boot manager because Cygmon seems to immediately start up instead. I can't find a way to make sure that the ethernet interfaces are up and that I have configured everything correctly before declaring the ROM bad and reflashing it.

Specifically, my questions are:

- What exactly is the "on-board 82559 (or 82559ER) Ethernet Interface" mentioned in the manuals? Does this refer to all of the 4 RJ-45 jacks on the board or some jack that I don't have or don't see? Since the board supposedly uses this for the tftp transfer I want to make sure that I am plugging the cables into the right jacks on the card. Is there a specific jack that I am supposed to use? I have tried all four and haven't had any luck yet.

- Any idea why I can't get to the boot manager or the system monitor when booting the board? Were these removes to make room for Cygmon?

- Does any one know of a way to hard reboot the card from inside cygmon? It would be a big help for testing.

- Any idea why the board won't boot from the tftp server?

- Has anyone seen better documentation on setting up the boards and what to do when they don't work?

Any suggestions would be greatly appreciated.

Thank you, Greg Prier

---------------------------------------------------------------------- Greg Prier Previously: A Mudder 3564 Boelter Hall Currently: A Bruin working UCLA CA 90095 towards a PhD (310) 825-8899 After that: No idea

"Hell, there are no rules here. We're trying to accomplish something." Thomas Edison