[ECOS] CDL question

[ECOS] CDL question

[Grant Edwards]

In the cdl file for my platform HAL package, I'd like to change
the default value of CYGHWR_HAL_ARM_BIGENDIAN to 1. In the
Component Writer's Guide it explains how to define new options
in a cdl file, but what I'm trying to do is set the value for
an existing option.

Is this possible?

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] CDL question

[Bart Veer]

>>>>> "Grant" == Grant Edwards <grante@visi.com> writes:

    Grant> In the cdl file for my platform HAL package, I'd like to
    Grant> change the default value of CYGHWR_HAL_ARM_BIGENDIAN to 1.
    Grant> In the Component Writer's Guide it explains how to define
    Grant> new options in a cdl file, but what I'm trying to do is set
    Grant> the value for an existing option.

    Grant> Is this possible?

You cannot change the default value of some option in another package
(for the time being anyway), manipulating package configury like that
breaks encapsulation.

Instead your HAL package should use an appropriate requires property,
i.e.:

cdl_package XXXPKG_HAL_ARM_WHATEVER {
    ...
    requires CYGHWR_HAL_ARM_BIGENDIAN
}

The libcdl inference engine should sort this out pretty much
automatically, with no user intervention. If some user still wants to
use little-endian mode on that platform (assuming the platform HAL
code allows it), you will end up with a configuration containing
conflicts. This should not prevent a user from building the
configuration, but there will be some warnings.

If you want to be less draconian, you can add a line to the ecos.db
file:

target whatever {
    ...
    enable { CYGHWR_HAL_ARM_BIGENDIAN }
}

This would give BIGENDIAN a user value of enabled when the target is
selected, and the user could then switch back to little-endian without
raising any conflicts. 

Generally the requires property would be preferred, the ecos.db
mechanism is basically a backdoor mechanism that helps us to cope with
the vast diversity of hardware.

You could also add an endianness configuration option to the platform
HAL with an appropriate requires property for the architectural HAL,
but that starts getting messy.

Bart

Re: [ECOS] CDL question

[Grant Edwards]

> You cannot change the default value of some option in another
> package (for the time being anyway), manipulating package
> configury like that breaks encapsulation.
> 
> Instead your HAL package should use an appropriate requires
> property, i.e.:
> 
> cdl_package XXXPKG_HAL_ARM_WHATEVER {
>     ...
>     requires CYGHWR_HAL_ARM_BIGENDIAN
> }
>
> The libcdl inference engine should sort this out pretty much
> automatically, with no user intervention. 

Cool, thanks.  The "no user intervention" part was what I hadn't
figured out how to do.

I was using "requires CYGHWR_HAL_ARM_BIGENDIAN == 1", but that
didn't set the user value, it just warned you when you did an
"ecosconfig check".

> If some user still wants to use little-endian mode on that
> platform (assuming the platform HAL code allows it), you will
> end up with a configuration containing conflicts. This should
> not prevent a user from building the configuration, but there
> will be some warnings.

The hardware won't work right in little-endian mode, and you'd
have to modify the board to get it into little-endian mode
anyway.  So some warnings would be a good thing.  ;)

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] CDL question

[Bart Veer]

>>>>> "Grant" == Grant Edwards <grante@visi.com> writes:

    >> You cannot change the default value of some option in another
    >> package (for the time being anyway), manipulating package
    >> configury like that breaks encapsulation.
    >> 
    >> Instead your HAL package should use an appropriate requires
    >> property, i.e.:
    >> 
    >> cdl_package XXXPKG_HAL_ARM_WHATEVER {
    >> ...
    >> requires CYGHWR_HAL_ARM_BIGENDIAN
    >> }
    >> 
    >> The libcdl inference engine should sort this out pretty much
    >> automatically, with no user intervention. 

    Grant> Cool, thanks. The "no user intervention" part was what I
    Grant> hadn't figured out how to do.

    Grant> I was using "requires CYGHWR_HAL_ARM_BIGENDIAN == 1", but
    Grant> that didn't set the user value, it just warned you when you
    Grant> did an "ecosconfig check".

