How many byte do you know VxWorks BSP Image size?

[jeff]

my target cpu is ppc850.
i'd like to define boot rom size.
currently, compile result: about 600-700kbyte
i want that less than 512kbyte
do you know this method?

thank you.

[Michael R. Kesti]

jeff wrote:

If you're not currently building a compressed ROM image then you've got
two options. You can begin building a compressed ROM image or you can
remove features so as to remove code. You don't have the option of
simply defining an arbitrary size.

--
========================================================================
Michael Kesti | "And like, one and one don't make
| two, one and one make one."
mke...@gv.net | - The Who, Bargain

[John]

Hello,

1) Take out features that you are not using (you can do this manually,
or check out the auto-scaling feature of Tornado - make a backup of
your project before running this though, just in case it takes out too
much).

2) Make sure that you are using a compressed ROM image

(Probably best to check (2) before spending time on (1) since it is
easier, but with very little effort I was able to get the default
mbx860 image below 500KB uncompressed.)

HTH,

John...

jef...@unicess.com (jeff) wrote in message news:<107f9c39.0211...@posting.google.com>...

[Emmanuel Herbreteau]

Hi,

It depends on the type of bootrom. If you need
to boot your target from an ATA disk, such as
IDE or CompactFlash, you can build your custom
bootrom with the minimum number of modules
(core, ATA driver, DosFs2, etc...).

In this case, you should be able to make it
with only 300 KB uncompressed. With a compressed
image, a 256KB flash should do it as well, but
it use a small amount of RAM (the size of the uncompressed
code) and it's also slower (the code need to be unzip).

A good choice, in my opinion : a 512 KB flash bootrom.

(On our MPC823, it only use 223 KB to boot from ATA and DosFS1)

Regards
Emmanuel.

[Patrick]

Hi Emmanuel,
It seams that you are quite familiar with building bootable vxWorks
images. I'm trying this now for about 3 days with mixed success.
I'm using T2.0.2/VxWorks5.4 and a target "Radisys board with intel
80486 CPU and 32MB ram".

I was successfull in building a/the little demo application using
the makefiles in the config/BSP folder. I get a compressed vxWorks
running the little demo app. This compressed image is then put on
floppy with

mkboot a: vxWorks.app_rom

this is a duplicated target from vxWorks.st_rom without the standalone
feature. Boot the target system and a few seconds later the little
demo is running. Great!

This was all done by using the make files on the command line.
Now I want to do the same thing from the IDE by selecting the build
target vxWorks_romCompressed.
I added the very same little demo app to "usrAppInit.c" and build
the image. I put it on the floppy the same way:

mkboot a: vxWorks_romCompressed

boot the target and after loading the image the screen stays black
and the target system resets itself and does a warm boot. And the
loading starts again.

I tried already to modify (correct?) the location for the data segment
of the final linker stage (linking romInit.o, romStart.o, etc )(which
was the same value 0x8000 as for the text segment) to a value behind
the rom code (now value 0x10000). Same "reset" effect.

Is this target build from the IDE supposed to work correctly?
Do you have any suggestions? I would appreciate it very much.
BTW: My host is a Win2000 system with SP2.

Thanks Patrick

Emmanuel Herbreteau <eherb...@sepro-robotique.com> wrote in message news:<3DD9E8BF...@sepro-robotique.com>...

[Wade Oram]

In message <2450ac08.02112...@posting.google.com>, Patrick
<patrick....@siemens.com> writes

I don't know whether it is still the case with Tornado 2.0.2 but with
Tornado 2 there was a fault with rule for the vxWorks_romCompressed
target. The entry point for the image was set to 'SYS_ENTRY' when it
should have been set to 'ROM_ENTRY'.

I believe this fault occurred in %WIND_BASE%\target\h\make\rules.vxWorks
at line 109 (or thereabouts).

If the fault persists in 2.0.2, this may be your problem.

You should also be aware that the rom_compressed image load into the
RAM_HIGH_ADRS which is perversely in low memory and therefor there is a
limit on the maximum size of the compressed image (it can't extend
beyond the 640k lower memory limit). Your are obviously not encountering
this problem at present but it is one to be aware of - it took me quite
a while to work out what was going on when this one struck me!

HTH
--
Wade Oram

[Patrick]

Hi Wade Oram,
thanks for your help. Unfortunately this is not the cause for my problem.
The location you pointed out is inside the ROM_RESIDENT target. But I tried
the change it in the romCompressed target from originaly ROM_ENTRY (which I
thought should be correct) to SYS_ENTRY. It gave me linker error.
So I'm back to square 1.
I followed another comment to change the inflate-call in romStart.c.
Remove the ROM_DATA macro because it resolved to a negative/wrong source
address.

/* decompress the main image */

/* if (UNCMP_RTN (ROM_DATA(binArrayStart),
UNCACHED(RAM_DST_ADRS),
&binArrayEnd - binArrayStart) != OK)
*/
if (UNCMP_RTN ((UINT *)binArrayStart,
UNCACHED(RAM_DST_ADRS),
&binArrayEnd - binArrayStart) != OK)
return;

But still no success.

Any further help available??

Patrick

Wade Oram <ne...@wtoram.co.uk> wrote in message news:<3ZCXdZHX...@wtoram.co.uk>...