[ECOS] Correctly disabling GDB support in application/kernel

[Manuel Borchers <manuel at matronix dot de>]

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: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil