This is the mail archive of the ecos-devel@sources.redhat.com 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: [ECOS] Redboot-GDB


"Michael Anburaj" <embeddedeng@hotmail.com> writes:

> Hi,
> 
> I have a very simple issue with the Redboot_gdb_stub, which anyone
> familiar with Redboot should know the answer.
> 
> 1. After continue command is issued in the gdb console, $C0a#d4 is
> sent by the GDB host protocol <at least this is true in my case & most
> others>.

It seems strange that it is sending a "C" command rather than a "c"
command. This is a continue with signal, in this case SIGBUS. Maybe
this is the cause of your problems. Are you sure that RedBoot has
actually reached its initial breakpoint and has not actually hit some
other error? What do you get from RedBoot if you just type a $ to the
RedBoot> prompt?

> The GDB stub inside Redboot interprets this & should eventual
> jump or switch to the application thatÂs being started. It will be
> great if you could point me to a document about this mechanism. Or at
> least if you could tell me which code (end code  ARM architecture)
> is responsible for this; then I can back track the path & figure out
> the faulty code.
> 

The documentation for this stuff is the code itself. You will just
have to follow it. The control flow should be fairly easy to follow:
from handling the "c" command in __process_packet() it just returns to
process_exception() and then to __handle_exception().
__handle_exception() then returns to the HAL, to exception_handler()
in hal_misc.c which then returns to the exception code in vectors.S,
which just restores the CPU state and continues the interrupted code.

However, there is very little that your platform HAL can do to mess
this up. The only real platform-specific code in all of this is the
cache flush/invalidate macros. But ARM7s don't have caches, so this is
not relevant.

Normally this code gives no problems, it usually just works first
time. While tracing this code may give you a clue as to what is
actually wrong, don't spend too much time trying to understand it or
lookig for bugs in it. The problem is almost certainly in your
platform HAL somewhere. Maybe you have problems like a misconfigured
memory controller, or the memory map is not what you think.

-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts


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