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:[EMAIL PROTECTED] > 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
