RE: [ECOS] CDL parent target+options?

["Liviu Ionescu" <ilg at livius dot net>]

> > well. Again, we feel that typical application developers will work
> > with just one type of startup for most of the development
> cycle - this
> > could be an incorrect assumption, and given sufficient evidence we
> > would rethink the issue.
>
> Maybe im not typical, but i want both a ROM image and a RAM image. We
> have the software infrastructure in place that we can quickly put new
> images into FLASH. I tend to do most of my debugging with apps in
> FLASH. But when my app is too broken to allow software upgrade i have
> to fall back to a RAM version of the code.

we use a different approach, our board has one small boot rom and a larger
programable flash, with a switching device to select the active one (we
patched it to be remotely accesible). the large flash is programable only
when booting from the boot rom. to test the new programmed flash, a
reset/switch/release reset is necessary and the board boots from the new
flash image instead of the rom.

considering the above procedure, it is more convenient to do a mix of
several tests in ram and when things look stable to give it a try in flash.

so both ROM and RAM images should be available at the same time.
reconfiguring ecos and performing a full build is tedious and is really
useless, since the rom image is in fact build from exactly the same object
files but using a different link configuration.


probably one convenient way to do it would be to extend the definitions to
simultanously include both ram and rom ldi files (so target-ram.ld and
target-rom.ld to be created) and to repeat the link step for both ld files.

a more generic approach would use a list of ldi files and produce a set of
output files, one for each ld. (this will also cover our third build case,
when we need to produce a HEX file to be burned into PROM...)


regards,

Liviu