[ECOS] Redboot-GDB

[Michael Anburaj]

Hi,

Thanks to all, who responded.


>From: Nick Garnett <nickg@ecoscentric.com>
>To: "Michael Anburaj" <embeddedeng@hotmail.com>
>CC: ecos-discuss@sources.redhat.com, ecos-devel@sources.redhat.com
>Subject: Re: [ECOS] Redboot-GDB
>Date: 20 Jun 2003 08:57:56 +0100
>
>"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?

I will do some more work tomorrow & let you know. But, I was able to connect 
to the ARM9 Target & load the image without any issue. Which I guess 
indicates that the breakpoint (or Undefined instruction) exception is 
working fine. Am I right?

Only after I issue the continue command on the gdb console (on the PC host) 
the gdb on the host becomes mum. Which sends Hc0 & C0a after. Even if there 
were exceptions occurring on the target, in which case I would imagine the 
target communicating this 1st to the host (Signaling its condition). I am 
right? <I am not a GDB expert, so excuse me if I am wrong :), just a guess >


>However, there is very little that your platform HAL can do to mess
>this up.

Yea you are right, pretty much every thing is done in /arch or /arm9/var 
folders.

>The problem is almost certainly in your
>platform HAL somewhere.

Yea, i certainly agree.


One thing I really want to know is:
1. From the host I am able to connect to the target (ARM9 with 
Redboot_ROMRAM) & load the ecos image. Does this imply that the GDB serial 
protocol / breakpoint (or Undefined instruction) exception mechanism is 
working fine?

2. If thatÂ’s true, then is the packet, $C0a#d4 sent from the host the root 
of this problem? If so, what could driver the host to send this?

Also let me know what is the last redboot_ROMRAM instruction executed before 
the 1st ecos_RAM instruction at vector.S (in my case 0x40000). I mean the 
very 1st time ecos is made to run after itÂ’s loaded. Does this (last 
redboot_ROMRAM) code live in return_from_exception: of vector.S?


Thanks a lot,
-Mike.

_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail


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