I believe it should actually figure things out as soon as you do the
`ecosconfig new', unless you explicitly disable inference with
--no-resolve. If you look at the resulting ecos.ecc savefile, you
should see CYGHWR_HAL_ARM_BIGENDIAN with an inferred value, which
takes priority over the default value.

However, I have just spotted a problem in the inference engine code:
currently it will fail to trigger for "xxx == 1" if xxx is a boolean,
it will only trigger if xxx has a data part. If you rewrite it as
"requires CYGHWR_HAL_ARM_BIGENDIAN" then things should work better.

Unfortunately the inference engine does still need a fair bit of work,
but it was not worth holding up the release for that.

Bart

[ECOS] CDL question

[Sergei Gavrikov]

Hello

I'm trying to join a few HALs for almost the same boards in a single HAL
package. The boards have the same CPU and RAM, but they differ by the
FLASH parts and LAN controllers. I had an idea to select one target name
and then to select the kind of the hardware using the CDL validators:
is_substr, is_active.

It works fine, but, now I want evaluate `legal_values' list, and I found
that I cannot manage it like `default_value' or `calculated' things.  Is
it possible evaluate legal_values list? First, I think that I will can
manage the issue using quotes instead brackets, but that did not work
with the list. Well, it is possible to solve a puzzle using a few CDL
options, but, a question is, Is it possible to solve the puzzle inside
one component using no extra options and just using the expression for
`legal_values' list?

What I try to do using CDL expressions

if {board == A} {
	default_value A
	legal_values {A B C}
} else if {board == B} {
	default_value X
	legal_values {X Y Z}
}

and using in two-lines coding I could get only, for example,

	default_value B
	legal_values {A B C X Y Z}

Thanks for any comments on it.

Sergei

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

Re: [ECOS] CDL question

[Andrew Lunn]

On Mon, Jul 31, 2006 at 09:36:58PM -0500, Grant Edwards wrote:
> I've read through the CDL sections of the component developer's
> guide, but I can't figure out what the command is to set a data
> flavored option to an expression involving it's default value
> or it's current value.
> 
> Assume I've got an ecos.ecc file that I generated via an
> "ecosconfig new whatever" command.  Now I want to change the
> value of CYGBLD_GLOBAL_CFLAGS (which has its default value) to
> add "-DFooBar".  This needs to be done in a shell script so
> that I can automate the entire build process.  Usually when I
> need to make automated changes to ecos.ecc I create a .cdl file
> and import it like this:
> 
>    cat >.tmp$$.cdl <<EOF
>    cdl_option CYGBLD_BUILD_REDBOOT_WITH_GDB {user_value 0}
>    cdl_option CYGBLD_BUILD_REDBOOT_WITH_ZLIB {user_value 0}
>    EOF
>    ecosconfig import .tmp$$.cdl
> 
> However, I can't figure out what the TCL expression is for "the
> current value of option CYG_WHATEVER".  I thought perhaps something like
>    
>    option CYGBLD_GLOBAL_CFLAGS {user_value "$CYGBLD_GLOBAL_CFLAGS -DFooBar"}
> 
> But that doesn't work.  I'm sure it's something obvious, but
> I've never been able to grok TCL no matter how hard I try...

This method will not work. tcl has no access to CDL
variables. $CYGBLD_GLOBAL_CFLAGS means nothing to tcl.

You could use the cdl_option CYGPKG_KERNEL_CFLAGS_REMOVE,
CYGPKG_KERNEL_LDFLAGS_ADD etc to add FooBar to specific packages, in
this example the kernel. 

Another idea would be something like adding a custom package with CDL
something like:

cdl_option CYGBLD_DIDDLE_THE_FLAGS {
     flavor data
     default_value ""
     requires { is_substr(CYGBLD_GLOBAL_CFLAGS, CYGBLD_DIDDLE_THE_FLAGS) }
}

Then you can set CYGBLD_DIDDLE_THE_FLAGS from your import file and the
inference engine will do the rest.

          Andrew

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

[ECOS] CDL question

[Grant Edwards]

I've read through the CDL sections of the component developer's
guide, but I can't figure out what the command is to set a data
flavored option to an expression involving it's default value
or it's current value.

Assume I've got an ecos.ecc file that I generated via an
"ecosconfig new whatever" command.  Now I want to change the
value of CYGBLD_GLOBAL_CFLAGS (which has its default value) to
add "-DFooBar".  This needs to be done in a shell script so
that I can automate the entire build process.  Usually when I
need to make automated changes to ecos.ecc I create a .cdl file
and import it like this:

   cat >.tmp$$.cdl <<EOF
   cdl_option CYGBLD_BUILD_REDBOOT_WITH_GDB {user_value 0}
   cdl_option CYGBLD_BUILD_REDBOOT_WITH_ZLIB {user_value 0}
   EOF
   ecosconfig import .tmp$$.cdl

However, I can't figure out what the TCL expression is for "the
current value of option CYG_WHATEVER".  I thought perhaps something like
   
   option CYGBLD_GLOBAL_CFLAGS {user_value "$CYGBLD_GLOBAL_CFLAGS -DFooBar"}

But that doesn't work.  I'm sure it's something obvious, but
I've never been able to grok TCL no matter how hard I try...

-- 
Grant Edwards
grante@visi.com



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

Re: [ECOS] CDL question

[Bart Veer]

>>>>> "Trenton" == Trenton D Adams <tadams@extremeeng.com> writes:

    Trenton> Is the following
    Trenton>         define_proc {__DEVICE_NAME "eth1"}
    Trenton> the same as 
    Trenton> 	  #define __DEVICE_NAME "eth1"
    Trenton> ???

No.

define_proc provides a fragment of Tcl code which can be used to put
arbitrary text into a header file. The "proc" bit stands for
procedure, and "proc" also happens to be the standard Tcl command for
defining a new command.

What would happen in this case is that a Tcl interpreter running
inside the configuration tools would attempt to execute the Tcl
command __DEVICE_NAME with a single argument, eth1. Since there is no
such Tcl command that is not going to work very well.

Instead you can use something like:

    define_proc {
        puts $cdl_header "#define __DEVICE_NAME \"eth1\""
    }

using the Tcl "puts" command with appropriate arguments. See
http://sources.redhat.com/ecos/docs-latest/cdl/ref.define-proc.html
and the Component Writer's Guide generally for more details.

Bart

[ECOS] CDL question

[Trenton D. Adams]

Is the following
        define_proc {__DEVICE_NAME "eth1"}
the same as 
	  #define __DEVICE_NAME "eth1"
???


Trenton D. Adams
Extreme Engineering
#17, 6025 - 12 St. SE
Calgary, Alberta, Canada
T2H 2K1

Phone: 403 640 9494 ext-208
Fax: 403 640 9599

http://www.extremeeng.com