[ECOS] Building eCos hello world

[ECOS] Building eCos hello world

[David Ho]

Hi,

I am attempting to build an eCos hello world app, but I have quickly
stumbled on an issue.
As I am investigating I found that the platform specific serial port
code is missing, and I noticed it is _not active_ because
IO_SERIAL_DEVICES is disabled.

Now does eCos have a default ecm file like RedBoot? (e.g.redboot_RAM.ecm).
What would be a way to enable it by default?

Thanks, David

cdl_package CYGPKG_IO_SERIAL_ARM_AT91 {
    # Packages cannot be added or removed, nor can their version be changed,
    # simply by editing their value. Instead the appropriate configuration
    # should be used to perform these actions.

    # This option is not active
    # The parent CYGPKG_IO_SERIAL_DEVICES is disabled
    # ActiveIf constraint: CYGPKG_IO_SERIAL
    #     CYGPKG_IO_SERIAL == current
    #   --> 1
    # ActiveIf constraint: CYGPKG_HAL_ARM_AT91
    #     CYGPKG_HAL_ARM_AT91 == current
    #   --> 1

    # This value cannot be modified here.
    # Flavor: booldata
    # Current value: 1 current
    # Requires: CYGPKG_ERROR
    #     CYGPKG_ERROR == current
    #   --> 1
};

-- 
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] Building eCos hello world

[David Ho]

