On Thu, 25 Aug 2005, Grant Likely wrote:

On Wed, Aug 24, 2005 at 08:20:48PM -0500, T Ziomek wrote:

quoted

Also, be aware that the differences between 'xparameters.h' and
'xparameters_ml300.h' are not all you need to worry about.

BTW, I took a approach different from MV's for 'xparameters.h'.  Seeing no
reason why that file *had* to be changed for Linux (and because the folks
doing the Xilinx hardware releases I use only use the 'standalone' BSP and
hence never run that Tcl script), I instead added a 'linux.xparameters.h'
file.  This file first includes 'xparameters.h' and then #defs all of the
Linux-specific stuff.
    Then I changed all Linux #includes of 'xparameters.h' to pull in my new
file instead.

My 'linux.xparameters.h' hasn't changed since I created it Feb. 2, though
I've worked with a dozen or more 'xparameters.h' files in that time.

IMO, this two files approach is better all-around, with better separation
of concerns and no Tcl script.

quoted

   Starting with MV's port to the ML300, you need to figure out which IP
versions it was created for (for example, "emac_v1_00_b").  Then you need
to compare that with the IP version used in your system [NOTE 1].  They'll
probably be different, so then you need to either merge MV's changes into
the newer Xilinx code or Xilinx's changes into the MV-modified drivers.
This leaves you with software drivers that match the IP and have the chang-
es needed to work in Linux.

Ah, yes.  I was wondering how much grief I would be dealing with in that
regard.  One of my goals is to get somewhat flexable drivers for basic
cores into mainline, so I'm sure I'll be fighting with this.

I keep wanting to implement a "2 files" approach like that above for the
driver files.  It's not as simple to do, and so far I keep enduring the
periodic hack session rather than investing time looking for a better solu-
tion.

Oh yeah, another minor type of change I had to deal with -- in cases where
a peripheral is on a different bus between the ML300 and our board I had to
make changes such as "OPB" -> "PLB".  No big deal there, though I wonder if
it should really be necessary.  Does Xilinx IP have significant bus-specific
differences (e.g. OPB EMAC vs. PLB EMAC)?  I wouldn't expect so...

quoted

   It also looks like the Xilinx software driver bugs that MV found were
not reported to Xilinx but just worked around, so those bugs are probably
still present in your design.  They were in ours...

Thank's for the heads up.  Your email addr's getting a permanent place
in my address book.  :)

:-(

Just kidding; I've been meaning for months now to put this stuff out on the
maillist (partly because I'm way overdue on "giving back" and partly to see
if I was missing some obvious Easy Way).

quoted

NOTE 1:  And don't depend on Xilinx's rev numbers changing when their dri-
         ver code does.  I regularly run across situations where consecu-
         tive FPGA designs both use, say, the "gpio_v2_00_a" IP and driver
         yet the driver code has changed.  It is important that you 'diff'
         or whatever all of the driver code for changes each time you re-
         ceive a new FPGA design generated from an XPS with *any* changes
         at all (new version, patches, etc.), even if it appears that the
         patch should not affect any driver code.

Hmm, lovely.

Don't get me started...

IMHO the mainline code should be as simple as possible to adapt to new
boards and their associated xparameters.h.  I've created an xparameters
'abstraction layer' that keeps changes to the board more or less
isolated to the platform bus initialization data structures.  It also
prevents having to recompile the world everytime I use a different
bitstream.  However, that doesn't solve the changes to logic cores (as
you so eloquently pointed out).  At the very least I'd like to get a set
of core drivers ported/written that use #defs to adapt to the
appropriate core version.  I'll never be able to support every core
version, but I should be able to support a number of the more recent
cores.

The difficulty that I have with the current port is that there is still
a fair bit of work to adapt from one xparameters to another.

There is a very real possibilty that I'll be taking on
lots of v2pro work in the near future and I'd like to have a comfortable
foundation to start from.

Exactly what I keep wanting to do.  I expect you'll be glad you have it.

