[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Xilinx IP core drivers for RTEMS- Keith Robertson still around?
- Date: Tue, 18 Jul 2006 12:21:56 -0400
- From: rsg at alum.mit.edu (Robert S. Grimes)
- Subject: Xilinx IP core drivers for RTEMS- Keith Robertson still around?
Yes, you and I had talked about this 'round then. Sorry I haven't keep
1. Xilinx took forever to deliver the ml403 - April, I think!!!
2. Other aspects of the "preliminary design" stage took priority.
3. I decided to see if I could get Ed Sutter's MicroMonitor to work
IIRC, you volunteered to help with the RTEMS side of things, if I could
handle the V4 side. I'm more capable now than I was then of doing my
end, and I should be able to devote more time now, and especially
starting in August. So, yes, I'd like to move this along.
AFAIK, Keith may have indeed done what I had also coincidentally done -
replace the full-fledged, extra dollar UART with the free lite version;
otherwise, it seems the same as what comes with the board. For my
project, we will have a custom board that is based heavily on the ml403,
but with more memory, a larger V4 chip, and different mix of
peripherals. What I have been doing is developing a platform using the
ml403, with the intent of porting it to the custom design when that
becomes available. In my travels through this crazy V4 land, it seems
the FPGA configuration is very flexible and powerful, but that makes it
pretty hard to develop a BSP for it; after all, even with the same
physical hardware, you can have a multitude of configurations, each of
which could look like a completely different "board"! I'm not saying
it's impossible, nor am I trying to lecture you ;-), but it seems we
have to somehow manage that aspect.
I just re-read your email, in particular the phrase:
"turns the gen405 BSP into a ml403 BSP"
I think that was certainly what Keith did, which made sense for him, I'm
sure. You sound like you'd like to make a new BSP - is that correct?
That sure seems to be the right way to do it, if we want this all to
eventually become part of the official distribution. Is this what you
have in mind?
Thomas Doerfler (nt) wrote:
> this really looks interesting. we were in contact with keith aroung
> chrismas but we drowned in our work right from the start of this year,
> so we lost contact again about the ml403 BSP.
> Can you (or Keith) provide a more detailed outline about the neccesary
> xilinx configuration?
> I have checked the patch you provided, it looks interesting, but it
> turns the gen405 BSP into a ml403 BSP, instead of defining a derivate.
> But I think it will not be SO difficult to devide things again so the
> BSP will support either a gen405 board 8whatever it is now) or a ml403.
> Thomas .
> Robert S. Grimes schrieb:
>> Hi Greg,
>> I'm in the same boat as you. Keith has sent me his diffs, which I
>> include here. Note that they are against a little older version
>> (V4.6.5) of RTEMS, and should work on a suitably configured Xilinx ml403
>> board. You'll have to make sure your V4 configuration is compatible
>> with his stuff, or change one side or another...
>> Be forewarned - things are much more tricky here in V4 land. Because of
>> the flexibility of the V4, you have many more variables. When I used
>> Keith's work, the simplest RTEMS application simply worked! However, in
>> looking at things afterwards, I realized how random that was...
>> I started with the Xilinx ml403 development/evaluation board. As
>> delivered, it is a pretty full-fledged configuration designed to show
>> off all the V4 and ml403 features. One thing I noticed early on is that
>> some of the IP used in that configuration, specifically the serial port
>> and the Ethernet MAC, would cost extra (iirc, $2K for the serial port,
>> and $5 for the MAC). I sure didn't feel like paying $2K for a console
>> port! Fortunately, the provide the uart lite component, so I did the
>> necessary substitution. Here is where the randomness kicks in - for
>> whatever reason, Keith had done the same, so lo and behold, things worked!
>> It gets more complicated, however. For me, I can't justify spending $5K
>> for a core that takes up 25% of the FPGA fabric, /especially when there
>> are two hard TEMACs on the darn chip to begin with/! (I'm still a bit
>> hot under the collar about how difficult getting the TEMAC up has been,
>> especially because one would reasonably had assumed that such a
>> highly-touted feature would have been demonstrated in an evaluation
>> board!!!) So I'll have to modify what Keith has done anyway to use the
>> Anyway, I've been off it for a little while, but will be picking up
>> steam again, especially after my design review on this project August
>> 1&2, so if interested, we can perhaps help each other a bit. Be
>> forewarned, I'm a novice with RTEMS, though I won't be for much longer...
>> Keith's stuff:
>> Attached is his diff against a clean 4.6.5 - here are his comments
>> Here's the diff's against a clean 4.6.5. I've had to manually edit
>> the output of my svn diff command to only get changes specific to
>> the gen405 drivers I've spoken about. I believe it should work though.
>> All changes are made available under the standard rtems license (ie
>> GPL plus rtems exception).
>> The main changes are the following:
>> Xilinx opb interrupt controller:
>> Xilinx uart lite driver:
>> Xilinx ethernet driver:
>> There are three other types of changes:
>> 1) Makefile.am changes to make the whole thing compile
>> 2) A few changes that were spoken about on the mailing list in July
>> (essentially bugs in the gen405 port AFAICT).
>> 3) Bsp startup / connection to driver files
>> (gen405/network/network.c, gen405/include/bsp.h)
>> gregory.menke at gsfc.nasa.gov wrote:
>>> This message is directed to Keith Robertson with regard to a message on
>>> the rtems mail list in Dec 2005 where he indicated he had some RTEMS
>>> code written to support Virtex-4 PPC hardware, specifically the
>>> interrupt controller, uart & ethernet. If possible, I'd like to get
>>> copies of the code since we have a high priority effort underway using
>>> those parts, and RTEMS is the OS.