Best Linux tree for Xilinx support.
David H. Lynch Jr.
dhlii at dlasys.net
Sun Aug 19 11:29:10 EST 2007
> I deem such approach is not very good one. I'm using precisely same IP
> cores like GPIO, EMAC, SPI, CAN, etc... in Virtex and Spartan FPGAs
> which means (OK, may be cores are different somewhat for different FPGAs
> but low level Xilinx code is the same). That means at least 2 different
> CPU architectures (PPC and Microblaze).
Most device drivers are outside the arch tree, only board specific
While there is a great deal of similarity between the microblaze and
ppc code that
would be under the arch tree's they are still as distinct as
Maybe there would be some way to share some of the code, but for the
the similar or identical code falls outside the arch tree.
> A How EDK project parameters get into Linux kernel? This is huge issue
> which can be divided on several items.
Xilinx has their own idea's and thus far they do not seem to fit
well with the
norms of Linux kernel developers. It is extremely unlikely the latter
I did the BSP for the Pico E1x series of boards. While it is based
heavily on Grant's
MLXXX work that I am trying to track, very little of it is even xilinx
One the key distinctions between FPGA based systems and typical
systems is that
the core is very very small. In a Pico E1x, you can only count on:
and some serial (or pseudo serial) device capable of functioning as
Flash, Ethernet, Specific Uarts, Even interrupts and interrupt
> A.2. There is also a question how these definitions get into .c and Make
> files. Petalogix has interesting solution when they bump all XILINX
> parameters to autoconf.h and .config files thus making them available
> for both compiler and make. What's your approach?
With all respect to Petalogix and the significant work they have
done, I can not see migrating all
the xparameters.h values into .config being adopted. Besides little
of none of those values are
needed outside the core of the BSP.
I am not particular enamored with the CONFIG_VIRTEX or
CONFIG_VIRTEX_4 flags either. There is very very little that knowing
the exact FPGA tells Linux. As an example Pico E12's, E14's and E16's
are fundimentally very similar, despite having different form factors,
being on different cards (CF, CardBus, ExpressBus), and using different
Xilinx parts (sometimes on the same model)
I beleive that the long term effort is to put everything into device
then the device information for the product is
dynamically created, or stored in flash or otherwise provided to
at boot. But that is pretty close to the extent of my knowledge of
trees at this time.
> A.4. Is it assumed that Xilinx low level code will stay intact as it is
> supplied with EDK package or you are going to prepare special Linux
> Xilinx set (mostly because of name convention)?
I do not beleive anyone is anticipating the Xilinx EDK code making
its way into
a kernel.org Linux source.
> B How drivers get registered - via platform devices structure in
> virtex.c file or something different?
I beleive the current approach is mostly using platform devices - though
individual drivers may vary. I beleive the longterm approach is to use
trees - I am not sure how the two interrelate.
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii at dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
More information about the Linuxppc-embedded