GDB Stubs for PowerPC BSP with old-exceptions

Tue Feb 20 17:57:26 UTC 2007

Hi Thomas,

Well, I have a BSP called virtex, that borrowed heavily from Greg Menke
and Keith Robertson.  It seems to work, but there are some warts:

  1. I have a bug or two in the automake stuff.  I don't really
understand this system well enough, so I've been using a workaround
involving copying the files from the "wrong" place to the "right"
place.  So this means the BSP isn't really ready to be included in the
distribution.  However, it is probably good enough for you to play with,
if you want.

  2. I wanted to use the hard TEMAC supplied by Xilinx, but I wasn't
really interested in reimplementing their drivers; they seem to work
fine, and I don't have the time or desire to redo them.  So my BSP links
with the Xilinx libraries for the TEMAC drivers, and other peripherals I
need that are outside of the BSP.  Right now, though, I do use the
interrupt controller drivers from Greg/Keith.  I realize this requires
the Xilinx EDK in order to use this BSP, as the Xilinx drivers can not
be included in the RTEMS tree because of licensing issues.  I feel this
is not a problem, as I would guess most people using the Virtex FPGAs
will get the EDK anyways.  Xilinx claims you need it to develop PowerPC
applications; I'm not sure if that's 100% true, but it is clear that
it's a heck of a lot easier with the EDK than it would be without it!!!

  3. Currently, I am using the interrupt-driven FIFO mode for the TEMAC;
this uses about half of the FPGA resources (e.g. slices, flip-flops,
LUTs, etc.). as the scatter-gather DMA implementation does.  For my
application, I was thinking that was "good enough", and the smaller
footprint might make the BSP of interest to more people, especially
those using the ml403 eval board.  However, my boards have the FX60
FPGA, so I could certainly implement the bigger, faster SGDMA design. 
(FYI - my hardware guy used the FX60 because it was more available than
smaller options, not because we needed that much logic (or the second
PowerPC!)  I would like to support either option in the BSP, but I'm not
sure how best to do that.  For those unaware of the specifics, the TEMAC
can utilize FIFOs or DMA, but the choice is an FPGA-configuration-time
choice; once you decide in the hardware, your software must use the same
mode.

  4. The previous point hints at a bigger issue that should be resolved
- that is, how to handle the variability in the FPGA configurations
that, while similar enough in function that one might reasonably expect
the BSP to work with, still varies from my configuration in important
details.  For example, at what offset does the interrupt controller or
the serial port live.  I had problems with this when getting up to
speed.  The Xilinx tools generate a header file (xparameters.h) that
contains this sort of information, and gets us part of the way there,
but even that might not be enough.  For example, I don't like the
default names the tools use for peripherals, so the constants end up
with different names.  Another example is serial ports; if you have more
than one, how does the BSP know which one is to be the console port? 
I'm thinking some sort of configuration file is the answer, but I'm not
sure where to put it in the hierarchy.  This gets particularly tricky
when you consider the official RTEMS tree vs. any user's source control
choices.  I'm using Subversion (subversion.tigris.org) and a "vendor
drop" approach, which makes it easy for me to deal with this, but I
would not want to force others to do the same. 

5.  Oh, yeah, then there is the "new exception model" stuff...

So, I'm not sure if you're still interested...  If so, let me know.  I'd
be happy to send you what I've got.  I certainly would welcome feedback
from others, especially more knowledgeable folks such as yourself!

Take care,
-Bob

Thomas Doerfler wrote:
> Hello Robert, hello Till,
>
> Sorry that I enter the discussion so late.
>
> I fully agree with Tills recommendations, including his request to use
> the shared/vectors sources. There is one thing special with the PPC4xx
> family concerning the exception handling: PPC4xx (and the new Book E
> PowerPCs) have the concept of "critical interrupts", which is not
> available in the other PPC derivates. This will need some special
> handling, but it is a good idea to add it to the shared code, because it
> will be useful for future PPC implementations aswell.
>
> Robert, in the past I have adapted the PPC403 BSP (helas403), but due to
> my lack of debugging facilities and current hardware, I could not
> support the transition to the new exception handling for PPC4xx.
>
> If I can be of any help to support you with the transition, please let
> me know.
>
>
> I have access to a Xilinx Eva Board and the corresponding development
> software, so I might even try things out here when the BSP is ripe
> enough to be tested.
>
> wkr,
> Thomas Doerfler.
>
>
>
> Robert S. Grimes schrieb:
>   
>> Hi Till,
>>
>> Sorry for the delay, but you just missed me before a weekend away from work!
>>
>> Thanks, your comments should prove very useful; I think they're just
>> what I needed to guide me.
>>
>> Take care,
>> -Bob
>>
>> Till Straumann wrote:
>>     
>>> Robert S. Grimes wrote:
>>>       
>>>> Hi Till,
>>>>
>>>> Thanks for the response.  Perhaps you misunderstood me, but I
>>>> certainly wasn't expecting you to support an old standard!  I was
>>>> envisioning me doing the work, either way...Anyway, Joel has
>>>> suggested I do the same, for similar reasons.  Given that I've always
>>>> felt the new model would be better, it seems I've enough good reasons
>>>> for changing what already works.  Only problem is that I don't have
>>>> any information about the differences between old and new.
>>>> Do you or anyone else know where I should look?
>>>>         
>>> Dunno other than in the obvious places (relevant new/old source
>>> directories)
>>> and in a BSP that uses 'new'.
>>>
>>> Ideally, you can just use code from the 'vectors' subdirectory of the
>>> 'powerpc/shared' directory (look at the 'psim' BSP). This works
>>> for the 60x/750/74xx CPUs. I don't know if you would need modifications
>>> for the 405 - I'm not familiar with that one.
>>>
>>> In any case *do not* copy from powerpc/shared/vectors and create
>>> a modified version in your 'vectors' subdirectory. This has been very
>>> bad practice in the past and lead to a bunch of hard to maintain
>>> variants of code. Due to the low-level nature of exception handling
>>> there has to be assembly code. We don't want a jungle of variants
>>> of this code. Don't do it. Please.
>>>
>>> If you have to deviate from the 'shared' implementation then think
>>> about adding run-time tests or (if you have to) compile-time conditionals
>>> (#ifdef) to the 'shared' implementation so that only a single
>>> implementation needs to be maintained.
>>>
>>> Your Makefile then uses the code from the 'shared' area (ugly, I know;
>>> there should really be a library)
>>>
>>> HTH
>>> -- Till
>>>       
>>>> Or at the very least, suggest one or two good example PowerPC BSPs
>>>> that implement the new exception model?
>>>>
>>>> Thanks!
>>>> -Bob
>>>>         
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users at rtems.com
>> http://rtems.rtems.org/mailman/listinfo/rtems-users
>>     
>
>
>   