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)?
>
