[ECOS] Correctly disabling GDB support in application/kernel

[ECOS] Correctly disabling GDB support in application/kernel

[Manuel Borchers]

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

Hi all,

as I already told in an old mail, I'm in the progress of porting eCos to
the netX controller family (ARM9 based).

The netX chips do have their own bootloaders, so I want to also support
an application profile that doesn't use Redboot. Therefore the
application is typically linked to reside in the internal RAM or in the
external SDRAM. The bootloader will fetch the App from witchever medium
is used and copy it over to SRAM/SDRAM and start it.

So far, so good. I basically got this working and I'm loading the
application's elf via a JTAG debugger to the target.
I'm somewhat struggling using the UARTs (need to verify the UART driver
and will get back to the list if I have any more problems on that).

The problem I'm facing is, that I want to completely disable any
GDB-related functions in the application/kernel, because all netX boards
are accessed through JTAG (or even ETM) using openocd.

Is there any way to do this correctly? As a result I want to have the
diagnostic channel routed to UART0 (which is the only one on this board
routed out). I don't need any GDB stub running in the kernel/the app.

Here is what I did to disable it:

-- snip --
cdl_option CYGBLD_BUILD_GDB_STUBS {
    user_value 0
};

cdl_option CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS {
    inferred_value 0
};

cdl_option CYGSEM_HAL_USE_ROM_MONITOR {
    inferred_value 0 0
};

cdl_component CYG_HAL_STARTUP {
    user_value RAM
};

cdl_option CYGSEM_HAL_DIAG_MANGLER {
  user_value None
};
-- snap --

What I'm seeing now is, that the tracing messages are being sent uisng
the GDB mangler. But with no GDB on the serial port connected, the
target will just wait forever for a GDB reply.

Any hint or example configs/options to complete disable GDB are welcome.

Cheers,
Manuel

-- 
manuel@matronix.de
http://www.matronix.de

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[ECOS] Re: Correctly disabling GDB support in application/kernel

[John Dallaway]

Hi Manuel

Manuel Borchers wrote:

> The problem I'm facing is, that I want to completely disable any
> GDB-related functions in the application/kernel, because all netX boards
> are accessed through JTAG (or even ETM) using openocd.
> 
> Is there any way to do this correctly? As a result I want to have the
> diagnostic channel routed to UART0 (which is the only one on this board
> routed out). I don't need any GDB stub running in the kernel/the app.
> 
> Here is what I did to disable it:

[ snip ]

Make sure that your eCos library and application builds are up to date
since configuring CYGSEM_HAL_DIAG_MANGLER == "None". You might consider
a "make clean" to be sure.

I usually disable CYGDBG_HAL_DIAG_TO_DEBUG_CHAN to break the association
between diagnostics and debug entirely when using JTAG with ARM targets.

I hope this helps...

John Dallaway
eCos maintainer

-- 
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: Correctly disabling GDB support in application/kernel

[Manuel Borchers]

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

Hi John,

Am Dienstag, den 18.05.2010, 17:12 +0100 schrieb John Dallaway:
> Make sure that your eCos library and application builds are up to date
> since configuring CYGSEM_HAL_DIAG_MANGLER == "None". You might consider
> a "make clean" to be sure.
> 
> I usually disable CYGDBG_HAL_DIAG_TO_DEBUG_CHAN to break the association
> between diagnostics and debug entirely when using JTAG with ARM targets.
> 
> I hope this helps...

Yes, thanks for your quick answer. I thought about something like that
already and started from "scratch", because I couldn't remember what
exactly I did to clean the tree. I startet from scratch with a new ecc
file, make clean and make. I also found the
CYGDBG_HAL_DIAG_TO_DEBUG_CHAN and disabled it.
Et voila, the messages are coming through in plain text :)

Cheers,
Manuel


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]