On 7/27/06, Sergei Gavrikov <w3sg@softhome.net> wrote:
>
>
> On Thu, 27 Jul 2006, David Ho wrote:
>
> > Hi,
> >
> > I am attempting to build an eCos hello world app, but I have quickly
> > stumbled on an issue.
> > As I am investigating I found that the platform specific serial port
> > code is missing, and I noticed it is _not active_ because
> > IO_SERIAL_DEVICES is disabled.
> >
> > Now does eCos have a default ecm file like RedBoot? (e.g.redboot_RAM.ecm).
> > What would be a way to enable it by default?
> >
> > Thanks, David
>
> Which eCos template is used? Try to use the `default' template.

I am using the default template.

bash$ ecosconfig new satmodem

Where is default configuration defined?
When I forcibly enable it in ecos.db

I get the following complaint, and it is still disabled.

Hardware selection, target `satmodem': warning
    The option `CYGPKG_IO_SERIAL_DEVICES' is supposed to be enabled
for this target.
    However this option is not in the current configuration.

target satmodem {
        alias { "NMX satmodem board (satmodem)" at91_satmodem }
        packages { CYGPKG_HAL_ARM
                   CYGPKG_HAL_ARM_AT91
                   CYGPKG_HAL_ARM_AT91_SATMODEM
                   CYGPKG_IO_SERIAL_ARM_AT91
                   CYGPKG_IO_FLASH
                   CYGPKG_DEVS_FLASH_SATMODEM
                   CYGPKG_DEVS_FLASH_AMD_AM29XXXXX
                   CYGPKG_DEVICES_WATCHDOG_ARM_AT91
        }
        enable { CYGPKG_IO_SERIAL_DEVICES }
        description "
        The satmodem target provides the packages needed to run eCos on an NMX
        satmodem board (SATMODEM)."
}


David

-- 
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] Building eCos hello world

[David Ho]

> porting eCos for own target. Is it right? So, look at the at91* target
> descriptions, please:
>

I tried another at91 target (eb40a).  I got the same thing.  I will
look around some more.

David

# >
# Atmel AT91 serial device drivers
# This option enables the serial device drivers for the
# Atmel AT91.
#
cdl_package CYGPKG_IO_SERIAL_ARM_AT91 {
    # Packages cannot be added or removed, nor can their version be changed,
    # simply by editing their value. Instead the appropriate configuration
    # should be used to perform these actions.

    # This option is not active
    # The parent CYGPKG_IO_SERIAL_DEVICES is disabled
    # ActiveIf constraint: CYGPKG_IO_SERIAL
    #     CYGPKG_IO_SERIAL == current
    #   --> 1
    # ActiveIf constraint: CYGPKG_HAL_ARM_AT91
    #     CYGPKG_HAL_ARM_AT91 == current
    #   --> 1

    # This value cannot be modified here.
    # Flavor: booldata
    # Current value: 1 current
    # Requires: CYGPKG_ERROR
    #     CYGPKG_ERROR == current
    #   --> 1
};

-- 
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] Building eCos hello world

[Sergei Gavrikov]

On Thu, 27 Jul 2006, David Ho wrote:

>> porting eCos for own target. Is it right? So, look at the at91* target
>> descriptions, please:
>> 
>
> I tried another at91 target (eb40a).  I got the same thing.  I will
> look around some more.
>
> David
>
> # >
> # Atmel AT91 serial device drivers
> # This option enables the serial device drivers for the
> # Atmel AT91.
> #
> cdl_package CYGPKG_IO_SERIAL_ARM_AT91 {
>   # Packages cannot be added or removed, nor can their version be changed,
>   # simply by editing their value. Instead the appropriate configuration
>   # should be used to perform these actions.
>
>   # This option is not active

Oh, that concerns you... Try it (copy-n-paste to bash)

cat >serdev.ecm<<_eof
cdl_component CYGPKG_IO_SERIAL_DEVICES {
 	user_value 1
}
_eof
ecosconfig new eb40a
ecosconfig add posix
ecosconfig import serdev.ecm
ecosconfig resolve
ecosconfig tree

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] Building eCos hello world

[David Ho]

I built all the examples in, examples.  I believe everyone is choking
at the same spot.

gdb tracing leads me to this.  Any idea if I am chasing the right goose?

Thanks, David

Breakpoint 1, hal_if_diag_write_char (c=83 'S') at hal_if.h:590
590     __data_VV(CYGNUM_CALL_IF_CONSOLE_PROCS, __call_if_console_procs_t)
Current language:  auto; currently c
(gdb) stepi
0x0000d4b4      590     __data_VV(CYGNUM_CALL_IF_CONSOLE_PROCS,
__call_if_console_procs_t)
(gdb)
876         if (__chan)
(gdb)
606     __data_VV(CYGNUM_CALL_IF_DEBUG_PROCS, __call_if_debug_procs_t)
(gdb)
873     {
(gdb)
0x0000d4c4      873     {
(gdb)
305     __call_voidCOMM1(IF_PUTC, void, __comm_if_putc_t, cyg_uint8)
(gdb)
0x0000d4d0      305     __call_voidCOMM1(IF_PUTC, void,
__comm_if_putc_t, cyg_uint8)
(gdb)
0x0000000c in ?? ()
(gdb)
0x0000c1a4 in abort_prefetch ()

-- 
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] Building eCos hello world

[David Ho]

Okay, I finally figured it out.  I wasn't aware of what virtual
vectors are used for.  I guess ecos applications makes use of services
provided by redboot.

I keep convincing myself that an ecos application can be run
standalone for some reason.  Haha,  I was indeed chasing a wild goose.

Thanks, David

On 7/28/06, David Ho <davidkwho@gmail.com> wrote:
> I built all the examples in, examples.  I believe everyone is choking
> at the same spot.
>
> gdb tracing leads me to this.  Any idea if I am chasing the right goose?
>
> Thanks, David
>
> Breakpoint 1, hal_if_diag_write_char (c=83 'S') at hal_if.h:590
> 590     __data_VV(CYGNUM_CALL_IF_CONSOLE_PROCS, __call_if_console_procs_t)
> Current language:  auto; currently c
> (gdb) stepi
> 0x0000d4b4      590     __data_VV(CYGNUM_CALL_IF_CONSOLE_PROCS,
> __call_if_console_procs_t)
> (gdb)
> 876         if (__chan)
> (gdb)
> 606     __data_VV(CYGNUM_CALL_IF_DEBUG_PROCS, __call_if_debug_procs_t)
> (gdb)
> 873     {
> (gdb)
> 0x0000d4c4      873     {
> (gdb)
> 305     __call_voidCOMM1(IF_PUTC, void, __comm_if_putc_t, cyg_uint8)
> (gdb)
> 0x0000d4d0      305     __call_voidCOMM1(IF_PUTC, void,
> __comm_if_putc_t, cyg_uint8)
> (gdb)
> 0x0000000c in ?? ()
> (gdb)
> 0x0000c1a4 in abort_prefetch ()
>

-- 
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] Re: Building eCos hello world

[Grant Edwards]

In gmane.os.ecos.general, you wrote:

> Okay, I finally figured it out.  I wasn't aware of what
> virtual vectors are used for.  I guess ecos applications makes
> use of services provided by redboot.

They can, if you configure them that way.

> I keep convincing myself that an ecos application can be run
> standalone for some reason.

They can, if you configure them that way.

-- 
Grant Edwards                   grante             Yow!  ... or were you
                                  at               driving the PONTIAC that
                               visi.com            HONKED at me in MIAMI last
                                                   Tuesday?

-- 
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] Re: Building eCos hello world

[David Ho]

On 7/28/06, Grant Edwards <grante@visi.com> wrote:
> In gmane.os.ecos.general, you wrote:
>
> > Okay, I finally figured it out.  I wasn't aware of what
> > virtual vectors are used for.  I guess ecos applications makes
> > use of services provided by redboot.
>
> They can, if you configure them that way.

May I be further enlightened by your wisdom by telling me where this
configuration is, the default of which is to use services provided by
RedBoot.

Thanks, David

-- 
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] Re: Building eCos hello world

[Grant Edwards]

In gmane.os.ecos.general, you wrote:
> On 7/28/06, Grant Edwards <grante@visi.com> wrote:
>> In gmane.os.ecos.general, you wrote:
>>
>> > Okay, I finally figured it out.  I wasn't aware of what
>> > virtual vectors are used for.  I guess ecos applications makes
>> > use of services provided by redboot.
>>
>> They can, if you configure them that way.
>
> May I be further enlightened by your wisdom by telling me where this
> configuration is, the default of which is to use services provided by
> RedBoot.

Actually, I wasn't aware that was the default.  None of my apps
use RedBoot services, and I don't remember ever having to
change anything, but I may have just picked the right defaults
when I created the HAL for my target platform.

Browsing through the ecos.ecc file, here are few likely
settings:

turn off CYGSEM_HAL_VIRTUAL_VECTOR_INHERIT_CONSOLE
turn on  CYGSEM_HAL_VIRTUAL_VECTOR_CLAIM_COMMS
turn on  CYGSEM_HAL_VIRTUAL_VECTOR_INIT_WHOLE_TABLE 
turn on  CYGSEM_HAL_VIRTUAL_VECTOR_CLAIM_DEFAULT

-- 
Grant Edwards                   grante             Yow!  I'm pretending that
                                  at               we're all watching PHIL
                               visi.com            SILVERS instead of RICARDO
                                                   MONTALBAN!

-- 
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] Re: Building eCos hello world

[Gary Thomas]

[-- Attachment #1: Type: text/plain, Size: 1466 bytes --]

Grant Edwards wrote:
> In gmane.os.ecos.general, you wrote:
>> On 7/28/06, Grant Edwards <grante@visi.com> wrote:
>>> In gmane.os.ecos.general, you wrote:
>>>
>>>> Okay, I finally figured it out.  I wasn't aware of what
>>>> virtual vectors are used for.  I guess ecos applications makes
>>>> use of services provided by redboot.
>>> They can, if you configure them that way.
>> May I be further enlightened by your wisdom by telling me where this
>> configuration is, the default of which is to use services provided by
>> RedBoot.
> 
> Actually, I wasn't aware that was the default.  None of my apps
> use RedBoot services, and I don't remember ever having to
> change anything, but I may have just picked the right defaults
> when I created the HAL for my target platform.
> 
> Browsing through the ecos.ecc file, here are few likely
> settings:
> 
> turn off CYGSEM_HAL_VIRTUAL_VECTOR_INHERIT_CONSOLE
> turn on  CYGSEM_HAL_VIRTUAL_VECTOR_CLAIM_COMMS
> turn on  CYGSEM_HAL_VIRTUAL_VECTOR_INIT_WHOLE_TABLE 
> turn on  CYGSEM_HAL_VIRTUAL_VECTOR_CLAIM_DEFAULT

Probably the easiest (on those platforms that *do* have RedBoot)
is to make sure that CYGSEM_HAL_USE_ROM_MONITOR is disabled.

For PowerPC targets, I use the attached .ecm script.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

[-- Attachment #2: ppc_stand_alone --]
[-- Type: text/plain, Size: 263 bytes --]

cdl_component CYGDBG_HAL_DIAG_TO_DEBUG_CHAN {
    user_value 0
};

cdl_option CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS {
    user_value 0
};

cdl_option CYGSEM_HAL_USE_ROM_MONITOR {
    user_value 0
};

cdl_option CYGSEM_HAL_POWERPC_COPY_VECTORS {
    user_value 1
};


[-- Attachment #3: Type: text/plain, Size: 148 bytes --]

-- 
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] Re: Building eCos hello world

[David Ho]

I used the following three options and it work beautifully for me.

Thanks once again,
David

> cdl_component CYGDBG_HAL_DIAG_TO_DEBUG_CHAN {
>     user_value 0
> };
>
> cdl_option CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS {
>     user_value 0
> };
>
> cdl_option CYGSEM_HAL_USE_ROM_MONITOR {
>     user_value 0
> };

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