Binary compression and booting strategy

LZ77, that is, what "gzip" does.

Irrelevant. With modern CPU speeds, decompression is faster than you can read data off the flash.

Yes. [That is, "it depends"...]

-Rob

----- Rob Warnock

That depends. Adopting a single algorithm is a naive approach and makes a lot of assumptions about the target environment (e.g., the resources that it has available to it).

You need to look at your application to decide what sort of compression algorithm will give you the results you desire: degree of compression, resources required to decompress and, potentially, the *cost* of compressing the original binary (since you haven't explicitly declared the environment from which the compressed binary originates).

You also need to decide how tolerant of data errors the compressor should be. I.e. some approaches can corrupt an entire binary if a single compressed byte is altered. You may wish to adopt different compression strategies for the TEXT vs. DATA sections of your binary.

Is there some reason why this is not an acceptable approach? Or, are you looking to try to quantify it a priori?

You can do this any way you want. I.e. you could have the boot loader pull in a second stage loader that includes the decompressor. The boot loader can have enough smarts to verify that this second stage loader is not corrupt. The second stage loader can then have *more* smarts to examine the compressed binary and determine it's integrity before/after decompressing, etc. The uncompressed binary could conceivably contain code to further decompress portions of the application -- either residing *within* the "decompressed binary" or, more typically, as a separate chunk of FLASH (e.g., imagine an application containing lots of ASCII text -- like web page templates -- which the application might want to decompress... perhaps even "on the fly")

Arrange for that code to be executed by the bootstrap loader. (sorry, I don't see the intent of your question)

--don

It's been about 10 years since I compressed executables for an embedded system. At that time 1MB flash came on a PCMCIA card for about $100.

used a custom LZR variant, operating on 16-bit symbols, which works well for 68000 code. At that time there were also LZW patent issues.

It turns out to be insignificant, compared to the time to warm up the rest of the hardware.

Main code was self-decompressing, giving us the option of changing algorithms.

that's the advantage of making it self-extracting.

Being careful about GPLs.

Standard zlib from gzip.org is BSD-style IIRC.

Phil

I'm a little unclear on your question. Are you linking vxworks with your app, compressing it, and storing it into flash and allowing the bootrom to uncompress it into ram before execution, or are you doing another strategy on your own? ie. ae you asking how the bootrom does it or are you looking for alternatives.

Thanks lc Phil Armstr> >Somebody else wrote: