This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]