Xilinx IP core drivers for RTEMS- diff attached
gregory.menke at gsfc.nasa.gov
gregory.menke at gsfc.nasa.gov
Wed Dec 20 16:53:08 UTC 2006
Hi Bob,
There is only one xilemac.h, and it should be in libchip.
gen405/include/bsp.h is supposed to include libchip/xilemac.h, so it can
obtain driver definitions. I just checked the diff and it looks like I
screwed it up- I see the extra include as you say, but it does not exist
in my source. Beats me how I messed it up, but there you go...
With the gen405 in its present setup, I think xilemac would be better
located in the bsp than in libchip. If/when a virtex bsp shows up, then
xilemac could be copied into libchip- leaving the current version in
gen405 sort of like how the pc386 bsp has its own network drivers.
If/when gen405 moves to new_exceptions then maybe it could abandon its
internal xilemac in favor of the libchip version.
Given the above, I'd like to regenerate the diff with xilemac moved back
into the gen405 bsp, which makes sense given the old_exceptions and the
assumptions about the driver that the bsp makes. I'll try to get a new
patch out in a day or so, and please accept my apologies for the broken
diffs...
Regards,
Greg
Robert S. Grimes writes:
> Yes,
>
> It looks like $SOURCEDIR/c/src/libchip/network/xilemac.h (only xilemac.h
> I was able to find in source tree) is not making it into
> $BUILDIDR/powerpc-rtems/gen405/lib/include/libchip.
>
> I attempted to fix that by copying the file. However, when I did that,
> I got a problem about infinite include nesting; seems the file was
> including itself? Perhaps I am confused, but there is an include
> directive in xilemac.h like this
> #include <libchip/xilemac.h>
>
> If I comment that out, the infinite nesting problem goes away, but is
> replaced by these
>
> In file included from ../../../../.././gen405/lib/include/bsp.h:73,
> from
> ../../../../../../../rtems-4.6.99.3/c/src/lib/libcpu/powerpc/old-exceptions/cpu.c:31:
> ../../../../.././gen405/lib/include/libchip/xilemac.h:234: error:
> 'NUM_XILEMAC_UNITS' undeclared here (not in a function)
> ../../../../.././gen405/lib/include/libchip/xilemac.h: In function
> 'xilFifoRead32':
> ../../../../.././gen405/lib/include/libchip/xilemac.h:270: error:
> 'XEM_PFIFO_RXDATA_OFFSET' undeclared (first use in this function)
> ../../../../.././gen405/lib/include/libchip/xilemac.h:270: error: (Each
> undeclared identifier is reported only once
> ./../../../.././gen405/lib/include/libchip/xilemac.h:270: error: for
> each function it appears in.)
> ../../../../.././gen405/lib/include/libchip/xilemac.h: In function
> 'xilFifoWrite32':
> ../../../../.././gen405/lib/include/libchip/xilemac.h:309: error:
> 'XEM_PFIFO_TXREG_OFFSET' undeclared (first use in this function)
> ../../../../.././gen405/lib/include/libchip/xilemac.h:318: error:
> 'DRIVER_PREFIX' undeclared (first use in this function)
> ../../../../.././gen405/lib/include/libchip/xilemac.h:327: error:
> 'XEM_PFIFO_TXDATA_OFFSET' undeclared (first use in this function)
> ../../../../.././gen405/lib/include/libchip/xilemac.h: In function
> 'xilGetWrFifo32VacancyBytes':
> ../../../../.././gen405/lib/include/libchip/xilemac.h:363: error:
> 'XEM_PFIFO_TXREG_OFFSET' undeclared (first use in this function)
> ../../../../.././gen405/lib/include/libchip/xilemac.h: In function
> 'xilFifoRead64':
> ../../../../.././gen405/lib/include/libchip/xilemac.h:385: error:
> 'XEM_PFIFO_RXDATA_OFFSET' undeclared (first use in this function)
> ./../../../.././gen405/lib/include/libchip/xilemac.h: In function
> 'xilFifoWrite64':
> ../../../../.././gen405/lib/include/libchip/xilemac.h:440: error:
> 'XEM_PFIFO_TXREG_OFFSET' undeclared (first use in this function)
> ../../../../.././gen405/lib/include/libchip/xilemac.h:445: error:
> 'DRIVER_PREFIX' undeclared (first use in this function)
> ../../../../.././gen405/lib/include/libchip/xilemac.h:452: error:
> 'XEM_PFIFO_TXDATA_OFFSET' undeclared (first use in this function)
> ../../../../.././gen405/lib/include/libchip/xilemac.h: In function
> 'xilGetWrFifo64VacancyBytes':
> ../../../../.././gen405/lib/include/libchip/xilemac.h:507: error:
> 'XEM_PFIFO_TXREG_OFFSET' undeclared (first use in this function)
> ../../../../.././gen405/lib/include/libchip/xilemac.h: In function
> 'xilGetWrFifoVacancyBytes':
> ../../../../.././gen405/lib/include/libchip/xilemac.h:533: error:
> 'DRIVER_PREFIX' undeclared (first use in this function)
> ../../../../.././gen405/lib/include/libchip/xilemac.h: In function
> 'xilEmacStop':
> ./../../../.././gen405/lib/include/libchip/xilemac.h:548: error:
> dereferencing pointer to incomplete type
> ../../../../.././gen405/lib/include/libchip/xilemac.h:551: error:
> dereferencing pointer to incomplete type
> ../../../../.././gen405/lib/include/libchip/xilemac.h:551: error:
> 'XEM_ECR_OFFSET' undeclared (first use in this function)
> ../../../../.././gen405/lib/include/libchip/xilemac.h:555: error:
> dereferencing pointer to incomplete type
> ../../../../.././gen405/lib/include/libchip/xilemac.h:559: error:
> dereferencing pointer to incomplete type
>
> and so on, especially the deref pointer errors.
>
> Seems something else is missing wrt the Xilinx definitions...
>
> Thanks,
> -Bob
>
> gregory.menke at gsfc.nasa.gov wrote:
> > Hi Robert,
> >
> > Its likely something missing from the patch since I had a strip out a
> > lot of test things from the diff. I'll have a look at get back to you.
> >
> > OTOH I continue to have problems with automake/autoconf occasionally
> > generating makefiles that need editing because its unclear which
> > versions work and which won't and RTEMS stays so close to the
> > toolchain's bleeding edge that its hard to tell. So there is some
> > possiblity that automake/autoconf issues could be causing trouble.
> >
> > Greg
> >
> >
> > Robert S. Grimes writes:
> > > Hi Greg,
> > >
> > > I attempt to build using your patches on a clean install of 4.6.99.3,
> > > and I get this error:
> > >
> > > Making all in powerpc
> > > make[5]: Entering directory
> > > `/cygdrive/c/Home/ll/etill/rtems-4.6.99.3/tools/b-rtems-4.6.99.3/powerpc-rtems/c/gen405/lib/
> > > libcpu/powerpc'
> > > if powerpc-rtems-gcc --pipe -B../../../../.././lib/
> > > -B../../../../.././gen405/lib/ -specs bsp_specs -qrtems -DPACKAGE_NA
> > > ME=\"rtems-c-src-lib-libcpu-powerpc\"
> > > -DPACKAGE_TARNAME=\"rtems-c-src-lib-libcpu-powerpc\"
> > > -DPACKAGE_VERSION=\"4.6.99.3\
> > > " -DPACKAGE_STRING=\"rtems-c-src-lib-libcpu-powerpc\ 4.6.99.3\"
> > > -DPACKAGE_BUGREPORT=\"rtems-bugs at rtems.com\" -I. -I../.
> > > ./../../../../../rtems-4.6.99.3/c/src/lib/libcpu/powerpc -isystem
> > > ../../../../.././gen405/lib/include -I../../../../../
> > > ../../rtems-4.6.99.3/c/src/lib/libcpu/powerpc/old-exceptions -Wall
> > > -mcpu=403 -D_OLD_EXCEPTIONS -Dppc405 -O4 -fno-keep-i
> > > nline-functions -g -MT
> > > old-exceptions/old_exceptions_rtems_cpu_rel-cpu.o -MD -MP -MF
> > > "old-exceptions/.deps/old_exception
> > > s_rtems_cpu_rel-cpu.Tpo" -c -o
> > > old-exceptions/old_exceptions_rtems_cpu_rel-cpu.o `test -f
> > > 'old-exceptions/cpu.c' || echo
> > > '../../../../../../../rtems-4.6.99.3/c/src/lib/libcpu/powerpc/'`old-exceptions/cpu.c;
> > > \
> > > then mv -f
> > > "old-exceptions/.deps/old_exceptions_rtems_cpu_rel-cpu.Tpo"
> > > "old-exceptions/.deps/old_exceptions_rtems_cpu_re
> > > l-cpu.Po"; else rm -f
> > > "old-exceptions/.deps/old_exceptions_rtems_cpu_rel-cpu.Tpo"; exit 1; fi
> > > In file included from
> > > ../../../../../../../rtems-4.6.99.3/c/src/lib/libcpu/powerpc/old-exceptions/cpu.c:31:
> > > ../../../../.././gen405/lib/include/bsp.h:73:29: error:
> > > libchip/xilemac.h: No such file or directory
> > > make[5]: *** [old-exceptions/old_exceptions_rtems_cpu_rel-cpu.o] Error 1
> > > make[5]: Leaving directory
> > > `/cygdrive/c/Home/ll/etill/rtems-4.6.99.3/tools/b-rtems-4.6.99.3/powerpc-rtems/c/gen405/lib/l
> > > ibcpu/powerpc'
> > >
> > > The "xilemac.h" file certainly does exist! It seems there's an include
> > > path problem. I'm going to try and track it down, but I thought you might:
> > > - know what I did wrong (if it's my mistake), or
> > > - want to know (if it's a patch problem).
> > >
> > > I will let you know what I find on my end.
> > >
> > > Thanks!
> > > -Bob
> > >
> > > gregory.menke at gsfc.nasa.gov wrote:
> > > > Hi,
> > > >
> > > > I finally got back to some long-needed config management on the gen405
> > > > bsp. I assembled the diffs against 4.6.99.3, the file is attached for
> > > > review.
> > > >
> > > > I hesitate to just check them in as some of the changes related to
> > > > uarts, fpu and memory map are highly idiosyncratic and I don't want to
> > > > mess up other people's work. I think a compromise patch might make the
> > > > most sense, where I set up a diff that preserves the general character
> > > > of the bsp; base addresses, etc.. but gets in the updated drivers.
> > > >
> > > > Our bsp was peculiar in that the 405 units have 4 uarts and no fpu at
> > > > all, meaning, the entire toolchain has to be compiled with -msoft-float
> > > > to ensure nothing at all in newlib or above uses fp registers- the
> > > > va_args are problematic since the ppc ABI allows fpu registers to be
> > > > used when handing variable arguments. I think it is this issue that
> > > > generally forces all PPC tasks to be floating point- its quite an
> > > > annoying architectural property.
> > > >
> > > > So I'd like to propose that folks interested in the Virtex 4 gen405 bsp
> > > > family have a look at the diffs and respond with issues & changes and
> > > > hopefully I can commit something that doesn't cause too much trouble.
> > > >
> > > > If folks' email systems won't pass the attachment, then please email me
> > > > and I'll resend directly.
> > > >
> > > > Thanks,
> > > >
> > > > Greg
> > > >
> > > >
> > > > ------------------------------------------------------------------------
> > > >
> > > > _______________________________________________
> > > > rtems-users mailing list
> > > > rtems-users at rtems.com
> > > > http://rtems.rtems.org/mailman/listinfo/rtems-users
> > > >
> > >
> >
> >
> >
>
More information about the users
mailing list