- ixp1200 - lists.cs.princeton.edu

Looking for Newer IXP1200 HRM than 10/1999
by Scott C. Karlin 05 May '00

05 May '00

Has anyone seen or know about a newer version of the IXP1200 Hardware Reference Manual than October, 1999? I'd like to read section 3.7 -- Boot Sequence. In the 10/1999 version the section is TBD. -Scott

1 0

Re: Hello, LEDs (was RE: Meta Boot Loader)
by Scott C. Karlin 02 May '00

02 May '00

Johnson, Erik J writes: > > > /* > > ** The next line is a guess > > */ > > typedef unsigned long UINT32; > > It looks like it is also in types/vxTypesOld.h, and I > bet others. I couldn't find these on the IXP1200 CDROM. Perhaps it comes with VxWorks? > > I'm using the default start address of 0x00008000. > > Just watching the vxWorks link step, I see that they place the > text segment at 0x1000, that is probably the first thing I would > try. You can also type make vxWorks in the BoardSupport\VxWorks\IXP1200EB > directory and watch for other compiler/linker options being passed into > the process of making vxWorks. It looks like they change the entry > point to sysInit, but I can't image the actual name of the entry point > is important. Without VxWorks, I cannot run the makefile to watch the commands. I also cannot find the vxWorks target in the makefiles. It is probably in $(WIND_BASE)/... somewhere. > I also wonder if the boot loader assumes anytype of compression and/or > checksums. I thought there was a checksum in the a.out header (?) and > I don't think the vxWorks image I have is compressed (I can look at its > symbols...) I agree, the first bytes of the vxWorks file from the CDROM are: 00000000: 00 0A 03 00 00 00 00 00 9C 64 09 00 BE 23 00 00 .........d...#.. 00000010: 1C 00 07 A1 0B 01 00 00 18 31 09 00 DC 32 00 00 .........1...2.. 00000020: 08 B1 00 00 00 10 00 00 00 10 00 00 18 41 09 00 .............A.. 00000030: 2E 74 65 78 74 00 00 00 00 10 00 00 00 10 00 00 .text........... 00000040: 18 31 09 00 A8 00 00 00 00 00 00 00 00 00 00 00 .1.............. 00000050: 00 00 00 00 20 00 00 00 2E 64 61 74 61 00 00 00 .... ....data... 00000060: 18 41 09 00 18 41 09 00 DC 32 00 00 C0 31 09 00 .A...A...2...1.. 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 40 00 00 00 ............@... 00000080: 2E 62 73 73 00 00 00 00 F4 73 09 00 F4 73 09 00 .bss.....s...s.. 00000090: 08 B1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000A0: 00 00 00 00 80 00 00 00 00 10 0F E1 3F 10 C1 E3 ............?... 000000B0: D3 10 81 E3 01 F0 29 E1 4C 11 9F E5 02 20 A0 E3 ......).L.... .. 000000C0: 00 20 81 E5 9C 1F A0 E3 01 10 81 E3 80 1F 81 E3 . .............. 000000D0: 10 1F 01 EE 00 10 A0 E3 10 1F 0D EE 11 20 A0 E3 ............. .. 000000E0: 18 11 9F E5 00 20 81 E5 51 EF 0F EE 00 10 A0 E3 ..... ..Q....... 000000F0: 13 1F 0E EE 18 1F 0E EE 9A 1F 07 EE 16 1F 07 EE ................ This is neither a.out nor binary. It also isn't compressed. -Scott

1 1

Re: Hello, LEDs (was RE: Meta Boot Loader)
by Scott C. Karlin 02 May '00

02 May '00

