* [ECOS] question about cyg_hal_invoke_constructors
@ 2005-05-14 11:13 von Lehe, Richard H
2005-05-14 16:26 ` Gary Thomas
0 siblings, 1 reply; 2+ messages in thread
From: von Lehe, Richard H @ 2005-05-14 11:13 UTC (permalink / raw)
To: Ecos-Discuss (E-mail)
Greetings,
I've had lots of success with Analogue & Micro boards (AdderII and Rattler) in the recent past, but seem to be stuck getting an application to run on the Boa board that we've recently received. I believe I have a configuration problem, but I'm not sure why what I have done is not working for me.
What I did is very simple:
* I am using a BDI2000 to load and run an application from RAM.
* I set up the kernel using the command: ecosconfig new boa net
* I compiled the kernel ('make') then did a 'make tests'
* I've tried to run a couple of simple tests: 'bin_sem0' and 'sprintf1' using 'ddd --debugger powerpc-eabi-gdb'
What I see is this:
* I can load the test just fine, and can step quite a ways into the initialization.
* When I reach cyg_hal_invoke_constructors, it freezes halfway through the list.
* I have narrowed it down to the constructor for net_init_class.
There's the whole messy macro call tree in include/cyg/hal/hal_if.h, but it basically boils down to a missing entry in the hal_virtual_vector_table. It's trying to call a function pointer stored at location 14 in the table, which is garbage. It seems like the entry that is supposed to get placed there (at id==CYGNUM_CALL_IF_SET_CONSOLE_COMM) doesn't get put there unless I have defined CYGSEM_HAL_VIRTUAL_VECTOR_CLAIM_COMMS. It seems the only place this could happen is in hal_if.c.
My question is: what is this CYGSEM_HAL_VIRTUAL_VECTOR_CLAIM_COMMS and why isn't this set by default for the configuration I have chosen?
Thanks for any suggestions!
Richard von Lehe
General Dynamics Advanced Information Systems
8800 Queen Ave. S.
Bloomington, MN 55431
952-921-6406
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [ECOS] question about cyg_hal_invoke_constructors
2005-05-14 11:13 [ECOS] question about cyg_hal_invoke_constructors von Lehe, Richard H
@ 2005-05-14 16:26 ` Gary Thomas
0 siblings, 0 replies; 2+ messages in thread
From: Gary Thomas @ 2005-05-14 16:26 UTC (permalink / raw)
To: von Lehe, Richard H; +Cc: Ecos-Discuss (E-mail)
On Fri, 2005-05-13 at 14:05 -0500, von Lehe, Richard H wrote:
> Greetings,
>
> I've had lots of success with Analogue & Micro boards (AdderII and Rattler) in the recent past, but seem to be stuck getting an application to run on the Boa board that we've recently received. I believe I have a configuration problem, but I'm not sure why what I have done is not working for me.
>
> What I did is very simple:
>
> * I am using a BDI2000 to load and run an application from RAM.
Applications which are loaded directly into RAM via a hardware
debugger must be configured to take over everything. I use these
settings when I need to build such a program:
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
};
That said, it's almost always advisable to just use RedBoot to
load and execute your code :-)
> * I set up the kernel using the command: ecosconfig new boa net
> * I compiled the kernel ('make') then did a 'make tests'
> * I've tried to run a couple of simple tests: 'bin_sem0' and 'sprintf1' using 'ddd --debugger powerpc-eabi-gdb'
>
>
> What I see is this:
>
> * I can load the test just fine, and can step quite a ways into the initialization.
> * When I reach cyg_hal_invoke_constructors, it freezes halfway through the list.
> * I have narrowed it down to the constructor for net_init_class.
>
> There's the whole messy macro call tree in include/cyg/hal/hal_if.h, but it basically boils down to a missing entry in the hal_virtual_vector_table. It's trying to call a function pointer stored at location 14 in the table, which is garbage. It seems like the entry that is supposed to get placed there (at id==CYGNUM_CALL_IF_SET_CONSOLE_COMM) doesn't get put there unless I have defined CYGSEM_HAL_VIRTUAL_VECTOR_CLAIM_COMMS. It seems the only place this could happen is in hal_if.c.
>
> My question is: what is this CYGSEM_HAL_VIRTUAL_VECTOR_CLAIM_COMMS and why isn't this set by default for the configuration I have chosen?
>
> Thanks for any suggestions!
>
> Richard von Lehe
> General Dynamics Advanced Information Systems
> 8800 Queen Ave. S.
> Bloomington, MN 55431
> 952-921-6406
>
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2005-05-13 19:33 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-05-14 11:13 [ECOS] question about cyg_hal_invoke_constructors von Lehe, Richard H
2005-05-14 16:26 ` Gary Thomas
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).