[Bug 2020] Provide support for the PPC 440

Wed Feb 22 00:36:34 UTC 2012

https://www.rtems.org/bugzilla/show_bug.cgi?id=2020

--- Comment #11 from Ric Claus <claus at SLAC.Stanford.edu> 2012-02-21 18:36:34 CST ---
(In reply to comment #9)
> (In reply to comment #7)
> > Sorry to have caused so much upset.
> > 
> > The virtex BSP assumes certain firmware is loaded in the FPGA (e.g., console
> > and network support, at least).  I presume that was done on purpose and that it
> > is in active use, so I most certainly didn't intend to break it, nor to suggest
> > that it should be deprecated.
> 
> I don't think you broke it. The virtex, virtex4, and virtex5 BSPs all try to
> compile the same libcpu clock.c file. The patch file did not apply cleanly and
> I had to do my best working through the rejects to get where the file is now
> in git. I revisited this and virtex now compiles.
> 
> The other compilation issues appear to be 4.11 versus 4.10 issues. These may
> require a bit of attention. The others Sebastian pointed out a (e.g. asm.h 
> and start.S copyright) should be easy to address.
> 
> I believe the virtex BSP matched the configuration of some Xilinx board with
> their preconfigured FPGA load.
> 
> > My intent with the virtex4 BSP is to defer as much as possible any dependency
> > on the FPGA's firmware or external hardware to the application code, since this
> > fits with the usage of this chip in our project.
> 
> I think that's a good thing. My understanding is that the tool that generates
> the FPGA load also generates a device tree and .h file. Is that .h file put 
> somewhere in the bsp source and then you compile a tailored variant?

I'm not very familiar with Xilinx' tools (EDK, etc.), but for the case of their
app notes with prepackaged firmware that can be used with their Base System
Builder, yes, it does produce .h files, etc.  Since our project doesn't depend
on their prepackaged firmware, we don't get that luxury and have to create the
.h files ourselves based on the registers, etc., we put in the firmware.

Our build system is orthogonal to RTEMS' (and others'), so the .h files live in
our tree and not the RTEMS one.  We try as much as possible to treat RTEMS as a
separate entity.

> 
> >  I therefore "derived" this
> > BSP from various others, including virtex, and combined with example code from
> > Xilinx amd the Xilinx and IBM user guides, got to this result.  The code was
> > written by me, but probably shares some macro names and register usage with the
> > things I looked at to produce it.  If this constitutes copyright infringement,
> > then it's fine by me that the appropriate references are added if I didn't do a
> > good enough job of that already.
> 
> We are and have to be paranoid at hints that something has origins in something
> else independent of the license and copyright of the original code. Although at
> the end of the day, it could be a legal issue, I treat it as an academic issue.
> All we ask is to cite your references. FWIW I also worry about U.S. export
> issues. I do not want the RTEMS Project to unintentionally propagate something
> that causes issues.

Understood, and agreed wholeheartedly.  I tried to make it a point of citing my
refs.  Are you saying I missed some?

> 
> Unfortunately you used the word "derive" which does have a human as well as a
> legal meaning. You apparently meant it in the human sense to indicate that you
> didn't create this out of thin air but had an abundance of reference material
> and vendor provided source. Frequently register names and macros end up looking
> alike because everyone starts with the same vendor supplied headers, code,
> manuals and application notes.  I think that all you meant by "derived" is that
> you used reference material, and all is OK. But "derivative work" is a very
> specific term in copyright law.

Again, understood.  Our project is written in C++, so I have the term "derived
class" on my mind.  Consider the abundance of reference material as the logical
base class.

> 
> Did you start from virtex/start/dlentry.s? I can fix the verbiage to not raise
> concerns. :)

Well, it started more than a year ago and I no longer remember what came first.
 Certainly I copy-and-pasted a number of things from that file.

BTW, why's it called "dlentry"?  What is "dl"?  No where did I find an
explanation as to why this BSP diverges from the description in the manual. 
Ditto as to why there is a bsp_specs and bsp_specs.dl, linkcmds and
linkcmds.dl.

Fine with me if you fix the verbiage however you like.

> 
> > The comment with "RiC" in it was inadvertently left in.  It was meant to be a
> > "note to self" and I'm not sure whether there is a real issue there or not.
> 
> OK. I have removed that.
> 
> > I don't understand the comments about "git format-patch".  That's what I used,
> > as I thought would have been evident from the file names.  Did I use it
> > incorrectly?
> 
>  git format-patch --help
> 
> I must admit to not knowing much about it myself except that it can take a
> series of commits and place them separate files in a mailbox format. In 
> the git workflow, there are tools which make then easier to merge in this
> format.
> 
> > I didn't know about the macro rules.  I'd suggest reverting there usage to the
> > way things were to get clock.c and virtex to compile.  Then reenable my changes
> > by introducing whatever the proper macros are.  I don't know how 403s and e500s
> > compare to 405s and 440s, so I was reluctant to use existing macros for fear of
> > breaking things that depend on them.  Seems I did anyway.  Sorry to cause more
> > work.
> 
> I am not an expert on all these variations myself and that is why my hand merge
> of the rejects is happening.
> 
> I see that virtex4/include/irq.h and virtex5/include/irq.h not define any IRQ
> constants. I had to define a dummy BSP_PIT to virtex4 and BSP_DECREMENTER to
> virtex5 to get that BSP to compile.

I think that that those might be remnants of an incomplete port.  I haven't
gotten to doing anything with IRQ yet.  :-(

I wonder why I didn't need to define those macros...

> 
> At this point, all the virtex BSPs compile on the virtex branch in my personal
> repo.  Can you confirm they are complete and include what you intended?

Okay, I'll give it a shot.

> 
> Also did I miss adding a README file? Are there instructions on how to get from
> this code to a BSP matching your hardware?

No, I didn't provide one, sorry.  The idea is that it's not dependent on any
specific hardware.  Thus, once you've got it loaded into your hardware by hook
or crook (generally JTAG and xmd), you end up in the weakly referenced
__app_bsp_* functions.  There you can do the application specific things and
finish the board set-up, etc.  Is this sufficient, or is there some template to
follow?

> 
> Please don't take anything personal. This is all intended to be friendly and
> non-confrontational. Just wanting to get the right code into the right places
> with the right words.

-- 
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.