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


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


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