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


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


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