[ECOS] Chicken and the Egg: GDB, eCos, Virtual Vectors

[ECOS] Chicken and the Egg: GDB, eCos, Virtual Vectors

[Kevin Wilson]

I have scoured the docs and sources, tried multiple (some illegal)
configurations just to see if I could circumvent the rom requirement of
CYG_HAL_STARTUP to fit our ram model, but alas I have come to realize I
must bow to the ecos gurus and seek confirmation of my assumptions and
some guidance. I am going to error on the side of including more
information rather than less so no questions are left unanswered.

[Our Setup]
Our platform is a RAM only model ARM target. Redboot, obviously, is
built with our hal package included. The inclusion prevents us from
building a redboot with startup type = ROM. (A ROMRAM build doesn't get
the job done either)

1) Board bringup:
	a) a small startup binary at rom address 0 copies redboot
	   from rom into ram, starts redboot and swaps memory
	   locations so that ram is at ram address 0. Redboot is
	   loaded in the upper end of ram with applications loaded
	   at ram address 0.

This model allows redboot to update itself (image stored in rom). It
requires flash programming utils which prevents CYG_HAL_STARTUP == ROM.

What gdb can do with a ram model, both redboot and application.

1) Attach to remote target and load application.
2) Set Breakpoints:
	a) Non-threaded code allows stepping but pukes
	   on a subsequent continue.
	   (e.g. break at cyg_user_start, step step, continue, puke)
	b) Breaks inside threaded functions will allow inspection
	   of variables, etc. but not stepping. Continue, again,
	   is not possible.

What gdb cannot do in a ram model is:

1) Continue from any point in code.
2) Single step inside threads.
3) Show thread information.

[Virtual Vectors]
Our app does have the virtual Vector (VV) mechanism in place but it
appears to be useless/limited because we must still use a redboot that
runs from rom, is that correct?

Also, the VV doc states that we must implement our own asynchronous
debugger interrupts (ASI) and hooks for accessing kernel thread
information (KTI). The docs also states to look in the powerpc/cogent
code to find a reference implementation of VVs. I could not find the
specific code that handles the ASI & KTI calls. Could someone point to
where I might find those code blocks?


Now my main question is if I redo our model so redboot can run from rom
with our app still in ram will that solve the stepping and continuing
problem without implementing ASI or KTI right away? I am also curious as
to why a ram loaded redboot cannot be made to utilize full debugging
capabilities so developers can easily update and debug their ram
targets. Where does the restriction occur, gdb/ecos/both?

Thanks for taking the time to read through this long email, I appreciate it.

Kevin



-- 
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] Chicken and the Egg: GDB, eCos, Virtual Vectors

[Gary Thomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kevin Wilson wrote:
> I have scoured the docs and sources, tried multiple (some illegal)
> configurations just to see if I could circumvent the rom requirement of
> CYG_HAL_STARTUP to fit our ram model, but alas I have come to realize I
> must bow to the ecos gurus and seek confirmation of my assumptions and
> some guidance. I am going to error on the side of including more
> information rather than less so no questions are left unanswered.
> 
> [Our Setup]
> Our platform is a RAM only model ARM target. Redboot, obviously, is
> built with our hal package included. The inclusion prevents us from
> building a redboot with startup type = ROM. (A ROMRAM build doesn't get
> the job done either)
> 
> 1) Board bringup:
> 	a) a small startup binary at rom address 0 copies redboot
> 	   from rom into ram, starts redboot and swaps memory
> 	   locations so that ram is at ram address 0. Redboot is
> 	   loaded in the upper end of ram with applications loaded
> 	   at ram address 0.
> 
> This model allows redboot to update itself (image stored in rom). It
> requires flash programming utils which prevents CYG_HAL_STARTUP == ROM.
> 
> What gdb can do with a ram model, both redboot and application.
> 
> 1) Attach to remote target and load application.
> 2) Set Breakpoints:
> 	a) Non-threaded code allows stepping but pukes
> 	   on a subsequent continue.
> 	   (e.g. break at cyg_user_start, step step, continue, puke)
> 	b) Breaks inside threaded functions will allow inspection
> 	   of variables, etc. but not stepping. Continue, again,
> 	   is not possible.
> 
> What gdb cannot do in a ram model is:
> 
> 1) Continue from any point in code.
> 2) Single step inside threads.
> 3) Show thread information.
> 
> [Virtual Vectors]
> Our app does have the virtual Vector (VV) mechanism in place but it
> appears to be useless/limited because we must still use a redboot that
> runs from rom, is that correct?
> 
> Also, the VV doc states that we must implement our own asynchronous
> debugger interrupts (ASI) and hooks for accessing kernel thread
> information (KTI). The docs also states to look in the powerpc/cogent
> code to find a reference implementation of VVs. I could not find the
> specific code that handles the ASI & KTI calls. Could someone point to
> where I might find those code blocks?
> 
> 
> Now my main question is if I redo our model so redboot can run from rom
> with our app still in ram will that solve the stepping and continuing
> problem without implementing ASI or KTI right away? I am also curious as
> to why a ram loaded redboot cannot be made to utilize full debugging
> capabilities so developers can easily update and debug their ram
> targets. Where does the restriction occur, gdb/ecos/both?