One thing I *did* do was completely remove Xilinx-sourced files (or files
based on Xilinx-supplied code) from the kernel tree.  So things like
.../arch/ppc/platforms/xilinx_ocp and .../drivers/net/xilinx_enet/x* are not
used at all.  In my thinking that stuff doesn't belong in the kernel tree
because it changes so often (again, the board vs. FPGA issue) (and I fully
expect to get re-educated, because I really don't know enough to spout off
about what should or shouldn't be in the kernel tree).
    I did of course have to change Makefiles and the like to pull the neces-
sary headers and C from my (external to the kernel tree) 'ppc405_0' dir.
And it's not a complete solution; my ppc405_0 tree isn't accounted for when
Linux builds all of its dependencies so I have to remember when to delete
a certain subtree's *.[oa] files to force rebuilds.
    Being a one-man band in a research group it works okay for me, but with-
out more work it certainly isn't scalable to a large team and wouldn't be
appropriate for product development.

quoted

I've been where you're going...

I feel a great sense of foreboding in that remark...  Thanks for the
long response; good info.

Did you use a 2.4 or 2.6 kernel in your work?  Are your driver changes
available for download anywhere?

So far we're using MV Pro 3.1, which is based on a 2.4 kernel.  Pro 4.0 is
2.6 based and starting to become available; I haven't yet checked on the
PPC405 / ML300 port.

Working for A Big Corporation, I can't easily get my changes onto an FTP
site.  I'll provide them on request instead, but note that I'll be out of
the office this Friday.  Plus I'll have to doublecheck them for the proper
copyright & licensing notices.  But still, next week should be no problem.

The files I've been modifying are
.../include/xbasic_types.h
.../include/xdma_channel.h  [1]
.../include/xemac.h  [1]
.../libsrc/dma_v*/src/xdma_channel_sg.c
.../libsrc/emac_v*/src/xemac.c
.../libsrc/emac_v*/src/xemac_g.c
.../libsrc/emac_v*/src/xemac_intr_dma.c

[1] : Since these two are duplicated within the driver tree (another peeve
       of mine), I also delete .../libsrc/dma_v*/src/xdma_channel.h and
       .../libsrc/emac_v*/src/xemac.h to avoid having to make the same
       changes twice.

Descriptions of the specific changes made follow.  I believe all but the
first are just re-applying changes MV made in their port to Linux.

.../include/xbasic_types.h
     Make 'Xuint32' and 'Xint32' 'int's rather than 'long's.

.../include/xdma_channel.h
     Add 'VirtPtr' and 'PhyPtr' elements to 'XDmaChannel' struct.
     Add 'PhyPtr' arg to XDmaChannel_CreateSgList()'s signature.

.../include/xemac.h
     Add 'PhysAddress' element to 'XEmac_Config' and 'XEmac' structs.
     Add 'PhyPtr' arg to XEmac_SetSgRecvSpace()'s and XEmac_SetSgSendSpace()'s
           signatures.

.../libsrc/dma_v*/src/xdma_channel_sg.c
     Add P_TO_V() and V_TO_P() macros.
     Add 'PhyPtr' arg to XDmaChannel_CreateSgList() and add setting of
     'InstancePtr's 'VirtPtr' and 'PhyPtr' fields.

.../libsrc/emac_v*/src/xemac.c
     Add setting of 'InstancePtr's 'PhysAddress' field in XEmac_Initialize().

.../libsrc/emac_v*/src/xemac_g.c
     Init 'XYZ' struct's new 'PhysAddress' element.

.../libsrc/emac_v*/src/xemac_intr_dma.c
     Pass 'PhysAddress' rather than 'BaseAddress' to XBufDescriptor_SetDestAd-
           dress() in XEmac_SgSend()
     Pass 'PhysAddress' rather than 'BaseAddress' to XBufDescriptor_SetSrcAd-
           dress() in XEmac_SgRecv().
     Add 'PhyPtr' arg to XEmac_SetSgRecvSpace() and pass it to XDmaChannel_Cre-
           ateSgList().
     Add 'PhyPtr' arg to XEmac_SetSgSendSpace() and pass it to XDmaChannel_Cre-
           ateSgList().

Looking at my archived of hacked ppc405_0 trees it looks like I have the
following hacked driver directories:  dma_v1_00_a, emac_v1_00_e, emac_v1_00_f
and emac_v2_00_c .  Of course there's no certainty one 'dma_v1_00_a' is the
same as another...

That's it, for now.
Tom

-- 
   /"\  ASCII Ribbon Campaign   |   Email to user 'CTZ001'
   \ /                          |             at 'email.mot.com'
    X        Against HTML       |
   / \     in e-mail & news     |