Following up to my own post... I've made a (very) small amount of progress on two fronts: 1. I can manually use the VxWorks loader command line to modify location 0x38508000 and verify that the LED does change. 2. Our ethernet switch was configured in such a way that the system could not see the tftp host. This is fixed and the new loader error message is: Attached TCP/IP interface to eeE0. Attaching network interface lo0... done. Loading... loadLib error: File type with magic number 0x10b is not supported. Error loading file: errno = 0x530008. Early serial debug initialized muxLoad failed! 0x [VxWorks Boot]: Perhaps the new error message will shed more light on the problem. -Scott Scott Karlin writes: > > I've built some arm-aout cross compiler tools for Linux and am > now attempting a "pre- Hello, World" program: a "write something > on the LEDs" program. > > It doesn't work yet so I thought I'd call upon the collective > experience of the mailing list. > > Here's the code: > > /* > ** The next line is a guess > */ > typedef unsigned long UINT32; > > /* > ** From BoardSupport/VxWorks/IXP1200EB/ixp1200eb.h > */ > #define IXP1200_LED_ADDR (0x38400000+0x108000) /* Addr of LED */ > #define IXP1200_REG_WRITE(a,val) (*(volatile UINT32 *)(a) = (val)) > > /* > ** From BoardSupport/VxWorks/IXP1200EB/sysLib.c > */ > #define DEBUG_LED(val) IXP1200_REG_WRITE(IXP1200_LED_ADDR, (val)) > > > void __main(void) > { > DEBUG_LED(3); > > loop: > goto loop; > } > > I compile it with: > arm-aout-gcc -nostartfiles -nodefaultlibs -o led.aout led.c > > An "arm-aout-objdump --disassemble led.aout" of the resulting file > gives this: > > led.aout: file format a.out-arm-little > > Disassembly of section .text: > > 00008000 <___main>: > 8000: e1a0c00d mov ip, sp > 8004: e92dd800 stmdb sp!, {fp, ip, lr, pc} > 8008: e24cb004 sub fp, ip, #4 > 800c: e3a035e1 mov r3, #943718400 > 8010: e2833942 add r3, r3, #1081344 > 8014: e3a02003 mov r2, #3 > 8018: e5832000 str r2, [r3] > > 0000801c <L3>: > 801c: eafffffe b 801c <L3> > 8020: e95ba800 ldmdb fp, {fp, sp, pc}^ > ... > > When I put it in place of the vxWorks boot image and reboot the > system I get this: > [wrong error message removed] > > There are many things which could be wrong. > I'm using little-endian. > I'm using the default start address of 0x00008000. > I'm using an a.out file. > > Any suggestions? Anyone know what error 0x530001 means? > > Thanks, > Scott > > > Johnson, Erik J writes: > > > > > If the boot loader can load our code directly, this is just what we > > > want. I guess we just need to get the details of the initial boot > > > loader. For example, what is the format of the file it pulls over? > > > > a.out, if I remember the code correctly. After pulling it down, it > > will jump to the entry point given in the a.out header. > > > > > Where in memory is the image placed? (i.e., where do we need to > > > link our text, bss, and data sections.) > > > > there should be MACROs and a routine that determines this in > > the BSP (BoardSupport/VxWorks/...../sysLib.c) (sorry I don't > > have the code handy right now, so I might have > > the names wrong). But look for things of the > > nature like sysMemTop() and SYS_MEM???. The memory map > > given in in the HRM might also provide the information. > > > > erik > > > > > > > > -Scott > > > > > > > > > Raghunandan, Makaram writes: > > > > > > > > The VxWorks boot image that is on the Flash ROM of IXP1200 > > > > Evaluation system does exactly what you need. The initial > > > > boot loader comes up initializes the Chip, and, the Ethernet > > > > NIC. After that the full suite of VxWorks is pulled over > > > > from the network. Now, in your case, you can use this > > > > method to load your OS rather than the default file. > > > > > > > > Another alternative is to use the Angel Debug Monitor that is also > > > > loaded on the FlashROM. The ARM SDT (from ARM LTD.) can be used in > > > > conjunction with this to load any program on to the StrongARM core. > > > > > > > > -----Original Message----- > > > > From: Scott C. Karlin [mailto:scott@CS.Princeton.EDU] > > > > Sent: Wednesday, April 19, 2000 8:27 PM > > > > To: ixp1200(a)CS.Princeton.EDU > > > > Subject: Meta Boot Loader > > > > > > > > > > > > We'd like to begin porting our own operating system (Scout) > > > > to the StrongARM core of the IXP1200. To do this we'll > > > > need a way to get code into the device. We have a couple > > > > of thoughts on this and would like to get some feedback > > > > (especially from the Intel folks who are on the list). > > > > We basically need a way to load a raw image into the core > > > > and start running it. We are not using VxWorks or eCOS. > > > > > > > > Approaches: > > > > > > > > 1. Purchase or lease a NetROM device. > > > > 2. Use a device programmer to program the flash EEPROM. > > > > Is the flash in a socket? The chip packaging looks > > > > unfamiliar. > > > > 3. Use a Meta Boot Loader. This is code that runs > > > > under VxWorks. The preprogrammed boot loader in > > > > ROM can load the meta boot loader which will, in > > > > turn, load our OS code. > > > > > > > > Number 3 has the advantage that it is an all software solution. > > > > The problem is that it appears to need a VxWorks executable > > > > (the meta boot loader) but we aren't interested in purchasing > > > > a license for this one little program. Is this something > > > > that someone else has done (or could do)? >

1 0

RE: Hello, LEDs (was RE: Meta Boot Loader)
by Johnson, Erik J 02 May '00

02 May '00

> /* > ** The next line is a guess > */ > typedef unsigned long UINT32; It looks like it is also in types/vxTypesOld.h, and I bet others. > I'm using the default start address of 0x00008000. Just watching the vxWorks link step, I see that they place the text segment at 0x1000, that is probably the first thing I would try. You can also type make vxWorks in the BoardSupport\VxWorks\IXP1200EB directory and watch for other compiler/linker options being passed into the process of making vxWorks. It looks like they change the entry point to sysInit, but I can't image the actual name of the entry point is important. I also wonder if the boot loader assumes anytype of compression and/or checksums. I thought there was a checksum in the a.out header (?) and I don't think the vxWorks image I have is compressed (I can look at its symbols...) erik

1 0

RE: Meta Boot Loader
by Johnson, Erik J 02 May '00

02 May '00

> If the boot loader can load our code directly, this is just what we > want. I guess we just need to get the details of the initial boot > loader. For example, what is the format of the file it pulls over? a.out, if I remember the code correctly. After pulling it down, it will jump to the entry point given in the a.out header. > Where in memory is the image placed? (i.e., where do we need to > link our text, bss, and data sections.) there should be MACROs and a routine that determines this in the BSP (BoardSupport/VxWorks/...../sysLib.c) (sorry I don't have the code handy right now, so I might have the names wrong). But look for things of the nature like sysMemTop() and SYS_MEM???. The memory map given in in the HRM might also provide the information. erik > > -Scott > > > Raghunandan, Makaram writes: > > > > The VxWorks boot image that is on the Flash ROM of IXP1200 > Evaluation > > system does exactly what you need. The initial boot loader comes up > > initializes the Chip, and, the Ethernet NIC. After that the full > > suite of VxWorks is pulled over from the network. Now, in > your case, > > you can use this method to load your OS rather than the > default file. > > > > Another alternative is to use the Angel Debug Monitor that is also > > loaded on the FlashROM. The ARM SDT (from ARM LTD.) can be used in > > conjunction with this to load any program on to the StrongARM core. > > > > -----Original Message----- > > From: Scott C. Karlin [mailto:scott@CS.Princeton.EDU] > > Sent: Wednesday, April 19, 2000 8:27 PM > > To: ixp1200(a)CS.Princeton.EDU > > Subject: Meta Boot Loader > > > > > > We'd like to begin porting our own operating system (Scout) > > to the StrongARM core of the IXP1200. To do this we'll > > need a way to get code into the device. We have a couple > > of thoughts on this and would like to get some feedback > > (especially from the Intel folks who are on the list). > > We basically need a way to load a raw image into the core > > and start running it. We are not using VxWorks or eCOS. > > > > Approaches: > > > > 1. Purchase or lease a NetROM device. > > 2. Use a device programmer to program the flash EEPROM. > > Is the flash in a socket? The chip packaging looks > > unfamiliar. > > 3. Use a Meta Boot Loader. This is code that runs > > under VxWorks. The preprogrammed boot loader in > > ROM can load the meta boot loader which will, in > > turn, load our OS code. > > > > Number 3 has the advantage that it is an all software solution. > > The problem is that it appears to need a VxWorks executable > > (the meta boot loader) but we aren't interested in purchasing > > a license for this one little program. Is this something > > that someone else has done (or could do)? >

2 1

RE: Meta Boot Loader
by Paige, Dale W 20 Apr '00

20 Apr '00

Scott - I agree, I also feel uncomfortable with it. I am not aware of a tool to make it easier, but it may exist. One tool that is highly recommended is a suction cup device to handle the flash parts. I do not recommend this process unless required. I was thinking that your desire to port your own RTOS to the IXP1200EB might be most cost effectively attained if you were to use the Cygnus SA1 tool chain which has recently completed a revamp to put cygmon onto the IXP1200 and use that with GDB as a monitor from which you can port your RTOS. Attainment of this goal would require you to go through the pain of removing and programming the flash parts. Also, as I already recommended, keep the original flash in reserve as a fall back. Best Regards - Dale -----Original Message----- From: Scott C. Karlin [mailto:scott@CS.Princeton.EDU] Sent: Thursday, April 20, 2000 10:28 AM To: dale.w.paige(a)intel.com Cc: ixp1200(a)CS.Princeton.EDU Subject: Re: Meta Boot Loader Thanks, Dale. I was able to "open" the socket. Since it required considerable force, I wouldn't recommend it to anyone unless they really want to get the chip out. Is there a trick or a tool to close the lid when the time comes? It seems like it will require more force than I am comfortable exerting on the board. -Scott Paige, Dale W writes: > > Scott - > > For a low cost solution I think that you should consider 2. If you can load > your own bootloader, or maybe the cygmon monitor for the SA1 then you should > only have to deal with reprogramming the flash a few times. Once you have > some way to boot code you can then use the BSP code as an example of how to > program the flash form your program. When that is successfully integrated > into a bootable option you should not have to open the flash packages. > > To open them you need to be careful. There are some arrows on the top > pointing in the direct that it must be slid (away from the "front" of the > board). Once the tabs protruding from the front have cleared you can gently > lift the lid, it kind or hinges on the protrusions on the "back" side of > the socket. Note the orientation of the flash in the socket. Save the > originals, you can do some stuff just with the vxWorks bootup interface, and > the Angel and diagnostics are totally functional. > > > Happy coding - Dale > > > -----Original Message----- > From: Scott C. Karlin [mailto:scott@CS.Princeton.EDU] > Sent: Wednesday, April 19, 2000 5:27 PM > To: ixp1200(a)CS.Princeton.EDU > Subject: Meta Boot Loader > > > We'd like to begin porting our own operating system (Scout) > to the StrongARM core of the IXP1200. To do this we'll > need a way to get code into the device. We have a couple > of thoughts on this and would like to get some feedback > (especially from the Intel folks who are on the list). > We basically need a way to load a raw image into the core > and start running it. We are not using VxWorks or eCOS. > > Approaches: > > 1. Purchase or lease a NetROM device. > 2. Use a device programmer to program the flash EEPROM. > Is the flash in a socket? The chip packaging looks > unfamiliar. > 3. Use a Meta Boot Loader. This is code that runs > under VxWorks. The preprogrammed boot loader in > ROM can load the meta boot loader which will, in > turn, load our OS code. > > Number 3 has the advantage that it is an all software solution. > The problem is that it appears to need a VxWorks executable > (the meta boot loader) but we aren't interested in purchasing > a license for this one little program. Is this something > that someone else has done (or could do)? > > -Scott

1 0

Re: Meta Boot Loader
by Scott C. Karlin 20 Apr '00

20 Apr '00

Thanks, Dale. I was able to "open" the socket. Since it required considerable force, I wouldn't recommend it to anyone unless they really want to get the chip out. Is there a trick or a tool to close the lid when the time comes? It seems like it will require more force than I am comfortable exerting on the board. -Scott Paige, Dale W writes: > > Scott - > > For a low cost solution I think that you should consider 2. If you can load > your own bootloader, or maybe the cygmon monitor for the SA1 then you should > only have to deal with reprogramming the flash a few times. Once you have > some way to boot code you can then use the BSP code as an example of how to > program the flash form your program. When that is successfully integrated > into a bootable option you should not have to open the flash packages. > > To open them you need to be careful. There are some arrows on the top > pointing in the direct that it must be slid (away from the "front" of the > board). Once the tabs protruding from the front have cleared you can gently > lift the lid, it kind or hinges on the protrusions on the "back" side of > the socket. Note the orientation of the flash in the socket. Save the > originals, you can do some stuff just with the vxWorks bootup interface, and > the Angel and diagnostics are totally functional. > > > Happy coding - Dale > > > -----Original Message----- > From: Scott C. Karlin [mailto:scott@CS.Princeton.EDU] > Sent: Wednesday, April 19, 2000 5:27 PM > To: ixp1200(a)CS.Princeton.EDU > Subject: Meta Boot Loader > > > We'd like to begin porting our own operating system (Scout) > to the StrongARM core of the IXP1200. To do this we'll > need a way to get code into the device. We have a couple > of thoughts on this and would like to get some feedback > (especially from the Intel folks who are on the list). > We basically need a way to load a raw image into the core > and start running it. We are not using VxWorks or eCOS. > > Approaches: > > 1. Purchase or lease a NetROM device. > 2. Use a device programmer to program the flash EEPROM. > Is the flash in a socket? The chip packaging looks > unfamiliar. > 3. Use a Meta Boot Loader. This is code that runs > under VxWorks. The preprogrammed boot loader in > ROM can load the meta boot loader which will, in > turn, load our OS code. > > Number 3 has the advantage that it is an all software solution. > The problem is that it appears to need a VxWorks executable > (the meta boot loader) but we aren't interested in purchasing > a license for this one little program. Is this something > that someone else has done (or could do)? > > -Scott

1 0

IXP1200 Admin
by Scott C. Karlin 20 Apr '00

20 Apr '00

Just a quick reminder that the behavior I chose for the ixp1200 mailing list is that the "Reply-To" field is set to the sender of the message (not the mailing list). If you want your replies to go to the list, be sure to explicitly include in the To or Cc field. This prevents personal replies from accidentally being sent to everyone on the list. The downside, of course, is that replies which continue a discussion thread sometimes don't get sent to everyone. -Scott

1 0

RE: Meta Boot Loader
by Raghunandan, Makaram 20 Apr '00

20 Apr '00

The VxWorks boot image that is on the Flash ROM of IXP1200 Evaluation system does exactly what you need. The initial boot loader comes up initializes the Chip, and, the Ethernet NIC. After that the full suite of VxWorks is pulled over from the network. Now, in your case, you can use this method to load your OS rather than the default file. Another alternative is to use the Angel Debug Monitor that is also loaded on the FalshROM. The ARM SDT (from ARM LTD.) can be used in conjuction with this to load any program on to the StrongARM core. -----Original Message----- From: Scott C. Karlin [mailto:scott@CS.Princeton.EDU] Sent: Wednesday, April 19, 2000 8:27 PM To: ixp1200(a)CS.Princeton.EDU Subject: Meta Boot Loader We'd like to begin porting our own operating system (Scout) to the StrongARM core of the IXP1200. To do this we'll need a way to get code into the device. We have a couple of thoughts on this and would like to get some feedback (especially from the Intel folks who are on the list). We basically need a way to load a raw image into the core and start running it. We are not using VxWorks or eCOS. Approaches: 1. Purchase or lease a NetROM device. 2. Use a device programmer to program the flash EEPROM. Is the flash in a socket? The chip packaging looks unfamiliar. 3. Use a Meta Boot Loader. This is code that runs under VxWorks. The preprogrammed boot loader in ROM can load the meta boot loader which will, in turn, load our OS code. Number 3 has the advantage that it is an all software solution. The problem is that it appears to need a VxWorks executable (the meta boot loader) but we aren't interested in purchasing a license for this one little program. Is this something that someone else has done (or could do)? -Scott -------------------------------------------------------------------------- Scott C. Karlin Princeton University Graduate Student Department of Computer Science Voice: (609) 258-5386 35 Olden Street Email: scott(a)cs.princeton.edu Princeton, NJ 08544-2087 WWW: http://www.cs.princeton.edu/~scott --------------------------------------------------------------------------

2 1

Meta Boot Loader
by Scott C. Karlin 19 Apr '00

19 Apr '00

We'd like to begin porting our own operating system (Scout) to the StrongARM core of the IXP1200. To do this we'll need a way to get code into the device. We have a couple of thoughts on this and would like to get some feedback (especially from the Intel folks who are on the list). We basically need a way to load a raw image into the core and start running it. We are not using VxWorks or eCOS. Approaches: 1. Purchase or lease a NetROM device. 2. Use a device programmer to program the flash EEPROM. Is the flash in a socket? The chip packaging looks unfamiliar. 3. Use a Meta Boot Loader. This is code that runs under VxWorks. The preprogrammed boot loader in ROM can load the meta boot loader which will, in turn, load our OS code. Number 3 has the advantage that it is an all software solution. The problem is that it appears to need a VxWorks executable (the meta boot loader) but we aren't interested in purchasing a license for this one little program. Is this something that someone else has done (or could do)? -Scott -------------------------------------------------------------------------- Scott C. Karlin Princeton University Graduate Student Department of Computer Science Voice: (609) 258-5386 35 Olden Street Email: scott(a)cs.princeton.edu Princeton, NJ 08544-2087 WWW: http://www.cs.princeton.edu/~scott --------------------------------------------------------------------------

1 0

Re: How to Boot the Ethernet Evaluation System?
by Scott C. Karlin 31 Mar '00

31 Mar '00

In case anyone is interested, Tammo and I solved the problem by setting jumpers J28 (GP3) and J27 (GP2) to the "factory settings" as described in the documentation (rather than the settings they were in when they arrived from the factory). -Scott Tammo Spalink writes: > > IXP1200 board and ethernet card are both in the correct PCI slots. > > Using the dc0 device doesn't seem to make any difference at all. > Using the "@" command instead of the "l" command makes no difference > at all either. > > Regarding FTP: I set the boot flags for TFTP, so I believe no > username/password should be needed. Also, we never saw the box > generate a single packet, so I doubt this is it. To be sure, we tried > with real FTP and no luck there either (with a username & passwd). > Yes scout-7 is running a TFTP server. > > Is the boot prompt "n" command really supposed to fail? > > Tammo > > On Mon, 27 Mar 2000, "Johnson, Erik J" <erik.j.johnson(a)intel.com> wrote: > > > > Here is what I know, maybe this will help (some of it just > > repeats what you already know) > > > > dc0 is the correct boot device (at least for the A-steppings of > > the board, which is what I assume you have). Make sure you have > > the given NIC on the correct slot on the backplane provided > > (it should be the farthest from the system slot where the > > IXP1200 is). > > > > just a sanity check: you are running a > > ftp server on scout-7. Also 128.xx.yy are all in the same subnet (or > > else you need to set the gateway value). There should be two other options > > in > > the vxworks boot loader one for username and password (these > > should be for the ftp server and the home directory of this > > user should be where the vxWorks binary is located). I don't > > see those in your print of the boot options, were they perhaps left > > blank? you can use anonymous, just fill that in as the username and > > put the standard x@y password > > > > I assume that if all of the above is okay, then the only other difference is > > that I have never tried to load the image (then jump to the entry > > point) on this board, I simply do it all with the @ command. > > > > I can go and dump out our boot loader settings if needed. Let me > > know > > > > erik > > > > > -----Original Message----- > > > From: Tammo Spalink [mailto:tspalink@CS.Princeton.EDU] > > > Sent: Monday, March 27, 2000 11:43 AM > > > To: ixp1200(a)CS.Princeton.EDU > > > Subject: How to Boot the Ethernet Evaluation System? > > > > > > > > > > > > Following the "Ethernet Evaluation System User's Guide": > > > > > > I am trying to get a VxWorks image to load on the chip, but am having > > > no success. Maybe someone has a suggestion as to what I should expect > > > or am not doing. > > > > > > I have configured the system as follows: > > > > > > > [VxWorks Boot]: p > > > > > > > > boot device : eeE > > > > unit number : 0 > > > > processor number : 0 > > > > host name : scout-7 > > > > file name : vxWorks > > > > inet on ethernet (e) : 128.xx.yy.100 > > > > host inet (h) : 128.xx.yy.27 > > > > flags (f) : 0x80 > > > > target name (tn) : ixp1200 > > > > > > > > > > By which I am intending that it should fetch the "vxWorks" file (the > > > one provided in /boardsuppoort/bin/vb on the CD) from the machine > > > scout-7(128.xx.yy.27) via TFTP. It may use the IP address > > > 128.xx.yy.100. > > > > > > However, trying a load command results in: > > > > > > > [VxWorks Boot]: l > > > > > > > > boot device : eeE > > > > unit number : 0 > > > > processor number : 0 > > > > host name : scout-7 > > > > file name : vxWorks > > > > inet on ethernet (e) : 128.xx.yy.100 > > > > host inet (h) : 128.xx.yy.27 > > > > flags (f) : 0x80 > > > > target name (tn) : ixp1200 > > > > > > > > Early serial debug initialized > > > > muxLoad failed! > > > > muxLoad > > > > > > > > [VxWorks Boot]: > > > > > > Thinking this might be the wrong boot device since the boot help says: > > > > > > > [VxWorks Boot]: ? > > > > > > > > > > ... help stuff omitted ... > > > > > > > n netif - print network interface device address > > > > > > ... help stuff omitted ... > > > > > > > > > > > available boot devices:Enhanced Network Devices > > > > dc0 eeE0 > > > > [VxWorks Boot]: > > > > > > I tried dc0 as well, with the same results. Then I tried the > > > following: > > > > > > > [VxWorks Boot]: n dc0 > > > > Network interface dc unknown. > > > > Cannot initialize interface named "dc0" > > > > [VxWorks Boot]: n eeE0 > > > > Network interface eeE unknown. > > > > Cannot initialize interface named "eeE0" > > > > [VxWorks Boot]: > > > > > > Repeating this process with a packet sniffer on, we did not see > > > anything that looked like it came from the system. I think I am > > > stuck. Any suggestions? > > > > > > Thanks, > > > > > > Tammo > > > > > > > ------- End of Forwarded Message >

1 0

RE: How to Boot the Ethernet Evaluation System?
by Johnson, Erik J 27 Mar '00

27 Mar '00

> Using the dc0 device doesn't seem to make any difference at all. > Using the "@" command instead of the "l" command makes no difference > at all either. Ahh, looking at the Beta4 version of the BSP, I see that they are now shipping two drivers with the OS (and presumably with the boot rom). (Check BoardSupport/VxWorks/IXP1200EB/configNet.h). So if your NIC has digital parts on it, go with dc, if it has intel parts, go with eeV (did you try eeV or eeE? Make sure you try eeV0 and eeE0. eeVconfig.h would seem to indicate that it uses eeE0, but I can't be sure).. I am still in the past with the dc NIC so I cannot attest to how things work with the intel part. hopefully the driver for the intel nic has been compiled into the bootrom. I wonder if anyone else out there can verify this(?) I don't know of a symbol table lookup command from the boot loader (i.e., like lkup() does once you get the full version of vxworks loaded). I tried to do an nm on the vxWorks_rom and vxWorks image in the bin/vb directory and vxWorks turns up hits for both eeVEndLoad and dec21x4xEndLoad (the dc driver). The vxWorks_rom image must be partly stripped because it does not turn up hits for either. > Regarding FTP: I set the boot flags for TFTP, so I believe no > username/password should be needed. Also, we never saw the box > generate a single packet, so I doubt this is it. To be sure, we tried > with real FTP and no luck there either (with a username & passwd). > Yes scout-7 is running a TFTP server. Ahhh, perhaps that explains your flags being set to 0x80. I just checked our settings and our flags are 0, which may explain why we are using ftp rather than tftp (if I read sysLib.h correctly, 0x80 is for tftp). One simple test would be to change the flags to 0, but I doub't this will help. > Is the boot prompt "n" command really supposed to fail? I would assume that it fails because both the dc and eeV are END drivers and the n command (if I read code correctly) is dealing with BSD-style drivers. (I am looking at configNet.h and bootConfig.c. In bootConfig.c I assume bootCmdLoop is producing the prompt you are getting. This calls netifAdrsPrint in response to the 'n' command). Following these calls through, I don't see the code calling muxDevLoad, rather it calls the attach routine in the device structure, which, correct me if I am wrong, is the older BSD-style interface. Anyway, it would not surprise me if it fails because of this (BTW, it fails on our "working" system). You could fix the n command to do the right thing (say call muxShow() instead of netifAdrsPrint), but of course since you can't boot vxworks you can't overwrite the boot rom and you are stuck. sorry for not being any help, I guess the best I can do is point you back to the person who shipped you the system and have them verify the version of your bootrom, and then, maybe replace your NIC. erk

1 0

Re: How to Boot the Ethernet Evaluation System?
by Tammo Spalink 27 Mar '00

27 Mar '00

IXP1200 board and ethernet card are both in the correct PCI slots. Using the dc0 device doesn't seem to make any difference at all. Using the "@" command instead of the "l" command makes no difference at all either. Regarding FTP: I set the boot flags for TFTP, so I believe no username/password should be needed. Also, we never saw the box generate a single packet, so I doubt this is it. To be sure, we tried with real FTP and no luck there either (with a username & passwd). Yes scout-7 is running a TFTP server. Is the boot prompt "n" command really supposed to fail? Tammo On Mon, 27 Mar 2000, "Johnson, Erik J" <erik.j.johnson(a)intel.com> wrote: > > Here is what I know, maybe this will help (some of it just > repeats what you already know) > > dc0 is the correct boot device (at least for the A-steppings of > the board, which is what I assume you have). Make sure you have > the given NIC on the correct slot on the backplane provided > (it should be the farthest from the system slot where the > IXP1200 is). > > just a sanity check: you are running a > ftp server on scout-7. Also 128.xx.yy are all in the same subnet (or > else you need to set the gateway value). There should be two other options > in > the vxworks boot loader one for username and password (these > should be for the ftp server and the home directory of this > user should be where the vxWorks binary is located). I don't > see those in your print of the boot options, were they perhaps left > blank? you can use anonymous, just fill that in as the username and > put the standard x@y password > > I assume that if all of the above is okay, then the only other difference is > that I have never tried to load the image (then jump to the entry > point) on this board, I simply do it all with the @ command. > > I can go and dump out our boot loader settings if needed. Let me > know > > erik > > > -----Original Message----- > > From: Tammo Spalink [mailto:tspalink@CS.Princeton.EDU] > > Sent: Monday, March 27, 2000 11:43 AM > > To: ixp1200(a)CS.Princeton.EDU > > Subject: How to Boot the Ethernet Evaluation System? > > > > > > > > Following the "Ethernet Evaluation System User's Guide": > > > > I am trying to get a VxWorks image to load on the chip, but am having > > no success. Maybe someone has a suggestion as to what I should expect > > or am not doing. > > > > I have configured the system as follows: > > > > > [VxWorks Boot]: p > > > > > > boot device : eeE > > > unit number : 0 > > > processor number : 0 > > > host name : scout-7 > > > file name : vxWorks > > > inet on ethernet (e) : 128.xx.yy.100 > > > host inet (h) : 128.xx.yy.27 > > > flags (f) : 0x80 > > > target name (tn) : ixp1200 > > > > > > > By which I am intending that it should fetch the "vxWorks" file (the > > one provided in /boardsuppoort/bin/vb on the CD) from the machine > > scout-7(128.xx.yy.27) via TFTP. It may use the IP address > > 128.xx.yy.100. > > > > However, trying a load command results in: > > > > > [VxWorks Boot]: l > > > > > > boot device : eeE > > > unit number : 0 > > > processor number : 0 > > > host name : scout-7 > > > file name : vxWorks > > > inet on ethernet (e) : 128.xx.yy.100 > > > host inet (h) : 128.xx.yy.27 > > > flags (f) : 0x80 > > > target name (tn) : ixp1200 > > > > > > Early serial debug initialized > > > muxLoad failed! > > > muxLoad > > > > > > [VxWorks Boot]: > > > > Thinking this might be the wrong boot device since the boot help says: > > > > > [VxWorks Boot]: ? > > > > > > > ... help stuff omitted ... > > > > > n netif - print network interface device address > > > > ... help stuff omitted ... > > > > > > > > available boot devices:Enhanced Network Devices > > > dc0 eeE0 > > > [VxWorks Boot]: > > > > I tried dc0 as well, with the same results. Then I tried the > > following: > > > > > [VxWorks Boot]: n dc0 > > > Network interface dc unknown. > > > Cannot initialize interface named "dc0" > > > [VxWorks Boot]: n eeE0 > > > Network interface eeE unknown. > > > Cannot initialize interface named "eeE0" > > > [VxWorks Boot]: > > > > Repeating this process with a packet sniffer on, we did not see > > anything that looked like it came from the system. I think I am > > stuck. Any suggestions? > > > > Thanks, > > > > Tammo > > > ------- End of Forwarded Message

1 0

None
by owner-ixp1200＠CS.Princeton.EDU 27 Mar '00

27 Mar '00

>From scott(a)CS.Princeton.EDU Mon Mar 27 14:59:06 2000 Message-ID: <86FFC5B42CDCD211AC4900A0C95D19E3D6160D(a)orsmsx52.jf.intel.com> From: "Johnson, Erik J" <erik.j.johnson(a)intel.com> To: ixp1200(a)CS.Princeton.EDU Subject: RE: How to Boot the Ethernet Evaluation System? Date: Mon, 27 Mar 2000 11:57:10 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ixp1200 Reply-To: "Johnson, Erik J" <erik.j.johnson(a)intel.com> Here is what I know, maybe this will help (some of it just repeats what you already know) dc0 is the correct boot device (at least for the A-steppings of the board, which is what I assume you have). Make sure you have the given NIC on the correct slot on the backplane provided (it should be the farthest from the system slot where the IXP1200 is). just a sanity check: you are running a ftp server on scout-7. Also 128.xx.yy are all in the same subnet (or else you need to set the gateway value). There should be two other options in the vxworks boot loader one for username and password (these should be for the ftp server and the home directory of this user should be where the vxWorks binary is located). I don't see those in your print of the boot options, were they perhaps left blank? you can use anonymous, just fill that in as the username and put the standard x@y password I assume that if all of the above is okay, then the only other difference is that I have never tried to load the image (then jump to the entry point) on this board, I simply do it all with the @ command. I can go and dump out our boot loader settings if needed. Let me know erik > -----Original Message----- > From: Tammo Spalink [mailto:tspalink@CS.Princeton.EDU] > Sent: Monday, March 27, 2000 11:43 AM > To: ixp1200(a)CS.Princeton.EDU > Subject: How to Boot the Ethernet Evaluation System? > > > > Following the "Ethernet Evaluation System User's Guide": > > I am trying to get a VxWorks image to load on the chip, but am having > no success. Maybe someone has a suggestion as to what I should expect > or am not doing. > > I have configured the system as follows: > > > [VxWorks Boot]: p > > > > boot device : eeE > > unit number : 0 > > processor number : 0 > > host name : scout-7 > > file name : vxWorks > > inet on ethernet (e) : 128.xx.yy.100 > > host inet (h) : 128.xx.yy.27 > > flags (f) : 0x80 > > target name (tn) : ixp1200 > > > > By which I am intending that it should fetch the "vxWorks" file (the > one provided in /boardsuppoort/bin/vb on the CD) from the machine > scout-7(128.xx.yy.27) via TFTP. It may use the IP address > 128.xx.yy.100. > > However, trying a load command results in: > > > [VxWorks Boot]: l > > > > boot device : eeE > > unit number : 0 > > processor number : 0 > > host name : scout-7 > > file name : vxWorks > > inet on ethernet (e) : 128.xx.yy.100 > > host inet (h) : 128.xx.yy.27 > > flags (f) : 0x80 > > target name (tn) : ixp1200 > > > > Early serial debug initialized > > muxLoad failed! > > muxLoad > > > > [VxWorks Boot]: > > Thinking this might be the wrong boot device since the boot help says: > > > [VxWorks Boot]: ? > > > > ... help stuff omitted ... > > > n netif - print network interface device address > > ... help stuff omitted ... > > > > > available boot devices:Enhanced Network Devices > > dc0 eeE0 > > [VxWorks Boot]: > > I tried dc0 as well, with the same results. Then I tried the > following: > > > [VxWorks Boot]: n dc0 > > Network interface dc unknown. > > Cannot initialize interface named "dc0" > > [VxWorks Boot]: n eeE0 > > Network interface eeE unknown. > > Cannot initialize interface named "eeE0" > > [VxWorks Boot]: > > Repeating this process with a packet sniffer on, we did not see > anything that looked like it came from the system. I think I am > stuck. Any suggestions? > > Thanks, > > Tammo >

1 0

How to Boot the Ethernet Evaluation System?
by Tammo Spalink 27 Mar '00

27 Mar '00

Following the "Ethernet Evaluation System User's Guide": I am trying to get a VxWorks image to load on the chip, but am having no success. Maybe someone has a suggestion as to what I should expect or am not doing. I have configured the system as follows: > [VxWorks Boot]: p > > boot device : eeE > unit number : 0 > processor number : 0 > host name : scout-7 > file name : vxWorks > inet on ethernet (e) : 128.xx.yy.100 > host inet (h) : 128.xx.yy.27 > flags (f) : 0x80 > target name (tn) : ixp1200 > By which I am intending that it should fetch the "vxWorks" file (the one provided in /boardsuppoort/bin/vb on the CD) from the machine scout-7(128.xx.yy.27) via TFTP. It may use the IP address 128.xx.yy.100. However, trying a load command results in: > [VxWorks Boot]: l > > boot device : eeE > unit number : 0 > processor number : 0 > host name : scout-7 > file name : vxWorks > inet on ethernet (e) : 128.xx.yy.100 > host inet (h) : 128.xx.yy.27 > flags (f) : 0x80 > target name (tn) : ixp1200 > > Early serial debug initialized > muxLoad failed! > muxLoad > > [VxWorks Boot]: Thinking this might be the wrong boot device since the boot help says: > [VxWorks Boot]: ? > ... help stuff omitted ... > n netif - print network interface device address ... help stuff omitted ... > > available boot devices:Enhanced Network Devices > dc0 eeE0 > [VxWorks Boot]: I tried dc0 as well, with the same results. Then I tried the following: > [VxWorks Boot]: n dc0 > Network interface dc unknown. > Cannot initialize interface named "dc0" > [VxWorks Boot]: n eeE0 > Network interface eeE unknown. > Cannot initialize interface named "eeE0" > [VxWorks Boot]: Repeating this process with a packet sniffer on, we did not see anything that looked like it came from the system. I think I am stuck. Any suggestions? Thanks, Tammo

1 0

Another Test -- Please Ignore
by Scott C. Karlin 24 Mar '00

24 Mar '00

This is another test message for the ixp1200 list. I am in the process of making sure that the list is properly archiving messages before someone posts a "real" message. -Scott

1 0