Your code isn't really ROM - it's more of a flavour of ROMRAM
which is the most supportable kind of RedBoot to have.  Some [minor]
tweaks may be necessary to get this to work, but this is how I'd
approach it.

Look at ROMRAM mode - all this means is that the code *starts* by
executing some ROM code (which could really be "do nothing"), then
copies the image into RAM and continues executing there.  This is
pretty much how your code works - just some details need work.

Note: there are two reasons for differentiating between ROMRAM and
RAM startup types:
  * the need on some platforms to start in ROM and move the code
    and data to RAM before executing in RAM.  The code is linked
    at the RAM addresses and may need to  be tolerant of starting
    up with ROM addresses.
  * eCos programs can use the RAM model which allows for a build/link
    time stratification of memory resources.

Hopefully this helps - you should be able to get what you want done,
without any "heavy lifting" required :-)

- --
- ------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
- ------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFGQ5ZVmaKbSsQGV8ARAh+yAJsF8zUefbY+oSVd3bTkBBWsAggEswCfXtZF
l1jHm/qKuh4+i/6SmF4jyJw=
=RrJn
-----END PGP SIGNATURE-----

-- 
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] Chicken and the Egg: GDB, eCos, Virtual Vectors

[Kevin Wilson]

>>Your code isn't really ROM ... Look at ROMRAM mode ...

Sorry but this I know, and that I have done. The problem with romram is ecosconfig's requirement of a ROM designation in cyg_hal_startup to include the gdb_thread_support package in redboot. If you look at the dependencies you'll see that anything other than a ROM startup takes debug thread support out of the redboot build. Just to be certain, I tested a redboot built using romram mode and it doesn't solve any of the issues in my original post.

This leads us back to my original inquiry, will making a ROM redboot build solve the break/step/continue problem without having to implement asynchronous
debugger interrupts and hooks for accessing kernel thread information right away? Also, if someone could point me to the async debug interrupts and kernel thread hooks in the powerpc/cogent reference implementation I would be most thankful. 

Thanks,

Kevin

-----Original Message-----
From: Gary Thomas [mailto:gary@mlbassoc.com]
Sent: Thursday, May 10, 2007 17:02
To: Kevin Wilson
Cc: Ecos-Discuss (E-mail)
Subject: Re: [ECOS] Chicken and the Egg: GDB, eCos, Virtual Vectors

Your code isn't really ROM - it's more of a flavour of ROMRAM
which is the most supportable kind of RedBoot to have.  Some [minor]
tweaks may be necessary to get this to work, but this is how I'd
approach it.

Look at ROMRAM mode - all this means is that the code *starts* by
executing some ROM code (which could really be "do nothing"), then
copies the image into RAM and continues executing there.  This is
pretty much how your code works - just some details need work.

Note: there are two reasons for differentiating between ROMRAM and
RAM startup types:
  * the need on some platforms to start in ROM and move the code
    and data to RAM before executing in RAM.  The code is linked
    at the RAM addresses and may need to  be tolerant of starting
    up with ROM addresses.
  * eCos programs can use the RAM model which allows for a build/link
    time stratification of memory resources.

Hopefully this helps - you should be able to get what you want done,
without any "heavy lifting" required :-)

