[Bug 2020] Provide support for the PPC 440

Tue Feb 21 23:01:23 UTC 2012

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

--- Comment #9 from Joel Sherrill <joel.sherrill at oarcorp.com> 2012-02-21 17:01:23 CST ---
(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 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.

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.

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

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

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?

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

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.