Linux on Xilinx Virtex
From SecretLab
Information about running Linux on the PowerPC core embedded into the Virtex-II Pro, Virtex 4 and Virtex 5 FPGAs from Xilinx.
Linux can be run on either the soft MicroBlaze core, or the hard PowerPC core. This page focuses on the PowerPC support. However, there is some overlap in device driver support between the PowerPC and MicroBlaze architectures.
For more information about Linux on MicroBlaze, go here: [1]
Contents |
EDK Project
The EDK software settings allow the developer to choose what software environment to create for each processor core in the design. To prepare a design for Linux in Platform Studio, go to "Software" -> "Software Platform Settings" -> "OS & Library Settings" and choose "linux_2_6".
BSP generation
You should generate the BSP into an empty directory and manually copy the arch/ppc/platform/4xx/xparameters/xparameters_ml* file into your kernel source tree. You can also copy some of the Xilinx device drivers manually, but it is simpler and easier to use one of the vendor trees listed below which already has most of the device drivers integrated.
I do not recommend letting Platform Studio generate its BSP in your Linux kernel source directory. Unless you are using the exact version of the kernel tree that EDK expect, it will most likely break your kernel tree and you won't be able to compile a kernel. ---Gcl 16:39, 23 July 2007 (MDT)
Supporting multiple OS targets
Unfortunately, Platform Studio does not allow BSPs for different OS targets to be generated from a single design. (Well, it does, but you need to generate one BSP, change the software settings, and generate the second BSP). For example, if your boot loader uses the standalone target, and Linux uses the linux_2_6 target (xparameters.h generated by 'standalone' will not work with the kernel), Platform Studio does not provide an option to generate both BSPs.
To work around this, you need to create a second shadow project which uses the same hardware design, but a separate set of files for the software settings. This is similar to the approach used by the Xilinx ml300 and ml403 reference designs, except the Xilinx designs also duplicate the system.xmp file. Easiest way I've found to do this is to temporarily modify system.xmp to use system_linux.mss file, setup the linux platform settings, and then switch back to system.mss.
Do the following; duplicate the software setting files
$ cp system.mss system_linux.mss $ sed -i -e 's/system.mss/system_linux.mss/g' system.xmp $ xps system.xmp (Setup the Linux settings and save the project) $ sed -i -e 's/system_linux.mss/system.mss/g' system.xmp
Now, to actually generate the Linux BSP, do the following on the command line:
$ make -f system.make MSSFILE=system_linux.mss clean libs
To build the normal BSP, just drop the MSSFILE= argument:
$ make -f system.make clean libs
Unfortunately, doing it this way provides no easy way to modify the Linux software settings entirely within Platform Studio. I've found I need to manually change the system.xmp file to use system_linux.mss, fire up Platform Studio to make my config changes, and then revert system.xmp back to normal.
The advantage of this approach is that it works well if you're using a custom makefile for your project. The custom Makefile can use the same system_incl.make file regardless of which OS target you are building. If you duplicate system.xmp as system_linux.xmp, then Platform Studio will insist on generating system_linux_incl.make instead of system_incl.make. This means your custom make files has to include a different file depending on which target is being used.
Warning:
- I've found that at times platform studio really likes to keep fiddling with system.mss, even after you've told it to use system_linux.mss.
- Be very careful and make sure you've checked in your system.* files before adding the Linux target to make sure the linux target isn't changing unexpected things.
Toolchain
Any recent powerpc cross compiler should be suitable for building the kernel and the root filesystem. Below are some of the options.
ELDK
I personally use ELDK from Denx Software Engineering
---Grant 16:14, 16 July 2007 (MDT)
Crosstool (built from sources)
The Crosstool set of scripts written by Dan Kegel is a tool for building a cross compiler from source. It is available from the crosstool webpage:
http://www.kegel.com/crosstool
Or by cloning Secret Lab's git mirror:
git clone git://git.secretlab.ca/git/crosstool.git
I had good success building the Linux 2.6 kernel for an ML-310 board by first building the cross compiler toolchain from sources using Crosstool. I only had to edit the demo-powerpc-405.sh script and uncomment only the following line:
eval `cat powerpc-405.dat gcc-3.4.5-glibc-2.3.6.dat` sh all.sh --notest
---Eigendude 21:03, 9 December 2007 (MST)
I've also had good luck with gcc 4.1.1 and glibc 2.3.6 which I use with buildroot for generating a root filesystem.
eval `cat powerpc-405.dat gcc-4.1.1-glibc-2.3.6.dat` sh all.sh --notest
---Gcl 09:26, 13 December 2007 (MST)
Kernel support
Mainline
The Virtex II Pro, Virtex 4 and Virtex 5 PowerPC cores are fully supported by the current official kernel release from kernel.org. The official kernel also has device drivers for many of the commonly used Xilinx IP cores. Device drivers which are not in mainline yet can usually be obtained from either the Secret Lab or the Xilinx git tree. See the table below for specific driver information.
| IP Core | kernel.org | Secret Lab | Xilinx | Notes |
|---|---|---|---|---|
| plbv46_pci plb_pci | no | no | Patch under review on linuxppc-dev mailing list | |
| xps_ethernetlite | no | no | Xilnix Layered driver | |
| xps_gpio opb_gpio | yes | yes | yes | |
| xps_hwicap opb_hwicap | yes | yes | yes | |
| xps_intc opb_intc | yes | yes | yes | |
| xps_spi | yes | yes | yes | |
| xps_sysace opb_sysace | yes | yes | yes | |
| xps_tft | yes | yes | yes | |
| xps_uart16550 | yes | yes | yes | |
| xps_uartlite opb_uartlite | yes | yes | yes | |
| xps_ll_temac | no | In test-2.6.29 (V5 only) | Xilnix Layered driver | The ll_temac driver will probably be released as part of the 2.6.31 kernel release |
There are a set of Xilinx cross-platform 'layered' drivers, but they do not match well with the kernel design patterns or coding style. It is unlikely that any of the Xilinx layered drivers will be merged into mainline as-is, and general consensus on the linuxppc-dev mailing list is that they need to be rewritten.
Vendor trees
There are a number of vendor trees which include the Xilinx drivers.
| Vendor | Tree | Notes |
|---|---|---|
| Secret Lab | http://git.secretlab.ca/?p=linux-2.6.git | Xilinx Virtex maintainer's staging tree. Patches being prepared for mainline will appear first in this tree. |
| Xilinx | git://git.xilinx.com/linux-2.6-xlnx.git | See Announcement |
Note on ARCH
The Linux build uses the $ARCH environmental variable to select the architecture for compiling the kernel. Historically, 32bit powerpc support has been in the arch/ppc directory (ARCH=ppc) and 64 bit support was is arch/ppc64 (ARCH=ppc64). In 2005 the decision was made to merge the 32-bit and 64-bit support into a single directory. The effort took several years, but as of 2.6.27 the merge is complete and all PowerPC support code is contained in the arch/powerpc subdirectory.
The transition also include some changes to the way Linux boots on PowerPC platforms. In arch/ppc, some bootloaders (mostly embedded) pass information to the kernel via the board info structure (struct bd_info), and others (usually OpenFirmware based) pass an OF device tree. The significant feature of arch/powerpc is that the bd_info structure is no longer supported. All platforms must use a device tree to pass information to the kernel.
Userspace
Any powerpc userspace should work. However the 405 core in the Virtex lacks an FPU so you either need a userspace compiled with soft-float, or have CONFIG_MATH_EMULATION configured into the kernel.
If your console is on the uartlite, you will need to add /dev/ttyUL* device nodes and you'll need to pass 'console=ttyUL0' on the kernel command line.
Distributions
ELDK
The ELDK distribution ships with a root filesystem which can be used on the Virtex 405. This is the easiest way to get a Virtex 405 Linux system up and running.
Refer to the ELDK documentation for information about how to tailor the ELDK rootfs.
Buildroot
The Buildroot tool can be used to build a custom rootfs.
Buildroot can either build it's own uclibc based toolchain, or it can use an external toolchain.
(Comment from Gcl): I'm currently using buildroot for my projects with using an external toolchain build from crosstool. Letting buildroot build the toolchain resulted in failures.
OpenEmbedded
OpenEmbedded is a complete tool for building a cross toolchain, the root filesystem, a kernel image and a bootloader for an embedded platform. OE includes support for the ml300 and ml403 platforms.
(Comment from Gcl): Unfortunately, I've been unsuccessful getting OE to build a usable rootfs for Virtex. OE is a complex system where a lot of things can go wrong.
Design Notes
Some of my observations running Linux 2.6 on the ML-310 are here Xilinx ML310 --Eigendude 10:19, 15 December 2007 (MST)