- --
- ------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
- ------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFGQ5ZVmaKbSsQGV8ARAh+yAJsF8zUefbY+oSVd3bTkBBWsAggEswCfXtZF
l1jHm/qKuh4+i/6SmF4jyJw=
=RrJn
-----END PGP SIGNATURE-----


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kevin Wilson wrote:
> I have scoured the docs and sources, tried multiple (some illegal)
> configurations just to see if I could circumvent the rom requirement of
> CYG_HAL_STARTUP to fit our ram model, but alas I have come to realize I
> must bow to the ecos gurus and seek confirmation of my assumptions and
> some guidance. I am going to error on the side of including more
> information rather than less so no questions are left unanswered.
> 
> [Our Setup]
> Our platform is a RAM only model ARM target. Redboot, obviously, is
> built with our hal package included. The inclusion prevents us from
> building a redboot with startup type = ROM. (A ROMRAM build doesn't get
> the job done either)
> 
> 1) Board bringup:
> 	a) a small startup binary at rom address 0 copies redboot
> 	   from rom into ram, starts redboot and swaps memory
> 	   locations so that ram is at ram address 0. Redboot is
> 	   loaded in the upper end of ram with applications loaded
> 	   at ram address 0.
> 
> This model allows redboot to update itself (image stored in rom). It
> requires flash programming utils which prevents CYG_HAL_STARTUP == ROM.
> 
> What gdb can do with a ram model, both redboot and application.
> 
> 1) Attach to remote target and load application.
> 2) Set Breakpoints:
> 	a) Non-threaded code allows stepping but pukes
> 	   on a subsequent continue.
> 	   (e.g. break at cyg_user_start, step step, continue, puke)
> 	b) Breaks inside threaded functions will allow inspection
> 	   of variables, etc. but not stepping. Continue, again,
> 	   is not possible.
> 
> What gdb cannot do in a ram model is:
> 
> 1) Continue from any point in code.
> 2) Single step inside threads.
> 3) Show thread information.
> 
> [Virtual Vectors]
> Our app does have the virtual Vector (VV) mechanism in place but it
> appears to be useless/limited because we must still use a redboot that
> runs from rom, is that correct?
> 
> Also, the VV doc states that we must implement our own asynchronous
> debugger interrupts (ASI) and hooks for accessing kernel thread
> information (KTI). The docs also states to look in the powerpc/cogent
> code to find a reference implementation of VVs. I could not find the
> specific code that handles the ASI & KTI calls. Could someone point to
> where I might find those code blocks?
> 
> 
> Now my main question is if I redo our model so redboot can run from rom
> with our app still in ram will that solve the stepping and continuing
> problem without implementing ASI or KTI right away? I am also curious as
> to why a ram loaded redboot cannot be made to utilize full debugging
> capabilities so developers can easily update and debug their ram
> targets. Where does the restriction occur, gdb/ecos/both?


--
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] Chicken and the Egg: GDB, eCos, Virtual Vectors

[Gary Thomas]

Kevin Wilson wrote:
>>> Your code isn't really ROM ... Look at ROMRAM mode ...
> 
> Sorry but this I know, and that I have done. The problem with romram is ecosconfig's requirement of a ROM designation in cyg_hal_startup to include the gdb_thread_support package in redboot. If you look at the dependencies you'll see that anything other than a ROM startup takes debug thread support out of the redboot build. Just to be certain, I tested a redboot built using romram mode and it doesn't solve any of the issues in my original post.

What constraint are you referring to (which CDL item, which file, etc)?
I don't see such a thing; only that in order to support GDB, the "program"
(i.e. RedBoot) must not set CYGSEM_HAL_USE_ROM_MONITOR.

> This leads us back to my original inquiry, will making a ROM redboot build solve the break/step/continue problem without having to implement asynchronous
> debugger interrupts and hooks for accessing kernel thread information right away? Also, if someone could point me to the async debug interrupts and kernel thread hooks in the powerpc/cogent reference implementation I would be most thankful. 

Such support requires very little help from the HAL, mostly
just getting things configured correctly.

I would *not* refer to the PowerPC/cogent HAL - it's *way* too
old and hasn't been maintained for many years.  Look at a more
modern platform.  The myriad ARM targets are mostly newer and
up to date and do implement the functions you are interested in.

Asynchronous interrupts are handled by the diagnostic I/O functions.
Look at .../hal/arm/xscale/pxa2x0/current/src/hal_diag.c to see how
they work for an ARM platform.

