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]

Chicken and the Egg: GDB, eCos, Virtual Vectors


I have scoured the docs and sources, tried multiple (some illegal)
configurations just to see if I could circumvent the rom requirement of
CYG_HAL_STARTUP to fit our ram model, but alas I have come to realize I
must bow to the ecos gurus and seek confirmation of my assumptions and
some guidance. I am going to error on the side of including more
information rather than less so no questions are left unanswered.

[Our Setup]
Our platform is a RAM only model ARM target. Redboot, obviously, is
built with our hal package included. The inclusion prevents us from
building a redboot with startup type = ROM. (A ROMRAM build doesn't get
the job done either)

1) Board bringup:
	a) a small startup binary at rom address 0 copies redboot
	   from rom into ram, starts redboot and swaps memory
	   locations so that ram is at ram address 0. Redboot is
	   loaded in the upper end of ram with applications loaded
	   at ram address 0.

This model allows redboot to update itself (image stored in rom). It
requires flash programming utils which prevents CYG_HAL_STARTUP == ROM.

What gdb can do with a ram model, both redboot and application.

1) Attach to remote target and load application.
2) Set Breakpoints:
	a) Non-threaded code allows stepping but pukes
	   on a subsequent continue.
	   (e.g. break at cyg_user_start, step step, continue, puke)
	b) Breaks inside threaded functions will allow inspection
	   of variables, etc. but not stepping. Continue, again,
	   is not possible.

What gdb cannot do in a ram model is:

1) Continue from any point in code.
2) Single step inside threads.
3) Show thread information.

[Virtual Vectors]
Our app does have the virtual Vector (VV) mechanism in place but it
appears to be useless/limited because we must still use a redboot that
runs from rom, is that correct?

Also, the VV doc states that we must implement our own asynchronous
debugger interrupts (ASI) and hooks for accessing kernel thread
information (KTI). The docs also states to look in the powerpc/cogent
code to find a reference implementation of VVs. I could not find the
specific code that handles the ASI & KTI calls. Could someone point to
where I might find those code blocks?


Now my main question is if I redo our model so redboot can run from rom
with our app still in ram will that solve the stepping and continuing
problem without implementing ASI or KTI right away? I am also curious as
to why a ram loaded redboot cannot be made to utilize full debugging
capabilities so developers can easily update and debug their ram
targets. Where does the restriction occur, gdb/ecos/both?

Thanks for taking the time to read through this long email, I appreciate it.

Kevin



-- 
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]