This is the mail archive of the ecos-discuss@sourceware.cygnus.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: CDL parent target+options?


> The "correct" way to do this is indeed to modify the .ecc file, either
> by a script, manually, or inside the GUI.

ok, I'll try to do it via a script.

> A Unix version of the GUI
> config tool is of course planned.

althought I don't like the way it looks, a Java AWT tool will probably do
the job on most platforms.

> We expect that, most of the time,
> people will use just one type of startup, probably RAM.

right

> Switching
> startups should be a fairly rare event, and there is no special
> support for it in the current tools.

ok. with a script to change options, this will be no longer needed.

>
> It is possible to achieve what you are after via the ecos.db database,
> using something like the following:
>
>     target iq80960rx_ram {
>         ...
>         set_value CYGHWR_HAL_STARTUP "RAM"
>     }

ok, I'll give it a try.

> This sort of thing is fine for development purposes, but for
> contributed entries to ecos.db I would expect to see just one target
> definition per board.

ok. but for development purposes, when "ecosconfig new" is required often
(until cdl files become stable), it would be usefull.

> There are other ways of achieving the same effect using templates, or
> by generating a partial savefile and using `ecosconfig import'.
>
>     Liviu> -/-/-
>
>     Liviu> more or less related to the above, is there any way to have
>     Liviu> a better control on the build process? for instance I would
>     Liviu> like to add new targets to the main makefile.
>
> Not at this time, I am afraid. Enhancing the configuration and build
> technology along these lines (and quite a few other lines as well) is
> on the TODO list. Providing support for additional targets could
> be done by an option to the existing CDL "make" property, or by a new
> property.

time permiting, I'll give it a try too. the main config will be ram, with a
target to build the rom version. but things will not be easy, since not only
the link phase need to be here, but also the  target-rom.ld file.

> However I do want to tread carefully here. One of the goals of the
> eCos build system is to keep things simple for ordinary application
> developers. Right now there is only one main target, and it generates
> the library and everything else needed to build applications. Allowing
> the build system to generate lots of targets could make things more
> confusing for typical application developers. I do not want to see the
> configuration technology grow into some kind of IDE for application
> development, that is not its purpose.

lots of targets are really a problem, but some 'standard' ones might be
usefull (selecting ram/rom, debug/release, for instance).

>
>     Liviu> before switching to ecos my previous build tools allowed
>     Liviu> separate debug/release targets, and in each case the link
>     Liviu> phase was doubled, producing both flash and ram versions
>     Liviu> from exactly the same object files (I personally believe it
>     Liviu> is not a good idea to propagate the ram/flash information
>     Liviu> into header files and have the object files built
>     Liviu> differently; distinct *.ld files are enough to
>     Liviu> differentiate the two cases).
>
> On some targets only the .ld files would be affected by startup
> selection, but on other targets there may have to be code changes as
> well.

you're probably right, but my own experience with embedded systems tels me
that, if carefully written, the ROM configuration can be executed from RAM
without source changes.

and since running in ram is usualy not a purpose in itself but a more
convenient debugging procedure, it is more appropriate to debug more or less
the same code as when running from rom.

> 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. We are also working on the assumption that
> changing the configuration and rebuilding is very easy - this is not
> quite true yet for Unix users.
>
> Bart

regards,

Liviu


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]