> -----Original Message-----
> From: Gary Thomas [mailto:gary@mlbassoc.com]
> Sent: Thursday, May 10, 2007 17:02
> To: Kevin Wilson
> Cc: Ecos-Discuss (E-mail)
> Subject: Re: [ECOS] Chicken and the Egg: GDB, eCos, Virtual Vectors
> 
> Your code isn't really ROM - it's more of a flavour of ROMRAM
> which is the most supportable kind of RedBoot to have.  Some [minor]
> tweaks may be necessary to get this to work, but this is how I'd
> approach it.
> 
> Look at ROMRAM mode - all this means is that the code *starts* by
> executing some ROM code (which could really be "do nothing"), then
> copies the image into RAM and continues executing there.  This is
> pretty much how your code works - just some details need work.
> 
> Note: there are two reasons for differentiating between ROMRAM and
> RAM startup types:
>   * the need on some platforms to start in ROM and move the code
>     and data to RAM before executing in RAM.  The code is linked
>     at the RAM addresses and may need to  be tolerant of starting
>     up with ROM addresses.
>   * eCos programs can use the RAM model which allows for a build/link
>     time stratification of memory resources.
> 
> Hopefully this helps - you should be able to get what you want done,
> without any "heavy lifting" required :-)
> 
> - --
> - ------------------------------------------------------------
> Gary Thomas                 |  Consulting for the
> MLB Associates              |    Embedded world
> - ------------------------------------------------------------
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> 
> iD8DBQFGQ5ZVmaKbSsQGV8ARAh+yAJsF8zUefbY+oSVd3bTkBBWsAggEswCfXtZF
> l1jHm/qKuh4+i/6SmF4jyJw=
> =RrJn
> -----END PGP SIGNATURE-----
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Kevin Wilson wrote:
>> I have scoured the docs and sources, tried multiple (some illegal)
>> configurations just to see if I could circumvent the rom requirement of
>> CYG_HAL_STARTUP to fit our ram model, but alas I have come to realize I
>> must bow to the ecos gurus and seek confirmation of my assumptions and
>> some guidance. I am going to error on the side of including more
>> information rather than less so no questions are left unanswered.
>>
>> [Our Setup]
>> Our platform is a RAM only model ARM target. Redboot, obviously, is
>> built with our hal package included. The inclusion prevents us from
>> building a redboot with startup type = ROM. (A ROMRAM build doesn't get
>> the job done either)
>>
>> 1) Board bringup:
>> 	a) a small startup binary at rom address 0 copies redboot
>> 	   from rom into ram, starts redboot and swaps memory
>> 	   locations so that ram is at ram address 0. Redboot is
>> 	   loaded in the upper end of ram with applications loaded
>> 	   at ram address 0.
>>
>> This model allows redboot to update itself (image stored in rom). It
>> requires flash programming utils which prevents CYG_HAL_STARTUP == ROM.
>>
>> What gdb can do with a ram model, both redboot and application.
>>
>> 1) Attach to remote target and load application.
>> 2) Set Breakpoints:
>> 	a) Non-threaded code allows stepping but pukes
>> 	   on a subsequent continue.
>> 	   (e.g. break at cyg_user_start, step step, continue, puke)
>> 	b) Breaks inside threaded functions will allow inspection
>> 	   of variables, etc. but not stepping. Continue, again,
>> 	   is not possible.
>>
>> What gdb cannot do in a ram model is:
>>
>> 1) Continue from any point in code.
>> 2) Single step inside threads.
>> 3) Show thread information.
>>
>> [Virtual Vectors]
>> Our app does have the virtual Vector (VV) mechanism in place but it
>> appears to be useless/limited because we must still use a redboot that
>> runs from rom, is that correct?
>>
>> Also, the VV doc states that we must implement our own asynchronous
>> debugger interrupts (ASI) and hooks for accessing kernel thread
>> information (KTI). The docs also states to look in the powerpc/cogent
>> code to find a reference implementation of VVs. I could not find the
>> specific code that handles the ASI & KTI calls. Could someone point to
>> where I might find those code blocks?
>>
>>
>> Now my main question is if I redo our model so redboot can run from rom
>> with our app still in ram will that solve the stepping and continuing
>> problem without implementing ASI or KTI right away? I am also curious as
>> to why a ram loaded redboot cannot be made to utilize full debugging
>> capabilities so developers can easily update and debug their ram
>> targets. Where does the restriction occur, gdb/ecos/both?
> 
> 


-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

-- 
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] Chicken and the Egg: GDB, eCos, Virtual Vectors

