This is the mail archive of the ecos-discuss@sourceware.org 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]
Other format: [Raw text]

Re: Re: NIOS2 toolchain build failure under Cygwin


>>>>> "Oyvind" == =?ISO-8859-1?Q?=D8yvind Harboe?= <ISO-8859-1> writes:

    <snip>

    >> Building eCos for NIOS2 is the biggest mess I've ever seen: A
    >> Shell script wrapper for a Java program that generates a CDL
    >> file that generates a shell script that generates a Perl script
    >> that calls a Java program that generates include files, etc.
    >> etc.
    >> 
    >> What a pile.

    Oyvind> I don't know why Altera thinks it needs to be that way.

    Oyvind> Though I can see how a soft-CPU with a dynamic number of
    Oyvind> peripherals would be a poor impeadance match with eCos
    Oyvind> static cdl files.

According to the design, CDL files do not have to be static. CDL is
embedded in a general-purpose scripting language, Tcl. Conceptually
that gives it the flexibility to adapt to changing hardware, including
reconfigurable systems. The problems are:

  1) the CDL implementation is still incomplete, for a variety of
     reasons I do not intend to go into here.

  2) not all the concepts behind CDL are widely understood, leading to
     flawed approaches like generating static CDL files.

    Oyvind> I never quite understood why eCos considers a specific HAL
    Oyvind> part of eCos. I always viewed the HAL as part of the
    Oyvind> application. Although final PCB's might strongly resemble
    Oyvind> a particular evaluation board, I wouldn't expect it to be
    Oyvind> exactly like the evaluation board in the general case.
    Oyvind> Never happened to me anyway. The stuff that can be shared
    Oyvind> between HALs and that does not change between HALs seems
    Oyvind> to belong(as in making the whole shebang more easily
    Oyvind> maintainable) in eCos.

I assume you are referring here specifically to platform HALs.
Architectural, processor and variant HALs obviously belong in the eCos
repository, they can be re-used across multiple platforms.

Typically there will be information in the platform HAL which other
packages will want to know at compile-time. For example the cpu speed
on a particular board is typically a characteristic of the platform
HAL but that information may be needed in various places, e.g. in
serial drivers when converting baud rates to register values. If you
make the platform HAL part of the application then the only way eCos
packages can get hold of that kind of information is at link-time via
variables or functions. That has code-size and performance penalties.

You also need to consider what happens from a maintainer's
perspective:

1) how do you build and run the tests for a given platform if the
   platform details are held in application space?

2) similarly how do you build RedBoot (assuming RedBoot is appropriate
   for the target hardware)?

3) how do you make coherent releases for a given platform, e.g. a
   standard evaluation board?

Having platform HALs makes some things a lot easier, even if at times
it may make life a bit more difficult for application developers
porting to custom hardware.

Bart

-- 
Bart Veer                       eCos Configuration Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


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