May 2000 - ixp1200 - lists.cs.princeton.edu

Hello, World (bare, no libs yet)
by Scott C. Karlin 09 May '00

09 May '00

Just an update to my previous post about building StrongARM tools under linux... As it turns out the "mysterious" file format the vxWorks boot loader expects is simply "coff-arm-little." After rebuilding the tools, I now have a "Hello, World" program which sends characters out the serial port. It does not use any library calls (e.g., printf). I am now in the process of getting the standard runtime libraries working. This way, I can use printf(). I'll let everyone know when this is working. In the meantime, in case anyone is interested, here's what I did to get it working: 1. Build the tools for arm-unknown-coff. I followed the steps in the CrossGCC FAQ online at http://www.objsw.com/CrossGCC/ and used GCC 2.95.2, binutils 2.9.1, and newlib 1.8.2. Before building the tools, I edited newlib-1.8.2/newlib/configure.host by commenting out both ARM_RDP_MONITOR and ARM_RDI_MONITOR. 2. Here is the program: *************************************************************************/ /* ** UART Definitions */ #define UART_SR 0x90003400 /* UART Status Register Address */ #define TXF 0x00000080 /* Transmit FIFO full bit */ #define RXR 0x00000010 /* Receive FIFO ready (not empty) */ #define UART_CR 0x90003800 /* UART Control Register Address */ #define XIE 0x00000100 /* Transmit interrupt enable bit */ #define RIE 0x00000010 /* Receive interrupt enable bit */ #define UART_DR 0x90003C00 /* UART Data Register Address */ /* ** Forward References */ static void noUartInts(void); static void putchar(int c); static void puts(char *s); static int getchar(void); /* ** Entry Point */ void __main(void) { int c; noUartInts(); puts("Hello, World!\n\r"); puts("\n\r"); puts("Enter characters to be echoed:\n\r"); while(1) { c = getchar(); if(c == '\r') { puts("\n\r"); } else { putchar(c); } } } /* ** Disable UART transmit/receive interrupts */ static void noUartInts(void) { volatile unsigned long *ptrCR; ptrCR = (volatile unsigned long *) UART_CR; *ptrCR &= ~(XIE | RIE); } /* ** Send a single character */ static void putchar(int c) { volatile unsigned long *ptrSR; volatile unsigned long *ptrDR; ptrSR = (volatile unsigned long *) UART_SR; while((*ptrSR & TXF) != 0) ; ptrDR = (volatile unsigned long *) UART_DR; *ptrDR = (unsigned long) c; } /* ** Send a null terminated string */ static void puts(char *s) { int c; while((c = *s++) != '\0') { putchar(c); } } /* ** Get a character */ static int getchar(void) { volatile unsigned long *ptrSR; volatile unsigned long *ptrDR; ptrSR = (volatile unsigned long *) UART_SR; while((*ptrSR & RXR) == 0) ; ptrDR = (volatile unsigned long *) UART_DR; return (int) *ptrDR; } /*************************************************************************/ 3. Here are the commands I used to compile the code: arm-unknown-coff-gcc -I. -nostartfiles -nodefaultlibs \ -fno-builtin -mcpu=strongarm110 -mapcs-32 -mno-sched-prolog \ -fvolatile -Wall -Wstrict-prototypes -O2 -c hw.c -o hw.o arm-unknown-coff-ld -o hw.coff hw.o -X -N -e ___main \ -Ttext 00001000 -Scott

1 0

re: IXP1200 Board as a Peripheral
by Perry Wagle 08 May '00

08 May '00

We are porting linux, with our mods, to the IXP1200. We just got our IXP1200's last week. I have one configured to vxworks, and the other to angel. With help from Dirk Brandewie at Intel, we successfully did a LED helloworld with angel and angelboot (ftp://ftp.netwinder.org/users/n/nico/). My current task is hacking the bios at (ftp://ftp.arm.linux.org.uk/pub/linux/arm/source/boot/) to download via angel over serial-line to the card to then boot off the network ala vxworks. I'm hoping this approach will dovetail to recreating and extending the stuff described below. We've already got linux running on a SA110 (ebsa285 board). Its a PCI slave running on a Pentium Linux box. Using the patches at (ftp://nt4.el.utwente.nl/pub/co285/), I was able to get Linux kernel 2.3.24 (but not 2.2.12) to boot over the PCI bus. To get this to go, the ROM on the ebsa285 board needed to be reprogrammed, and the kernels patched with the PCI mods that both permit the ebsa285 board to be initialized and a kernel loaded over the PCI bus, and to provide >>>IP-over-PCI<<<, which is then used to mount the root filesystem via NFS. Since this is a clean implementation of IP, it also permits the host kernel to route packets outwards to other systems. I'm rather taken with this IP-over-PCI, but it doesn't look like that code is being maintained (last time stamp is June 1999), but I haven't gotten around yet to querying the mailing lists to find out what the deal is. Having the root file system be accessible and modifiable by other systems aids debugging: watch those timestamps change during boot to see how far the boot sequence got; or watch the pci network traffic via tcpdump. You also get to build stuff on your cross-development platform, and write directly to the filesystem image. I'm wondering how bad I want to maintain this stuff myself. -- Perry Wagle (wagle(a)cse.ogi.edu)

1 0

IXP1200 Board as a Peripheral
by Scott C. Karlin 08 May '00

08 May '00

At some point soon, we would like to move the IXP1200 board from the passive PCI backplane to a traditional Pentium motherboard. I am starting this thread so that we can get a feel for the issues involved. It seems that there are several hurdles we must clear before doing this: 1. The PCI arbiter function must be disabled on the board. * Supported by J13 (CFN1) 2. The PCI reset function must be disabled on the board. * Supported by J14 (CFN0) 3. The board must be configured so that generates interrupts rather than receives them. * (Partially?) Supported by J10, J11, J17, and J9. 4. There must be a way to get the application code into the board. * One way would be to have the board boot up in a passive mode (selected by an unused combination of the GPIO[3:0] jumper settings) where the StrongARM waits for code to be written from the PCI bus by the host. On some signal from the host, the boot code would jump to a well-known address to run the downloaded code. Is this list complete? I know the engineers at Intel have been thinking about the problem because they wanted to do exactly this for the sessions at the Intel Developer Forum in Palm Springs. Thoughts? Ideas? Comments? -Scott

1 0

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