[Gary Thomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Please keep replies on the eCos mailing list so that all may benefit.
Full support, including private email support, is available with a contract.

Kevin Wilson wrote:
>>> What constraint ...
> 
> This is what I found. Sorry it took me a while to relocate where I had
> found this in my ecos tree expeditions. The redboot cdl (below) shows it
> requires this option. Now is this a bogus statement from the docs? I
> will try building another romram image and continue down that path as
> you suggest. I'll also look at the newer xscale pkg for the virtual
> vector stuff. Thanks for the pointers, I appreciate it.
> 
>From /hal/common/current/doc/porting.sgml
> 
> cdl_option CYGSEM_HAL_ROM_MONITOR {
>     display       "Behave as a ROM monitor"
>     flavor        bool
>     default_value 0
>     parent        CYGPKG_HAL_ROM_MONITOR
>     requires      { CYG_HAL_STARTUP == "ROM" }
>     description   "
>         Enable this option if this program is to be used as a ROM monitor,
>         i.e. applications will be loaded into RAM on the board, and this
>         ROM monitor may process exceptions or interrupts generated from the
>         application. This enables features such as utilizing a separate
>         interrupt stack when exceptions are generated."
> }
> 
> The redboot cdl shows it depends on the above option:
> 
> cdl_option CYGPRI_REDBOOT_ROM_MONITOR {
>             display      "Behave like a ROM monitor"
>             active_if    { CYG_HAL_STARTUP == "ROM" || CYG_HAL_STARTUP
> == "ROMRAM" }
>             requires     CYGSEM_HAL_ROM_MONITOR
>             calculated   1
>             no_define
>             description  "
>               Enabling this option will allow RedBoot to provide ROM
> monitor-style
>               services to programs which it executes."
>         }
> 

If you look carefully, you'll see that it's up to the platform HAL to
define this.  For example, in .../hal/arm/xscale/uE250/current/cdl/hal_arm_xscale_uE250.cdl
    cdl_option CYGSEM_HAL_ROM_MONITOR {
        display       "Behave as a ROM monitor"
        flavor        bool
        default_value 0
        parent        CYGPKG_HAL_ROM_MONITOR
        requires      { CYG_HAL_STARTUP == "ROM" || CYG_HAL_STARTUP == "ROMRAM" }
        description   "
            Enable this option if this program is to be used as a ROM monitor,
            i.e. applications will be loaded into RAM on the board, and this
            ROM monitor may process exceptions or interrupts generated from the
            application. This enables features such as utilizing a separate
            interrupt stack when exceptions are generated."
    }

Once this is enabled in the platform HAL, the rest of the mechanism
falls into place (provided by hal/common).  As I said earlier, you
will need to make sure all of the interrupt support is in place in
your diagnostic (serial) I/O functions.  Also, there are other CDL
options which can be enabled for thread debugging, etc.

> 
> Gary Thomas wrote:
>> Kevin Wilson wrote:
>>>>> Your code isn't really ROM ... Look at ROMRAM mode ...
>>> Sorry but this I know, and that I have done. The problem with romram is ecosconfig's requirement of a ROM designation in cyg_hal_startup to include the gdb_thread_support package in redboot. If you look at the dependencies you'll see that anything other than a ROM startup takes debug thread support out of the redboot build. Just to be certain, I tested a redboot built using romram mode and it doesn't solve any of the issues in my original post.
>> What constraint are you referring to (which CDL item, which file, etc)?
>> I don't see such a thing; only that in order to support GDB, the "program"
>> (i.e. RedBoot) must not set CYGSEM_HAL_USE_ROM_MONITOR.
>>
>>> This leads us back to my original inquiry, will making a ROM redboot build solve the break/step/continue problem without having to implement asynchronous
>>> debugger interrupts and hooks for accessing kernel thread information right away? Also, if someone could point me to the async debug interrupts and kernel thread hooks in the powerpc/cogent reference implementation I would be most thankful. 
>> Such support requires very little help from the HAL, mostly
>> just getting things configured correctly.
>>
>> I would *not* refer to the PowerPC/cogent HAL - it's *way* too
>> old and hasn't been maintained for many years.  Look at a more
>> modern platform.  The myriad ARM targets are mostly newer and
>> up to date and do implement the functions you are interested in.
>>
>> Asynchronous interrupts are handled by the diagnostic I/O functions.
>> Look at .../hal/arm/xscale/pxa2x0/current/src/hal_diag.c to see how
>> they work for an ARM platform.
>>
>>> -----Original Message-----
>>> From: Gary Thomas [mailto:gary@mlbassoc.com]
>>> Sent: Thursday, May 10, 2007 17:02
>>> To: Kevin Wilson
>>> Cc: Ecos-Discuss (E-mail)
>>> Subject: Re: [ECOS] Chicken and the Egg: GDB, eCos, Virtual Vectors
>>>
>>> Your code isn't really ROM - it's more of a flavour of ROMRAM
>>> which is the most supportable kind of RedBoot to have.  Some [minor]
>>> tweaks may be necessary to get this to work, but this is how I'd
>>> approach it.
>>>
>>> Look at ROMRAM mode - all this means is that the code *starts* by
>>> executing some ROM code (which could really be "do nothing"), then
>>> copies the image into RAM and continues executing there.  This is
>>> pretty much how your code works - just some details need work.
>>>
>>> Note: there are two reasons for differentiating between ROMRAM and
>>> RAM startup types:
>>>   * the need on some platforms to start in ROM and move the code
>>>     and data to RAM before executing in RAM.  The code is linked
>>>     at the RAM addresses and may need to  be tolerant of starting
>>>     up with ROM addresses.
>>>   * eCos programs can use the RAM model which allows for a build/link
>>>     time stratification of memory resources.
>>>
>>> Hopefully this helps - you should be able to get what you want done,
>>> without any "heavy lifting" required :-)
>>>
>>> Kevin Wilson wrote:
>>>> I have scoured the docs and sources, tried multiple (some illegal)
>>>> configurations just to see if I could circumvent the rom requirement of
>>>> CYG_HAL_STARTUP to fit our ram model, but alas I have come to realize I
>>>> must bow to the ecos gurus and seek confirmation of my assumptions and
>>>> some guidance. I am going to error on the side of including more
>>>> information rather than less so no questions are left unanswered.
>>>>
>>>> [Our Setup]
>>>> Our platform is a RAM only model ARM target. Redboot, obviously, is
>>>> built with our hal package included. The inclusion prevents us from
>>>> building a redboot with startup type = ROM. (A ROMRAM build doesn't get
>>>> the job done either)
>>>>
>>>> 1) Board bringup:
>>>> 	a) a small startup binary at rom address 0 copies redboot
>>>> 	   from rom into ram, starts redboot and swaps memory
>>>> 	   locations so that ram is at ram address 0. Redboot is
>>>> 	   loaded in the upper end of ram with applications loaded
>>>> 	   at ram address 0.
>>>>
>>>> This model allows redboot to update itself (image stored in rom). It
>>>> requires flash programming utils which prevents CYG_HAL_STARTUP == ROM.
>>>>
>>>> What gdb can do with a ram model, both redboot and application.
>>>>
>>>> 1) Attach to remote target and load application.
>>>> 2) Set Breakpoints:
>>>> 	a) Non-threaded code allows stepping but pukes
>>>> 	   on a subsequent continue.
>>>> 	   (e.g. break at cyg_user_start, step step, continue, puke)
>>>> 	b) Breaks inside threaded functions will allow inspection
>>>> 	   of variables, etc. but not stepping. Continue, again,
>>>> 	   is not possible.
>>>>
>>>> What gdb cannot do in a ram model is:
>>>>
>>>> 1) Continue from any point in code.
>>>> 2) Single step inside threads.
>>>> 3) Show thread information.
>>>>
>>>> [Virtual Vectors]
>>>> Our app does have the virtual Vector (VV) mechanism in place but it
>>>> appears to be useless/limited because we must still use a redboot that
>>>> runs from rom, is that correct?
>>>>
>>>> Also, the VV doc states that we must implement our own asynchronous
>>>> debugger interrupts (ASI) and hooks for accessing kernel thread
>>>> information (KTI). The docs also states to look in the powerpc/cogent
>>>> code to find a reference implementation of VVs. I could not find the
>>>> specific code that handles the ASI & KTI calls. Could someone point to
>>>> where I might find those code blocks?
>>>>
>>>>
>>>> Now my main question is if I redo our model so redboot can run from rom
>>>> with our app still in ram will that solve the stepping and continuing
>>>> problem without implementing ASI or KTI right away? I am also curious as
>>>> to why a ram loaded redboot cannot be made to utilize full debugging
>>>> capabilities so developers can easily update and debug their ram
>>>> targets. Where does the restriction occur, gdb/ecos/both?
>>


