Making Bootable Application In VXWorks

Making Bootable Application In VXWorks

Post by PaulGr.. » Wed, 04 Oct 2000 04:00:00



Forgive me if this is a FAQ but I am trying to link my application to
vxworks such that the application will run on bootup.

I have included my startup code in usrConfig.c by defining the macro
USER_APPL_INIT and have defined INCLUDE_USER_APPL. This code compiles
correctly when I rebuild VXWorks. The startup code consists of a call
to taskSpawn to start my own start up code in a routine called
startTask.
My application is compiled and linked to an object module which I have
linked using the method described in WindRiver's Vxworks course notes,
i.e. in the target makefile I have added it to the MACH_EXTRA
definition.

The problem is that the link fails in the following manner.

ldppc -X -N -e _sysInit -Ttext 00100000  \
    -o vxWorks dataSegPad.o vxWorks.tmp ctdt.o
vxWorks.tmp: In function `usrRoot':
vxWorks.tmp(.text+0x45d6e): undefined reference to `startTask'
vxWorks.tmp(.text+0x45d72): undefined reference to `startTask'
make.exe: *** [vxWorks] Error 0x1

I also tried removing the MACH_EXTRA declaration and instead placing my
module in the 'Added Modules' section on the BSP configuration dialog.
This gives the same result.

My feeling is that there is a cyclic dependancy here, my object file
links to Vxworks modules (it can't avoid that) and now we are telling
Vxworks to link to my object file. I cannot see a way to avoid this
situation so how does one get around this problem?

I am running Tornado 1.0 on Windows NT4, the target system is a Force
ppc603 module.

Thanks

Paul Gruet

Sent via Deja.com http://www.deja.com/
Before you buy.

 
 
 

Making Bootable Application In VXWorks

Post by Edsel Harrel » Wed, 04 Oct 2000 04:00:00


Your approach is the same as ones I've used successfully in the past...

Any chance of a spelling or case error in the name of compiled module?

Look at the earlier part of the makefile output where
vxworks is linked... You should see your module being explicitly
listed...  The MACH_EXTRA and ADDED_MODULES
are used by the "make" build rules and their substituted values
should appear explicitly in the makefile output.

I believe (but I'm too lazy to go check)
USER_APPL_INIT is compiled as part of usrRoot task
in usrConfig module... anyway... it appears to be getting
referenced in the kernel, but not loaded/linked


> Forgive me if this is a FAQ but I am trying to link my application to
> vxworks such that the application will run on bootup.

> I have included my startup code in usrConfig.c by defining the macro
> USER_APPL_INIT and have defined INCLUDE_USER_APPL. This code compiles
> correctly when I rebuild VXWorks. The startup code consists of a call
> to taskSpawn to start my own start up code in a routine called
> startTask.
> My application is compiled and linked to an object module which I have
> linked using the method described in WindRiver's Vxworks course notes,
> i.e. in the target makefile I have added it to the MACH_EXTRA
> definition.

> The problem is that the link fails in the following manner.

> ldppc -X -N -e _sysInit -Ttext 00100000  \
>     -o vxWorks dataSegPad.o vxWorks.tmp ctdt.o
> vxWorks.tmp: In function `usrRoot':
> vxWorks.tmp(.text+0x45d6e): undefined reference to `startTask'
> vxWorks.tmp(.text+0x45d72): undefined reference to `startTask'
> make.exe: *** [vxWorks] Error 0x1

> I also tried removing the MACH_EXTRA declaration and instead placing my
> module in the 'Added Modules' section on the BSP configuration dialog.
> This gives the same result.

