Hello, LEDs (was RE: Meta Boot Loader)

[Scott C. Karlin]

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 at CS.Princeton.EDU]
> > > > Sent: Wednesday, April 19, 2000 8:27 PM
> > > > To: ixp1200 at 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)?
>