- --
- ------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
- ------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFGRKqpmaKbSsQGV8ARAsZpAJ9dlVHJC6yfgQXAIoz4nxQQ7ua7cgCfbSas
FACgkltRShTNfRV/Yo+/mUk=
=SCTD
-----END PGP SIGNATURE-----

-- 
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] Chicken and the Egg: GDB, eCos, Virtual Vectors

[Kevin Wilson]

>>Please keep replies on ..

Yep Yep, just forgot to reply all and fix the email addys.

>>...is available with a contract.

That is not necessary, this list will do nicely. 

I believe my latest test builds have demonstrated that romram mode does not allow stepping inside threads nor any level of continuation when debugging over serial conn, at least not with our current hal_diag implementation. Maybe our hal_diag needs some tweaks as it was not built with gdb in mind. 

Will visit the xscale ref you gave for virtual vectors, thanks.

-----Original Message-----
From: Gary Thomas [mailto:gary@mlbassoc.com]
Sent: Friday, May 11, 2007 12:41
To: Kevin Wilson
Cc: eCos Discussion
Subject: Re: [ECOS] Chicken and the Egg: GDB, eCos, Virtual Vectors


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Please keep replies on the eCos mailing list so that all may benefit.
Full support, including private email support, is available with a contract.

Kevin Wilson wrote:
>>> What constraint ...
> 
> This is what I found. Sorry it took me a while to relocate where I had
> found this in my ecos tree expeditions. The redboot cdl (below) shows it
> requires this option. Now is this a bogus statement from the docs? I
> will try building another romram image and continue down that path as
> you suggest. I'll also look at the newer xscale pkg for the virtual
> vector stuff. Thanks for the pointers, I appreciate it.
> 
>From /hal/common/current/doc/porting.sgml
> 
> cdl_option CYGSEM_HAL_ROM_MONITOR {
>     display       "Behave as a ROM monitor"
>     flavor        bool
>     default_value 0
>     parent        CYGPKG_HAL_ROM_MONITOR
>     requires      { CYG_HAL_STARTUP == "ROM" }
>     description   "
>         Enable this option if this program is to be used as a ROM monitor,
>         i.e. applications will be loaded into RAM on the board, and this
>         ROM monitor may process exceptions or interrupts generated from the
>         application. This enables features such as utilizing a separate
>         interrupt stack when exceptions are generated."
> }
> 
> The redboot cdl shows it depends on the above option:
> 
> cdl_option CYGPRI_REDBOOT_ROM_MONITOR {
>             display      "Behave like a ROM monitor"
>             active_if    { CYG_HAL_STARTUP == "ROM" || CYG_HAL_STARTUP
> == "ROMRAM" }
>             requires     CYGSEM_HAL_ROM_MONITOR
>             calculated   1
>             no_define
>             description  "
>               Enabling this option will allow RedBoot to provide ROM
> monitor-style
>               services to programs which it executes."
>         }
> 

