The Board Support Package is composed by a set files, patches, recipes, configuration files, etc. This chapter gives you the information you need when you want to customize something, fix a bug, or simply learn how the all thing has been assembled.
The bootloader used by ZedBoard is u-boot. If you want to browse/modify the sources first you have to get them. There are two viable ways to do that:
Bitbake will place u-boot sources under:
/path/to/build/tmp/work/zedboard-poky-linux-gnueabi/u-boot-xlnx/v2014.01-xilinx+gitAUTOINC+2a0536fa48-r0/git
this means that within the virtual machine you will find them under:
/home/architech/architech_sdk/architech/zedboard/yocto/build/tmp/work/zedboard-poky-linux-gnueabi/u-boot-xlnx/v2014.01-xilinx+gitAUTOINC+2a0536fa48-r0/git
We suggest you to don’t work under Bitbake build directory, you will pay a speed penalty and you can have troubles syncronizing the all thing. Just copy the sources some place else and do what you have to do.
If you didn’t build them already with Bitbake, or you just want to make every step by hand, you can always get the sources from the Internet by cloning the proper repository and checking out the proper commit:
cd ~/Documents
git clone git://github.com/Xilinx/u-boot-xlnx.git
cd u-boot-xlnx
git checkout 2a0536fa48db1fc5332e3cd33b846d0da0c8bc1e
Suppose you modified something and you want to recompile the sources to test your patches, well, you need a cross-toolchain (see Cross compiler Section). If you are not working with the virtual machine, the most comfortable way to get the toolchain is to ask Bitbake for it:
bitbake meta-toolchain
When Bitbake finishes, you will find an install script under directory:
Host
path/to/build/tmp/deploy/sdk/
Install the script, and you will get under the installation directory a script to source to get your environment almost in place for compiling. The name of the script is:
environment-setup-armv7a-vfp-neon-poky-linux-gnueabi
Anyway, the environment is not quite right for compiling the bootloader and the Linux kernel, you need to unset a few variables:
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
Inside the virtual machine, the toolchain is already installed under:
/home/architech/architech_sdk/architech/zedboard/toolchain
In the very same directory there is a file, environment-nofs, that you can source that takes care of the environment for you when you want to compile the bootloader or the kernel
source /home/architech/architech_sdk/architech/zedboard/toolchain/environment-nofs
export LDFLAGS="-L /home/architech/architech_sdk/architech/zedboard/toolchain/sysroots/armv7a-vfp-neon-poky-linux-gnueabi/usr/lib/arm-poky-linux-gnueabi/4.9.1/"
Ok, now you a have working environment to compile u-boot, just do:
cd ~/Documents/u-boot-xlnx/
make mrproper
make zynq_zed_config
USE_PRIVATE_LIBGCC="yes" make [-j parallelism factor] all
if you omit -j parameter, make will run one task after the other, if you specify it make will parallelize the tasks execution while respecting the dependencies between them. Generally, you will place a value for -j parameter corresponding to the double of your processor’s cores number, for example, on a quad core machine you will place -j 8.
Once the build process is complete, you will find u-boot file in your sources directory, that’s your binary. However, u-boot file alone is not able to boot the board, you are going to need a First Stage Bootloader and a Bitstream to make the board properly boot.
Like we saw for the bootloader, the first thing you need is: sources. Get them from Bitbake build directory (if you built the kernel with it) or get them from the Internet.
Bitbake will place the sources under directory:
/path/to/build/tmp/work/zedboard-poky-linux-gnueabi/linux-xlnx/3.17-xilinx+gitAUTOINC+7b042ef9ea-r0
If you are working with the virtual machine, you will find them under directory:
/home/architech/architech_sdk/architech/zedboard/yocto/build/tmp/work/zedboard-poky-linux-gnueabi/linux-xlnx/3.17-xilinx+gitAUTOINC+7b042ef9ea-r0
We suggest you to don’t work under Bitbake build directory, you will pay a speed penalty and you could have troubles syncronizing the all thing. Just copy them some place else and do what you have to do.
If you didn’t build them already with Bitbake or you just want to do make every step by hand, you can always get them from the Internet by cloning the proper repository and checking out the proper hash commit:
cd ~/Documents
git clone -b xlnx_3.17 git://github.com/Xilinx/linux-xlnx.git
cd linux-xlnx
git checkout 7b042ef9ea5cc359a22110c75342f8e28c9cdff1
and by properly patching the sources:
cd ~/Documents
git clone git://git.yoctoproject.org/meta-xilinx.git
cd meta-xilinx/
git checkout 7f759048bb0aeef3c0b3938be81d2bcade7acb7e
cd ..
git clone -b dizzy https://github.com/architech-boards/meta-zedboard.git
patch -p1 -d linux-xlnx/ < meta-xilinx/recipes-kernel/linux/linux-xlnx/3.17/tty-xuartps-Fix-RX-hang-and-TX-corruption-in-set_termios.patch
patch -p1 -d linux-xlnx/ < meta-zedboard/recipes-kernel/linux/linux-xlnx/3.17/0001-Updated-the-TI-Wilink8-driver-to-R8.5.patch
patch -p1 -d linux-xlnx/ < meta-zedboard/recipes-kernel/linux/linux-xlnx/3.17/0002-Patching-kernel-to-adapt-TI-Wilink8-driver.patch
patch -p1 -d linux-xlnx/ < meta-zedboard/recipes-kernel/linux/linux-xlnx/3.17/0003-Fixed-TI-Wilink8-driver-with-kernel-structure.patch
cp meta-zedboard/recipes-kernel/linux/linux-xlnx/3.17/defconfig linux-xlnx/.config
add the copy of devicetree dts:
cp meta-zedboard/conf/machine/boards/zedboard/zedboard.dtsi linux-xlnx/arch/arm/boot/dts
cp meta-zedboard/conf/machine/boards/zedboard/zedboard-mmcblk0p2.dts linux-xlnx/arch/arm/boot/dts
cp meta-zedboard/conf/machine/boards/zedboard/zedboard-ram.dts linux-xlnx/arch/arm/boot/dts
Source the script to load the proper evironment for the cross-toolchain (see Cross compiler Section) and you are ready to customize the kernel:
source /home/architech/architech_sdk/architech/zedboard/toolchain/environment-nofs
cd ~/Documents/linux-xlnx
make
and compile the rigth device tree depending if you need to work only on the RAM or also with an MMC:
make zedboard-ram.dtb
or
make zedboard-mmcblk0p2.dtb
you can find the .dtb files in arch/arm/boot/dts
Note
and to compile it:
make -j <2 * number of processor's cores> uImage UIMAGE_LOADADDR=0x8000
By the end of the build process you will get uImage under arch/arm/boot.
~/Documents/linux-xlnx/arch/arm/boot/uImage
Enjoy!
The most frequent way of customization of the Linux Kernel is to change the .config file that contains the Kernel options. Setup the environment and run:
bitbake virtual/kernel -c cleanall
bitbake virtual/kernel -c menuconfig
a new window, like the following one, will pop-up:
follow the instructions, save and exit, than you ready to generate your preferred image based on your customized kernel. If you prefer, you can build just the kernel running:
bitbake virtual/kernel
At the end of the build process, the output file (uImage.bin), along with the built kernel modules, will be placed under tmp/deploy/images/zedboard/ inside your build directory, so, if you are building your system from the default directory, the destination directory will be /home/architech/architech_sdk/architech/zedboard/yocto/build/tmp/deploy/images/zedboard/.
A Yocto/OpenEmbedded meta-layer is a directory that contains recipes, configuration files, patches, etc., all needed by Bitbake to properly “see” and build a BSP, a distribution, a (set of) package(s), whatever. meta-xilinx is a meta-layer which defines the BSP for Xilinx devices, ZedBoard included. You can get it with git:
git clone git://git.yoctoproject.org/meta-xilinx.git
cd meta-xilinx/
git checkout 7f759048bb0aeef3c0b3938be81d2bcade7acb7e
Please, refer to the README file contained inside the meta-layer directory.
The machine name corresponding to ZedBoard is zedboard.
The final root file system will be packaged as a .tar.gz file that, at the end of the build process, Bitbake will let you find it under directory:
/path/to/yocto/build/tmp/deploy/images/zedboard/
this means that within the SDK the actual path of the directory is:
/home/architech/architech_sdk/architech/zedboard/yocto/build/tmp/deploy/images/zedboard/
To deploy the root file system, you are going to need an SD card with two partitions on it.
The first partition must be formatted as FAT16, its size must be sufficient to contain all the following files (64MB are more than enough):
To have a better understanding of those components and how to boot the board please refer to Let’s boot Section.
The second partition, our root file system partition, can be formatted as EXT2.
We assume that the second partition of the SD card gets mounted (in your SDK virtual machine) under:
/media/rootfs
Warning
If that’s not the case for your configuration, please find out what is the proper mounting point for such a partition on your system and replace it in the following instructions.
Untar the file corresponding to your root file system inside such a partition:
sudo rm -rf /media/rootfs/*
sudo tar -xzf /home/architech/architech_sdk/architech/zedboard/yocto/build/tmp/deploy/images/zedboard/<image>-zedboard.tar.gz -C /media/rootfs/
where <image> is the name of the recipe you used to build your root file system. For example, if you built core-image-minimal-dev with Bitbake, then the name of the tarball will be core-image-minimal-dev-zedboard.tar.gz
Important
sudo password is architech