> My feeling is that there is a cyclic dependancy here, my object file
> links to Vxworks modules (it can't avoid that) and now we are telling
> Vxworks to link to my object file. I cannot see a way to avoid this
> situation so how does one get around this problem?

> I am running Tornado 1.0 on Windows NT4, the target system is a Force
> ppc603 module.

> Thanks

> Paul Gruet

> Sent via Deja.com http://www.deja.com/
> Before you buy.

--
Edsel A. Harrell, Jr              (voice) (972) 575-6468   (email)

Sr Principal Systems Eng/honors   (pager) (972) 558-4204 (numeric numbers
only)
Raytheon Systems Company          (snail) 6600 Chase Oaks Blvd, MS 8454,
Plano, Tx 75023
------------------------------------------------------------------------------------

"Proofread Carefully to See if You Any Words Out"

DISCLAIMER: I speak only for myself, not my employer.
   EXCEPTION: If any of my ideas are worth more than $0.02, then they are
              property of my employer.

  eah.vcf
< 1K Download

 
 
 

Making Bootable Application In VXWorks

Post by Patric » Thu, 05 Oct 2000 09:23:00


Any chance your startTask is a C++ routine?. If that is the case you need to
declare it extern "C".

Patrick


> Forgive me if this is a FAQ but I am trying to link my application to
> vxworks such that the application will run on bootup.

> I have included my startup code in usrConfig.c by defining the macro
> USER_APPL_INIT and have defined INCLUDE_USER_APPL. This code compiles
> correctly when I rebuild VXWorks. The startup code consists of a call
> to taskSpawn to start my own start up code in a routine called
> startTask.
> My application is compiled and linked to an object module which I have
> linked using the method described in WindRiver's Vxworks course notes,
> i.e. in the target makefile I have added it to the MACH_EXTRA
> definition.

> The problem is that the link fails in the following manner.

> ldppc -X -N -e _sysInit -Ttext 00100000  \
>     -o vxWorks dataSegPad.o vxWorks.tmp ctdt.o
> vxWorks.tmp: In function `usrRoot':
> vxWorks.tmp(.text+0x45d6e): undefined reference to `startTask'
> vxWorks.tmp(.text+0x45d72): undefined reference to `startTask'
> make.exe: *** [vxWorks] Error 0x1

> I also tried removing the MACH_EXTRA declaration and instead placing my
> module in the 'Added Modules' section on the BSP configuration dialog.
> This gives the same result.

> My feeling is that there is a cyclic dependancy here, my object file
> links to Vxworks modules (it can't avoid that) and now we are telling
> Vxworks to link to my object file. I cannot see a way to avoid this
> situation so how does one get around this problem?

> I am running Tornado 1.0 on Windows NT4, the target system is a Force
> ppc603 module.

> Thanks

> Paul Gruet

> Sent via Deja.com http://www.deja.com/
> Before you buy.

 
 
 

Making Bootable Application In VXWorks

Post by pgr.. » Thu, 05 Oct 2000 04:00:00


Thank you Patrick
I have now found the problem and yes you are correct, startTask is
exported as a c++ mangled name hence the link failure. Thank you for
your help

Paul



> Any chance your startTask is a C++ routine?. If that is the case you
need to
> declare it extern "C".

> Patrick



> > Forgive me if this is a FAQ but I am trying to link my application
to
> > vxworks such that the application will run on bootup.

> > I have included my startup code in usrConfig.c by defining the macro
> > USER_APPL_INIT and have defined INCLUDE_USER_APPL. This code
compiles
> > correctly when I rebuild VXWorks. The startup code consists of a
call
> > to taskSpawn to start my own start up code in a routine called
> > startTask.
> > My application is compiled and linked to an object module which I
have
> > linked using the method described in WindRiver's Vxworks course
notes,
> > i.e. in the target makefile I have added it to the MACH_EXTRA
> > definition.

> > The problem is that the link fails in the following manner.

> > ldppc -X -N -e _sysInit -Ttext 00100000  \
> >     -o vxWorks dataSegPad.o vxWorks.tmp ctdt.o
> > vxWorks.tmp: In function `usrRoot':
> > vxWorks.tmp(.text+0x45d6e): undefined reference to `startTask'
> > vxWorks.tmp(.text+0x45d72): undefined reference to `startTask'
> > make.exe: *** [vxWorks] Error 0x1

> > I also tried removing the MACH_EXTRA declaration and instead
placing my
> > module in the 'Added Modules' section on the BSP configuration
dialog.
> > This gives the same result.

> > My feeling is that there is a cyclic dependancy here, my object file
> > links to Vxworks modules (it can't avoid that) and now we are
telling
> > Vxworks to link to my object file. I cannot see a way to avoid this
> > situation so how does one get around this problem?

> > I am running Tornado 1.0 on Windows NT4, the target system is a
Force
> > ppc603 module.

> > Thanks

> > Paul Gruet

> > Sent via Deja.com http://www.deja.com/
> > Before you buy.

Sent via Deja.com http://www.deja.com/
Before you buy.
 
 
 

1. Bootable VxWorks application

--MimeMultipartBoundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Anyone who can help,

I am tying to make a bootable application by using your
taskSpawn command.  The problem is, I don't wish to build it
into the vxworks image due to its large size.  Is it possible
to spawn a task that is outside the vxworks image, even though
it is being loaded PRIOR to the taskSpawn call as follows in
usrRoot():

usrRoot()
{
        .
        .
        .

#ifdef INCLUDE_USER_APPL
    /* Startup the user's application */

    USER_APPL_INIT;     /* must be a valid C statement or block */
#endif

    /* Load module containing hostinit()
     */
    env_id = loadModule(fd_env, LOAD_ALL_SYMBOLS);

    taskSpawn ("HostInit", 100, 0, 20000, (FUNCPTR)
hostinit,                                                                                            
0,0,0,0,0,0,0,0,0,0);

I can declare the task as external, so the "C" file builds, but
the link fails with:

ld386 -X -N -e _sysInit -Ttext 00108000  \
    -o vxWorks dataSegPad.o vxWorks.tmp ctdt.o
vxWorks.tmp(.text+0x5a87): undefined reference to `hostinit'

I also tried to add the -r option to the vxworks makefile, but upon
loading the image, I received an error and nothing loaded.

Is there a solution to this problem, or do I have to build an
incredibly large vxworks image with everything linked ahead of
time?

Thanks in advance!

Dan Sunnarborg
Applied Biometrics Inc.
Burnsville, MN
(612) 890-1123

--MimeMultipartBoundary--

2. SPECmark table

3. Making a bootable Openstep CD?

4. Amazing......

5. Problems making a bootable JAZ disk

6. Stupid question (Was: Re: About those WLO1.0)

7. Making a bootable hard drive.

8. Checkini and Java

9. Making multiple bootable partitions on diskonchip

10. making the HD bootable

11. Making HD bootable

12. Making QNX Bootable on 2.5GB Disk

13. Making bootable CD