If you look carefully, you'll see that it's up to the platform HAL to
define this.  For example, in .../hal/arm/xscale/uE250/current/cdl/hal_arm_xscale_uE250.cdl
    cdl_option CYGSEM_HAL_ROM_MONITOR {
        display       "Behave as a ROM monitor"
        flavor        bool
        default_value 0
        parent        CYGPKG_HAL_ROM_MONITOR
        requires      { CYG_HAL_STARTUP == "ROM" || CYG_HAL_STARTUP == "ROMRAM" }
        description   "
            Enable this option if this program is to be used as a ROM monitor,
            i.e. applications will be loaded into RAM on the board, and this
            ROM monitor may process exceptions or interrupts generated from the
            application. This enables features such as utilizing a separate
            interrupt stack when exceptions are generated."
    }

Once this is enabled in the platform HAL, the rest of the mechanism
falls into place (provided by hal/common).  As I said earlier, you
will need to make sure all of the interrupt support is in place in
your diagnostic (serial) I/O functions.  Also, there are other CDL
options which can be enabled for thread debugging, etc.

> 
> Gary Thomas wrote:
>> Kevin Wilson wrote:
>>>>> Your code isn't really ROM ... Look at ROMRAM mode ...
>>> Sorry but this I know, and that I have done. The problem with romram is ecosconfig's requirement of a ROM designation in cyg_hal_startup to include the gdb_thread_support package in redboot. If you look at the dependencies you'll see that anything other than a ROM startup takes debug thread support out of the redboot build. Just to be certain, I tested a redboot built using romram mode and it doesn't solve any of the issues in my original post.
>> What constraint are you referring to (which CDL item, which file, etc)?
>> I don't see such a thing; only that in order to support GDB, the "program"
>> (i.e. RedBoot) must not set CYGSEM_HAL_USE_ROM_MONITOR.
>>
>>> This leads us back to my original inquiry, will making a ROM redboot build solve the break/step/continue problem without having to implement asynchronous
>>> debugger interrupts and hooks for accessing kernel thread information right away? Also, if someone could point me to the async debug interrupts and kernel thread hooks in the powerpc/cogent reference implementation I would be most thankful. 
>> Such support requires very little help from the HAL, mostly
>> just getting things configured correctly.
>>
>> I would *not* refer to the PowerPC/cogent HAL - it's *way* too
>> old and hasn't been maintained for many years.  Look at a more
>> modern platform.  The myriad ARM targets are mostly newer and
>> up to date and do implement the functions you are interested in.
>>
>> Asynchronous interrupts are handled by the diagnostic I/O functions.
>> Look at .../hal/arm/xscale/pxa2x0/current/src/hal_diag.c to see how
>> they work for an ARM platform.
>>
>>> -----Original Message-----
>>> From: Gary Thomas [mailto:gary@mlbassoc.com]
>>> Sent: Thursday, May 10, 2007 17:02
>>> To: Kevin Wilson
>>> Cc: Ecos-Discuss (E-mail)
>>> Subject: Re: [ECOS] Chicken and the Egg: GDB, eCos, Virtual Vectors
>>>
>>> Your code isn't really ROM - it's more of a flavour of ROMRAM
>>> which is the most supportable kind of RedBoot to have.  Some [minor]
>>> tweaks may be necessary to get this to work, but this is how I'd
>>> approach it.
>>>
>>> Look at ROMRAM mode - all this means is that the code *starts* by
>>> executing some ROM code (which could really be "do nothing"), then
>>> copies the image into RAM and continues executing there.  This is
>>> pretty much how your code works - just some details need work.
>>>
>>> Note: there are two reasons for differentiating between ROMRAM and
>>> RAM startup types:
>>>   * the need on some platforms to start in ROM and move the code
>>>     and data to RAM before executing in RAM.  The code is linked
>>>     at the RAM addresses and may need to  be tolerant of starting
>>>     up with ROM addresses.
>>>   * eCos programs can use the RAM model which allows for a build/link
>>>     time stratification of memory resources.
>>>
>>> Hopefully this helps - you should be able to get what you want done,
>>> without any "heavy lifting" required :-)
>>>
>>> Kevin Wilson wrote:
>>>> I have scoured the docs and sources, tried multiple (some illegal)
>>>> configurations just to see if I could circumvent the rom requirement of
>>>> CYG_HAL_STARTUP to fit our ram model, but alas I have come to realize I
>>>> must bow to the ecos gurus and seek confirmation of my assumptions and
>>>> some guidance. I am going to error on the side of including more
>>>> information rather than less so no questions are left unanswered.
>>>>
>>>> [Our Setup]
>>>> Our platform is a RAM only model ARM target. Redboot, obviously, is
>>>> built with our hal package included. The inclusion prevents us from
>>>> building a redboot with startup type = ROM. (A ROMRAM build doesn't get
>>>> the job done either)
>>>>
>>>> 1) Board bringup:
>>>> 	a) a small startup binary at rom address 0 copies redboot
>>>> 	   from rom into ram, starts redboot and swaps memory
>>>> 	   locations so that ram is at ram address 0. Redboot is
>>>> 	   loaded in the upper end of ram with applications loaded
>>>> 	   at ram address 0.
>>>>
>>>> This model allows redboot to update itself (image stored in rom). It
>>>> requires flash programming utils which prevents CYG_HAL_STARTUP == ROM.
>>>>
>>>> What gdb can do with a ram model, both redboot and application.
>>>>
>>>> 1) Attach to remote target and load application.
>>>> 2) Set Breakpoints:
>>>> 	a) Non-threaded code allows stepping but pukes
>>>> 	   on a subsequent continue.
>>>> 	   (e.g. break at cyg_user_start, step step, continue, puke)
>>>> 	b) Breaks inside threaded functions will allow inspection
>>>> 	   of variables, etc. but not stepping. Continue, again,
>>>> 	   is not possible.
>>>>
>>>> What gdb cannot do in a ram model is:
>>>>
>>>> 1) Continue from any point in code.
>>>> 2) Single step inside threads.
>>>> 3) Show thread information.
>>>>
>>>> [Virtual Vectors]
>>>> Our app does have the virtual Vector (VV) mechanism in place but it
>>>> appears to be useless/limited because we must still use a redboot that
>>>> runs from rom, is that correct?
>>>>
>>>> Also, the VV doc states that we must implement our own asynchronous
>>>> debugger interrupts (ASI) and hooks for accessing kernel thread
>>>> information (KTI). The docs also states to look in the powerpc/cogent
>>>> code to find a reference implementation of VVs. I could not find the
>>>> specific code that handles the ASI & KTI calls. Could someone point to
>>>> where I might find those code blocks?
>>>>
>>>>
>>>> Now my main question is if I redo our model so redboot can run from rom
>>>> with our app still in ram will that solve the stepping and continuing
>>>> problem without implementing ASI or KTI right away? I am also curious as
>>>> to why a ram loaded redboot cannot be made to utilize full debugging
>>>> capabilities so developers can easily update and debug their ram
>>>> targets. Where does the restriction occur, gdb/ecos/both?
>>


- --
- ------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
- ------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFGRKqpmaKbSsQGV8ARAsZpAJ9dlVHJC6yfgQXAIoz4nxQQ7ua7cgCfbSas
FACgkltRShTNfRV/Yo+/mUk=
=SCTD
-----END PGP SIGNATURE-----

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