Optimizing VxWorks boot time ?
Søren Abildgaard
We are running a project, where we are using a x86 platform
and a vxworks 5.2.
I am fairly new to VxWorks, but my problem is the boottime we
are getting. It takes about 13 seconds from the BIOS POST ends
until VXworks starts to load our application.
The kernel I have built I have left out all components, which we
don´t need.
What parameters do I have left to tweak on? And whats dertermines this
boottime, which seems fairly long for an embedded system?
Yours sincerly
Søren Abildgaard
Terma A/S
Dk Denmark
Martin Dowie
news:3c3acff3$0$5452$edfa...@dspool01.news.tele.dk...
> Hi *.*,
>
> We are running a project, where we are using a x86 platform
> and a vxworks 5.2.
>
> I am fairly new to VxWorks, but my problem is the boottime we
> are getting. It takes about 13 seconds from the BIOS POST ends
> until VXworks starts to load our application.
> The kernel I have built I have left out all components, which we
> don´t need.
>
> What parameters do I have left to tweak on? And whats dertermines this
> boottime, which seems fairly long for an embedded system?
How much memory have you told VxWorks you have and how does that
compare with how much you actually use? We have found that reducing
the amount you tell VxWorks you have can make a considerable
difference to the time.
Graham Baxter
My BSP is PowerPC but this could apply to X86 too.
VxWorks copies the ROM image into RAM and then fills the RAM before and
after the image with zeros (bootInit.c).
When there is a lot of RAM this filling can take a long time.
Regards,
Graham Baxter (VxWorks and pSOS BSP'S)
Freelance Software Engineer - AVAILABLE FOR NEW ASSIGNMENT SOON
gba...@NOSPAM.bcs.org.uk
Søren Abildgaard
reported to VxWorks. I could proberly reduce this to
half the size. I will test out asap. Any other hints of how to
attack the boot time problem??
"Martin Dowie" <martin...@nospam.baesystems.com> wrote in message
news:3c3aebda$1...@pull.gecm.com...
Frank Wolf
We've modified the routines
LOCAL void copyLongs (source, destination, nlongs);
LOCAL void fillLongs (buf, nlongs, val);
to use the DMA controller instead of CPU to perform this task.
This helped us to get far lower startup times.
Frank
"Søren Abildgaard" <soren_ab...@hotmail.com> wrote in message
news:3c3c2d00$0$89102$edfa...@dspool01.news.tele.dk...
Martin Dowie
> We have 32 MB of RAM on-board and all is currently
> reported to VxWorks. I could proberly reduce this to
> half the size. I will test out asap. Any other hints of how to
> attack the boot time problem??
Hmmm, avoid initialising devices you don't need. I've heard
stories (though never seen this myself) that some Ethernet
chips can take up to (maybe more than?!) 1 second to initialise.
If you can still meet any (speed) performance requirements, you
could trying running from EEPROM (saves the loading of the SDRAM
and the uncompressing, assuming your image is compressed to
start with).
Søren Abildgaard
DMA controller ?
Regards,
Søren
"Frank Wolf" <fw...@gum.de> wrote in message news:0jch1a...@gum.de...
Martin Dowie
> I am question mark here. How should I use the
> DMA controller ?
As it may do this in the "background", freeing up your CPU to
be getting on with other tasks in parallel. It may even be
faster at doing it also.
Michael R. Kesti
>We are running a project, where we are using a x86 platform
>and a vxworks 5.2.
>
>I am fairly new to VxWorks, but my problem is the boottime we
>are getting. It takes about 13 seconds from the BIOS POST ends
>until VXworks starts to load our application.
>The kernel I have built I have left out all components, which we
>don´t need.
>
>What parameters do I have left to tweak on? And whats dertermines this
>boottime, which seems fairly long for an embedded system?
I'm not certain how this would apply to your environment, but in a
PPC860 project in which I was involed, we GREATLY reduced boot time
by enabling the instruction cache toward the end of romInit.s. The
BSP from which we derived our BSP had deferred cache enabling to the
projects' bootable vxWorks images that are loaded from the host or,
in deployed systems, from ROM.
--
========================================================================
Michael Kesti | "And like, one and one don't make
| two, one and one make one."
mke...@gv.net | - The Who, Bargain
Romano Signorelli
Thanks in advance, bye
Romano Signorelli
"Frank Wolf" <fw...@gum.de> ha scritto nel messaggio
news:0jch1a...@gum.de...
Romano Signorelli
Thanks in advance, bye
Romano Signorelli
P.S.: sorry for multi-post message
"Frank Wolf" <fw...@gum.de> ha scritto nel messaggio
David Laight
>
> "Søren Abildgaard" wrote:
>
> >We are running a project, where we are using a x86 platform
> >and a vxworks 5.2.
> >
> >I am fairly new to VxWorks, but my problem is the boottime we
> >are getting. It takes about 13 seconds from the BIOS POST ends
> >until VXworks starts to load our application.
> >The kernel I have built I have left out all components, which we
> >don´t need.
> >
> >What parameters do I have left to tweak on? And whats dertermines this
> >boottime, which seems fairly long for an embedded system?
>
> I'm not certain how this would apply to your environment, but in a
> PPC860 project in which I was involed, we GREATLY reduced boot time
> by enabling the instruction cache toward the end of romInit.s. The
> BSP from which we derived our BSP had deferred cache enabling to the
> projects' bootable vxWorks images that are loaded from the host or,
> in deployed systems, from ROM.
Things will speed up no end if you enable the I cache and D cache
- especially for the ROM space.
Beware that anything that writes to the EEPROMS needs uncached access,
probably best to map them twice!
You probably need to flush the D cache before you try to execute
anything that is still in it. Ideally this should be done after
the uncompress calls - but you can't (easily) add code there.
The start of usrInit() will probbaly do (all/usrConfig.c and
all/bootConfig.c). This problem may be an ARM one though, I added
code to flush the mini-cache.
David
Tuan Pham
I just wanted some more specifics of using the DMA controller to perform
this task? Is there a built in library?
Thanks in advance.
-Tuan Pham
"Frank Wolf" <fw...@gum.de> wrote in message news:0jch1a...@gum.de...