Re: [ECOS] GDB stub for RAM startup.

[Nick Garnett <nickg at ecoscentric dot com>]

Ottawa Guy <ottawaguy81@yahoo.com> writes:

> Hi,
> I am using sparc leon board. This board comes with
> serial port, PCI interface and DSU software.
> 
> Using the DSU software I can download an "elf" file
> into the board's memory and reset the PC to start
> executing. All I want is to use the serial port for
> debug (gdb). 
> 
> I have ported the CYGINT_HAL_VIRTUAL_VECTOR_SUPPORT.
> So that I could configure the serial port.
> 
> I have the following question.
> 
> 1. My application is only "RAM" startup. Do I need
> include  "ROM-MONITOR" package or REDBOOT package

RAM startup generally means that it expects to have been loaded by a
ROM monitor, so it will probably not do a full initialization of the
hardware. You may be able to get it to do a full initialization by
disabling CYGSEM_HAL_USE_ROM_MONITOR, but that does not work in all
HALs.


> 2. In the platform specific *.cdl file . I have the
> following 
> 
>   cdl_option CYGBLD_BUILD_GDB_STUBS {
>             display "Build GDB stub RAM image"
>             default_value 0
>             requires { CYG_HAL_STARTUP == "RAM" }
>             requires
> CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS
>            }
> 
> Do I need anything else under the "Required" claused. 
>

CYGBLD_BUILD_GDB_STUBS is for building a very cut-down ROM monitor
that only contains the GDB remote protocol stubs and nothing
else. It is not used much any more. You probably don't need it.


> 3. What is  "CYGINT_HAL_DEBUG_GDB_STUBS_BREAK"

It is part of the support for allowing ^C to be used from GDB to
interrupt a running program.

> Can someone tell me what else I am missing.
>             Ottawa

The main problem is that you are trying to do something that under
normal circumstances is not possible. Applications are normally
started from the reset vector and run from ROM, or are loaded by
something else and run from RAM. Applications don't usually find
themselves in RAM in an otherwise uninitialized machine. Hence we have
very little support for this kind of thing.

Your best bet is to simply build a ROM application and change the load
addresses in the .ldi file to place it all in RAM. Or fake it and
pretend that the top 512k of RAM is really ROM and just build a ROM
application that starts from there.

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


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