Translate

Sunday, 19 April 2020

New ! An easy way to install the needed board file for VIVADO



Hi !

Ok, It's been some time that I did not update this blog, but I discovered a new cool stuff, so I did some investigation on it, and there you go, here is a small article on this !






INTRO : So what is a board file anyway ??!



Xilinx provides for a long time now a very cool way to use the developement boards available thanks to the board file files !

When creating a new project, using the board file for your board instead of the FPGA reference allows you to quickly get in VIVADO everything already set up for the board ! It can save you quite some configuration time or document readings.

The only problem with this is if like me you keep changing your projects from VIVADO's versions, swaping computers or even test it on several boards, well you will spent some time on finding the board file on Google !

But YES, from 2019.1 version, things will get easier thanks to Xilinx !!


So to use it, when you create a VIVADO project, in the wizzard steps you get the possibility to set the FPGA's reference either by selecting all elements of the part reference, or you can choose a board definition file for the board your FPGA is on.

For example in VIVADO 2017.4 it gives :




This is because each VIVADO installation folder contains a reduced list of board file files.

In this example of VIVADO 2017.4 it is stored here :




Now let see what Xilinx added to help us get additionnal board file that are not provided in the default installation list.






SOLUTION 1 : Get the file within VIVADO at project creation step



Stage 1


So, when you create a VIVADO project and when you get in the Default part select wizzard, just go to the Boards tab, then you see on the right top hand corner a new button called Update Board Repositories. Click on it just like this :




Stage 2


When you Click on the Download button, it will launch the following Downloading boards pop up and, getting in a long long long long downloading time, because the whole board file catalog is downloaded !!!




Stage 3


After 8 long minutes, donwload is done and you get the whole list in the board selection tab.




You can then use the Search tool to find the board you need, select it and finalize project creation.


Stage 4


Let's analyze what has been done.

If I check the VIVADO .xpr project file content I get the following information on device reference definition.




If I compare it to an existing project where board selection has been done with the board files included on VIVADO's installation I get :




The BoardPartRepoPaths section has been added, which specifies a new path for board files. This path is added to the default one from in VIVADO installation path, it does not replace it, other boards are still available from the wizzard.

So, thanks to this BoardPartRepoPaths section it can be usefull to create and handle your own board file directory, so that your teams can always fine there the boards files for the boards you are using regularly !

Finally if we take a look in the BoardPartRepoPaths created folder we get a lot of boards files, and probably most of them not usefull for you !




CONCLUSION !

As a conclusion I would say that Xilinx provided a really cool tool, but used in the first place it may not be fully efficient for several reasons:

- It takes 8 minutes to install, if every designer of the team uses it on each of its computer, for each version of VIVADO, its time consuming,
- It installs ALL boards available, so it's HDD consuming, and I guess that you won't use more than 5% !

So I would recommand to handle this differently because Xilinx provided tcl commands to manage this data base !






SOLUTION 2 : Use TCL commands to handle additionnal Board files



Stage 1


So this new possibility has been made possible thanks to the xhub resource that provides the xilinx_board_store.

Let's try to have some information on this :




So as you can see, the destination storage folder is predefined in the LOCAL_ROOT_DIR.

This property is read only.

Anyway, the folder path in LOCAL_ROOT_DIR can be used as a temporary folder !!





UNDER CONSTRUCTION !!















Post Conclusion


Thursday, 9 May 2019

Another very low access method with the devmem utility



Hi !

We've started testting Linux Software development with PEEK and POKE commands.

3.1 - Very Low Level access with Peek and Poke

And then we moved to the mmap system call.

3.2 - Easy Custom IP access with application development based on mmap

In this post we've seen the mmap system call is based on the /dev/mem system virtual file use.



Well, I've just discovered that the /dev/mem is also directly available from the command line using a utility application provided by BusyBox which is called devmem !

This provides us a second very low level access method with the PEEK and POKE commands.


So let's see that we can do the same things as the PEEK and POKE commands !




Stage 1


Some information about the devmem utility use.




Stage 3


Now, to force the output led to ON, we only have to do the same steps as in the LED_TEST_IP_SetLedOn function of our driver.

Remember that our custom IP LED_TEST_IP is located at the physical offset 0x43C0_0000.

Which gives.




And there you go !

The led is ON on the MiniZed board.


Stage 4


Now, to force the output led to OFF, we only have to do the same steps as in the LED_TEST_IP_SetLedOff function of our driver.

Which gives.




And there you go !

The led is OFF on the MiniZed board.


Stage 5


Now, to force the output led to BLINK, we only have to do the same steps as in the LED_TEST_IP_SetLedBlink function of our driver.

Which gives.




And there you go !

The led blinks on the MiniZed board.










Post Conclusion
Now we have :

- Used the devmem utility application from the command line to control the behavior of our custom IP.

Like the PEEK and POKE commands, this is another methode to avoid writting a single line of software !

It can be a usefull tool.


Easy Custom IP access with application development based on mmap



Hi !

In the previous post we've started Linux Software development with PEEK and POKE commands.

3.1 - Very Low Level access with Peek and Poke

Now we are going a step further by developping a test application, which will use existing stuff underneath, in order to limit complexity for now !

The test application will be based on mmap (Memory Map) to get easily access to our custom IP hardware ressources.


As this post is quite long, here are the main sections of this post for a quick jump :







Step 1 : "Hello World !" template application with PetaLinux


The PetaLinux toolset is very powerfull and among all its functionalities we will use here its application development capability.


Stage 1


A Linux application is for PetaLinux a component, so it handles everything to create it.

As it is a nice tool, it will provide us a simple "hello world" template in C.

We will go through the process of generating a Linux application with PetaLinux, using this example application. Then we will go to our own test application.

So, first step, create the application using the C template from PetaLinux. Use the following command :




Oups ! Its seems that PetaLinux is quite sensible to the name syntax !!

Let's try a simple name with this command:




Ok the application template is created.


Stage 2


User application folders are located in the /project-spec/meta-user/recipes-apps/ folder.

Let's see what is generated in this folder.




This folder contains :

- The .bb file, this is a bitbake recipe file which is a Yocto stuff. It is some kind of a makefile that handles what is needed to be included, compiles and generates the output package to be installed.

- A readme file for some explainations,

- And the files folder, this is where are the source files.




The source files folder contains the Makefile and the template source for the "hello World" which is shown below.




Stage 3


Now the application is created, let's compile it.

We will use the PetaLinux compilation comand as follow:




Compilation is Ok, so the tool created all the needed files.


Now that the application is available, we will add it to the rootfs and the regenerate the output image files to be downloaded onto the MiniZed board.


Stage 4


To add an application to the rootfs we have to configure the rootfs !

The previous steps provided everything neccessary to insert the application in the system, so the system will detect the application automatically. We only have to click on it to have it included in the rootfs !

So first, let's open the rootfs configuration menu from PetaLinux with the following command:




The configuration menu opens.

Scroll down to the apps line, press enter.




The list of the available applications is shown. Our testmmap application is in the list, but it is not selected.

Scroll down to the testmmap line and press enter.




Then exit the configuration menu by pressing several times escape until you get the save request pop up.

Select Yes and press enter.




Stage 5


Ok, rootfs' configuration has been modified, now it has to be generated again to include the modifications.

The following command will do everything for us.

It will re generate the modified images and copy them in the output folders, ready to be downloaded !




Fine!

Everything is now ready for testing on the MiniZed board.

Download the images onto the board.

Open the console terminal with Putty and let's check if the system knows our testmmap application.

Just type testmmap to launch the application and check that the Hello World ! is generated.




YES !!

Everything worked fine.

The point here is that we've seen how to handle the generation of an application using PetaLinux.

So now, let's try to write our test application for our custom IP.






Step 2 : Write the test application for our Custom IP using PetaLinux



Stage 1


I will now replace the "Hello World" template application with a test application based on MMAP that I will call testmmap.

I will detail the source code I used in the testmmap.c to blink the LED driven by my custom IP LED_TEST_IP.

So, first, to get access to the custom IP mapping, we've got to open the /dev/mem virtual file, which will provide us an access to the system memory.




Stage 2


Ok, the system's physical memory mapping can be accessed.

To reach it, we will use the mmap system call.

It will map in the user space a page of the system's virtual memory corresponding to the page of the physical memory of our custom IP.

In return to the system call, we will get a pointer to the base address of the virtual memory page. Then we can use the offsets defined for the physical mapping of the registers inside the custom IP.




Stage 3


To end the mmap stuff here, we'll jump over the user function for now and have a look at the end of the application, where the file is closed and the mapped memory is given back.




Stage 4


Ok, back to the user code, in our case let's make the LED blink !

I created a parameter structure that is intended to contain the configuration / status of each instance of the custom IP. In our case it only needs to contain the base address of the custom IP internal mapping.




So, at the beginning of the main I declare the structure instance for my custom IP.




And last step, I initialize it with the virtual address retrieved from the mmap call.




Stage 5


Now everything is ready to play with the custom IP !!

As a test example I will put the custom IP in the blinking mode.

For that, I created the SetLedBlink function, and so I call it to execute the custom IP's registers configuration sequence.




If you look at it, it is a simple address pointer manipulation !




Ok, the testmmap.c is complete.

Now let's compile it and test it on the MiniZed board !!






Step 3 : Run the test application for our Custom IP on the MiniZed board



Stage 1


The first thing to do before launching the compilation is to clear the previous compilation environment.

I don't know why, but if I don't do this step, compilation step will stop in error.....

So use the following command to clean the previous compilation environment for the testmmap application.




Stage 2


Then you can launch the application compilation step.

Use the following command.




Stage 3


Ok, compilation went fine.

Now let's generate the image file including our testmmap application in the rootfs.

Use the following command.

Be aware that it can be quite long to generate the files. For me it took about 12 minutes.




Stage 4


Ok, generation went fine.

Now let's download the files to the MiniZed board.

Use the following command.

Be aware that it can be quite long to download the files using JTAG. For me it took about 5 minutes.

The -v option prints out more information, especially the time estimated for each step.


mtvl@mtvl-VirtualBox:~/fpga/test_proj_petalinux$ petalinux-boot -v --jtag --fpga --kernel
INFO: Use bitstream: "/home/mtvl/fpga/test_proj_petalinux/images/linux/system.bit.
INFO: Please use --fpga --bitstream  to specify a bitstream if you want to use other bitstream.
INFO: Append dtb - /home/mtvl/fpga/test_proj_petalinux/images/linux/system.dtb and other options to boot zImage
XSDB Script:
INFO: Launching XSDB for file download and boot.
INFO: This may take a few minutes, depending on the size of your image.

connect
puts stderr "INFO: Configuring the FPGA..."
puts stderr "INFO: Downloading bitstream: /home/mtvl/fpga/test_proj_petalinux/images/linux/system.bit to the target."
fpga "/home/mtvl/fpga/test_proj_petalinux/images/linux/system.bit"
targets -set -nocase -filter {name =~ "arm*#0"}

source /home/mtvl/fpga/test_proj_petalinux/project-spec/hw-description/ps7_init.tcl; ps7_post_config
catch {stop}
set mctrlval [string trim [lindex [split [mrd 0xF8007080] :] 1]]
puts "mctrlval=$mctrlval"
puts stderr "INFO: Downloading ELF file: /home/mtvl/fpga/test_proj_petalinux/images/linux/zynq_fsbl.elf to the target."
dow "/home/mtvl/fpga/test_proj_petalinux/images/linux/zynq_fsbl.elf"
after 2000
con
after 3000; stop
targets -set -nocase -filter {name =~ "arm*#0"}
puts stderr "INFO: Downloading ELF file: /home/mtvl/fpga/test_proj_petalinux/images/linux/u-boot.elf to the target."
dow "/home/mtvl/fpga/test_proj_petalinux/images/linux/u-boot.elf"
after 2000
con
after 2000; stop
targets -set -nocase -filter {name =~ "arm*#0"}

rst -processor; after 2000
puts stderr "INFO: Loading image: /home/mtvl/fpga/test_proj_petalinux/images/linux/system.dtb at 0x08008000"
dow -data "/home/mtvl/fpga/test_proj_petalinux/images/linux/system.dtb" 0x08008000
after 2000
rwr r2 0x08008000
targets -set -nocase -filter {name =~ "arm*#0"}
puts stderr "INFO: Loading image: /home/mtvl/fpga/test_proj_petalinux/images/linux/zImage at 0x00008000"
dow -data "/home/mtvl/fpga/test_proj_petalinux/images/linux/zImage" 0x00008000
after 2000
rwr pc 0x00008000
con
after 5000
exit
rlwrap: warning: your $TERM is 'xterm-256color' but rlwrap couldn't find it in the terminfo database. Expect some problems.: Inappropriate ioctl for device
attempting to launch hw_server                                                                                             

****** Xilinx hw_server v2018.3
  **** Build date : Nov 15 2018-19:35:59
    ** Copyright 1986-2018 Xilinx, Inc. All Rights Reserved.

INFO: hw_server application started
INFO: Use Ctrl-C to exit hw_server application

INFO: To connect to this hw_server instance use url: TCP:127.0.0.1:3121

INFO: Configuring the FPGA...
INFO: Downloading bitstream: /home/mtvl/fpga/test_proj_petalinux/images/linux/system.bit to the target.
100%    1MB   1.1MB/s  00:01    
mctrlval=30800100
INFO: Downloading ELF file: /home/mtvl/fpga/test_proj_petalinux/images/linux/zynq_fsbl.elf to the target.
Downloading Program -- /home/mtvl/fpga/test_proj_petalinux/images/linux/zynq_fsbl.elf
 section, .text: 0x00000000 - 0x00009703
 section, .handoff: 0x00009704 - 0x0000974f
 section, .init: 0x00009750 - 0x00009767
 section, .fini: 0x00009768 - 0x0000977f
 section, .rodata: 0x00009780 - 0x00009a27
 section, .data: 0x00009a28 - 0x0000bd1f
 section, .mmu_tbl: 0x0000c000 - 0x0000ffff
 section, .init_array: 0x00010000 - 0x00010003
 section, .fini_array: 0x00010004 - 0x00010007
 section, .rsa_ac: 0x00010008 - 0x0001103f
 section, .bss: 0x00011040 - 0x0001248f
 section, .heap: 0x00012490 - 0x0001448f
 section, .stack: 0xffff0000 - 0xffffd3ff
100%    0MB   0.0MB/s  00:01    
Setting PC to Program Start Address 0x00000000
Successfully downloaded /home/mtvl/fpga/test_proj_petalinux/images/linux/zynq_fsbl.elf
INFO: Downloading ELF file: /home/mtvl/fpga/test_proj_petalinux/images/linux/u-boot.elf to the target.
Downloading Program -- /home/mtvl/fpga/test_proj_petalinux/images/linux/u-boot.elf
 section, .text: 0x00400000 - 0x004370ab
 section, .rodata: 0x004370b0 - 0x004442ef
 section, .hash: 0x004442f0 - 0x00444307
 section, .dtb.init.rodata: 0x00444310 - 0x004478df
 section, .data: 0x004478e0 - 0x00449653
 section, .got.plt: 0x00449654 - 0x0044965f
 section, .u_boot_list: 0x00449660 - 0x0044a41f
 section, .efi_runtime: 0x0044a420 - 0x0044a51f
 section, .efi_runtime_rel: 0x0044a520 - 0x0044a5af
 section, .rel.dyn: 0x0044a5b0 - 0x0045201f
 section, .bss_start: 0x0044a5b0 - 0x0044a5af
 section, .bss: 0x0044a5b0 - 0x0046798b
 section, .bss_end: 0x0046798c - 0x0046798b
100%    0MB   0.0MB/s  00:08    
Setting PC to Program Start Address 0x00400000
Successfully downloaded /home/mtvl/fpga/test_proj_petalinux/images/linux/u-boot.elf
INFO: Loading image: /home/mtvl/fpga/test_proj_petalinux/images/linux/system.dtb at 0x08008000
100%    0MB   0.0MB/s  00:00    
Successfully downloaded /home/mtvl/fpga/test_proj_petalinux/images/linux/system.dtb
INFO: Loading image: /home/mtvl/fpga/test_proj_petalinux/images/linux/zImage at 0x00008000
100%    9MB   0.0MB/s  04:18    
Successfully downloaded /home/mtvl/fpga/test_proj_petalinux/images/linux/zImage

INFO: SOC Silicon version is 3.1.
mtvl@mtvl-VirtualBox:~/fpga/test_proj_petalinux$


Now, just enter the name of the application, here testmmap. This will execute the application.




And the LED blinks !!

So that's it for this post.





Post Conclusion

Now we have :

- Used the comands from the Petalinux tool to generate a template application,
- Used the comands from the Petalinux tool to generate a user application,
- Configured the system to embed the test application in the rootfs,
- Used the MMAP system call in the C source file, to easily access from the user space the hardware resources of our custom IP, and thus, be abble to quickly start writing test code for our custom IP.


We've identified that the whole process from modifing the source code of the application to running it on the board needs the following commands :

petalinux-build -c testmmap -x do_clean
petalinux-build -c testmmap
petalinux-build -x package
petalinux-boot -v --jtag --fpga --kernel

But the main conclusion is that the whole process takes about 20 minutes for an iteration !!!!

So this method cannot be used for the active developments steps where you might need to test many modifications, which would lead to hugh developement time !

This should be reserved for basic operations, in the case where your system has not the network configuration ready.



Friday, 12 April 2019

Very Low Level access with Peek and Poke



Hi !

Software access to Custom IP's registers under the Linux world can be done in so many ways !

This large choice of possibilities leaves beginners quite lost on how to start !

In this post we will start slowly and very easilly !

Let's do it old school using PEEK and POKE commands.

Even thow they are based on mmap that will see later in another post, these comands are still the same ! I read or write a physical address directly.

As this post is quite long, here are the main sections of this post for a quick jump :







Step 1 : Activate the PEEK and POKE commands in PetaLinux



Stage 1


The activation of the PEEK and POKE commands is done during the configuration step of the Rootfs in the PetaLinux tool.

So go the project's folder and use the following command.




Stage 2


This opens the configuration menu.

Then go to the apps menu.




And select the peekpoke application.




Then press escape several times to get out of the configuration menu.

Before leaving, you will be asked to save the modifications. Select Yes.




Then the configuration modification is done.




Now that configuration is done, you have to use the build comand again to generate the files.


Stage 3


The PEEK and POKE commands are in fact two Linux applications which source files can be found in project-spec/meta-user/recipes-apps/peekpoke/files/.

You'll see that these source codes are based on a system call named mmap (Memory Map).

You have to open the virtual file /dev/mem of the system memory, then make a mmap system call to the /dev/mem file to gain access to a physical address from the user space. More precisely, mmap will map an entire physical memory page, then your pointer can manipulate every offset in this memory page.






Step 2 : Use the PEEK and POKE commands in PetaLinux



Stage 1


First step here is to load the files to the MiniZed board.

Like the following previous post, we will use the JTAG commands from the PetaLinux tool.

2.7 - Generate a basic Linux over the custom IP

And then we will try the PEEK and POKE commands in a Putty terminal.

When in the terminal, try the commands to see if they are available.




OK, everything is ready !


Stage 2


Now, we have to find where are located the registers to access. This is the absolue physical address of our custom IP.

You can find the information :

- In the device tree file pl.dtsi, or
- In the VIVADO project, with the address mapping of the Block Design Editor.

So, for us it is 0x43C0_0000.


Stage 3


Now, to force the output led to ON, we only have to do the same steps as in the LED_TEST_IP_SetLedOn function of our driver.

Which gives.




And there you go !

The led is ON on the MiniZed board.


Stage 4


Now, to force the output led to ON, we only have to do the same steps as in the LED_TEST_IP_SetLedOff function of our driver.

Which gives.




And there you go !

The led is OFF on the MiniZed board.


Stage 5


Now, to force the output led to BLINK, we only have to do the same steps as in the LED_TEST_IP_SetLedBlink function of our driver.

Which gives.




And there you go !

The led blinks on the MiniZed board.










Post Conclusion
Now we have :

- Configured our Linux to have the PEEK and POKE commands available,
- Used the PEEK and POKE commands from the terminal to control the behavior of our custom IP.

For now we did not write a single line of software !

But yet with these commands we can control from the embedded Linux the registers of our IP, it can be usefull to make some debug tests. You can even write scripts to chain commands.


Friday, 5 April 2019

Generate a basic Linux over the custom IP



Hi !

In this post we will use what has been done for the Zynq standalone design to test our custom IP's driver. If you've missed it, have a look to this post and the previous ones.

2.6 - Run the test driver on the MiniZed board with a standalone Zynq design

The goal of this post is quite simple, generate a basic Linux for the Zynq core associated to the PL bitstream which includes our custom IP.

This will be done using the PetaLinux tool installed in the previous posts. That a look over there:

1.6 - How to install PetaLinux


As this post is quite long, here are the main sections of this post for a quick jump :







Step 1 : Import the project under the Linux environment



Stage 1


The previous posts used the VIVADO tool in the Windows environment to generate the Zynq project that we will re use.

So the first thing to do is to copy the VIVADO project and its dependency (our custom IP library) in Ubuntu. For that we use the shared folder.




Stage 2


Now we are going to open the project in VIVADO in the Ubuntu environment to check that everything is ok.

Open the Virtual box, Launch the VM, Log in Ubuntu.

Then I will copy the files into my user space under /home/mtvl/fpga/.




Then Launch VIVADO and open the test_proj_zynq project.

First thing to do, check that the dependency to the custom IP library has been automatically updated to the right folder.




Ok, so everything is set properly.


Stage 3


Now we are going to regenerate the bitstream, to check that everything is fine under Ubuntu.

Click on Generate Bitstream.

Set the number of jobs and click Ok.




The generation flow will execute until it is done.


Stage 4


Now the last and most important step, the Hardware Platform generation !


Good to know :

The Hardware Platform generation will provide a HDF file. This file is a container that will include all the major elements for PetaLinux tool to generate a Linux that contains everything to access our custom IP.




You can check that the design_1_wrapper.hdf file has been generated or updated in the /test_proj_zynq/test_proj_zynq.sdk folder.

You can close the VIVADO tool.





Step 2 : Create the Linux using the PetaLinux Tool



The PetaLinux tool is a very powerfull tool that make things quite easy !

The tool provides a sequential list of tasks in which you select the ones you need.

The workflow is the following:




Stage 1


So the first step is to create the Hardware Platform.

That's what we've done for the Zynq Standalone project.

But for Linux, there are some specific constraints that we have to add !

The Linux to run expects the following resources:

- One Triple Timer Counter TTC
- An external memory controller with at least 32MB of memory (we'll use the DDR of the Minized)
- An UART for serial console (which is the minimum mean of communication with the Linux)

Then some other resources are optional but usefull for other tasks:

- A non Volatile memory for storing boot ressources (QSPI, SD, MMC)
- An Ethernet controller for network access

I made a copy of the test_proj_zynq folder into a test_proj_zynq_linux folder.




Stage 2


Now let's open VIVADO to edit the Zynq core and for now, only add the required resources.

For the first element, the TTC, go to MIO configuration, click on the Timer 0 and select the pre defined pins MIO.




For the DDR controller, everything is already set up thanks to the MiniZed board file configuration.




And for the UART we have first to look to the one used on the Minized board.

The schematics of the board show that it is the UART1 on the MIO[48:49] pins.

Go to MIO configuration, click on the UART 1 and select the pre defined pins MIO[48:49].




Then regenerate the BD wrapper file and launch the bitstream generation.

Once it is done, launch the Export Hardware to update the HDF file.


Stage 3


So now let's create the PetaLinux project.

I will place it in the /home/fpga/test_proj_petalinux folder.

Open a terminal and go to /home/fpga.

Create the project with the following comand:




The command details :

- petalinux-create : petalinux resource creation
- -t project : specifiy which type of PetaLinux ressource to create (Project / Application / Module)
- -n test_proj_petalinux : in our case we specify the name of the project
- --template zynq : request to create a project with a Zynq predefined template (MicroBlaze / Zynq / ZynqMP)


Stage 4


As we use a custom hardware, we are now going to initialize the project using the Hardware Description file we generated.

First thing to do is to go to the PetaLinux project's folder.

As we are inside the PetaLinux projet, we have to provide the path to the HDF file. The command is the following:




The command details :

- petalinux-config : Initialize a PetaLinux project (only for custom hardware projects)
- -get-hw-description : Must provide the path to the folder containing the HDF file. Either the path is provided and you have to be in the project folder, either the path is not provided and you have to be in the HDF file folder.


This will launch the configuration menu.




This a very interesting menu. It can let you configure your project, but it can also let you check what is currently configured. For example you can check in Subsystem AUTO Hardware Settings what is the current UART for console.

Execution of the initialization can last several minutes.




Stage 5


Now we can build the projet.

So go inside the PetaLinux project's folder and type the following command:




The execution provides a warning but it can be ignored, see AR# 71110.

As you can see, the build step can be quite long, for me it took about 40 minutes.

The build step is very important because it provides a lot of things.


Good to know :

The build step will generate:

- A log file in test_proj_petalinux/build/build.log
- A DTB (Device Tree Blob) file,
- A FSBL (First Stage Boot Loader) file, which can be configured to not be generated,
- U-Boot,
- The Linux Kernel.

All these files are generated in the test_proj_petalinux/images/linux folder.
The tool makes a copy of these files in the /tftpboot folder to be ready to download to the board.






Step 3 : Analyze the generated content of the PetaLinux project



Stage 1


One thing interesting to check is to see if our IP has been integrated in the hardware definition. This means, is our IP part of the device tree generated ?

Well, this is the case. The folder test_proj_petalinux/components/plnx_workspace/device-tree/device-tree contains all the Device Tree elements.

The pl.dtsi stands for the Programmable Logic Device Tree Include, which should describe the content of the FPGA. So everything is ok, our IP is described.




This IP is expected to be compatible with the xlnx, led-test-ip-1.0 driver !


Stage 2


Another interesting thing, is to see what are the inputs to the PetaLinux project. The test_proj_petalinux/project-spec/hw-description folder contains these inputs.




There we can check that are available:

- The HDF file which describes the custom hardware,
- The bitstream  to configure the PL, generally used by the FSBL,
- The ps7_init files to configure the ARM peripherals,
- And a drivers folder that contains the driver for our custom IP.

The only thing is that the driver content is the standalone one, we'll have to see how to handle it to make it compatible for Linux !!






Step 4 : Load our Linux onto the MiniZed board



Stage 1


Now that the PetaLinux tool has produced all the needed files, let's configure the board.

To bring the board to a configured state, a lot of stages have to be executed, here is the Linux Boot Process on a target platform.




A very important point to have in mind is that for each steps several solutions are available to do it !

As we are using the PetaLinux tool we will start by using the PetaLinux resources for booting the board.


Stage 2


As we are at the beginning of the design, we will use the JTAG as a straightforward tool to make the first tests with the board. But we will see that it is not the right solution for transferring large files, it takes too much time !

So, first thing to do check that the MiniZed board is configured for JTAG boot.




Stage 3


We will use the PetaLinux command to load and configure the bitstream file into the PL.

Don't forget to activate the VM's serial port (Xilinx JTAG + Serial) when you power up the MiniZed board.

Go to the PetaLinux project folder and use the following comand:




This command uses the system.bit file located in the /test_proj_petalinux/images/linux/ folder.

The Done Led of the MiniZed board shall be activated after about 20 seconds.


Stage 4


We will use the PetaLinux command to load and run the u-boot executable file from the PS.

Open a Putty terminal to have a look at the Linux Console terminal.

Go to the PetaLinux project folder and use the following comand:




The bitstream has to be loaded on its own, but the command launches all the following tasks :

This command uses the zynq_fsbl.elf file located in the /test_proj_petalinux/images/linux/ folder. This will load the file in memory and execute it to configure the ARM core.

This command then uses the u-boot.elf file located in the /test_proj_petalinux/images/linux/ folder. This will load the file in memory and execute it.

Once it is done we get the U-Boot execution prompt on the Putty terminal.




We can see that U-boot tries to load the kernel from the QSPI flah memory, but as it is not programmed, it fails.


Stage 5


We will use the PetaLinux command to load and run the Kernel file from the PS.

Open a Putty terminal to have a look at the Linux Console terminal.

Go to the PetaLinux project folder and use the following comand:




The bitstream has to be loaded on its own, but the command launches all the following tasks :

This command uses the zynq_fsbl.elf file located in the /test_proj_petalinux/images/linux/ folder. This will load the file in memory and execute it to configure the ARM core.

This command then uses the u-boot.elf file located in the /test_proj_petalinux/images/linux/ folder. This will load the file in memory and execute it.

This command then uses the system.dtb file located in the /test_proj_petalinux/images/linux/ folder. This will load the file in memory and provide the Device Tree to the Kernel.

And then, this command uses the zImage file located in the /test_proj_petalinux/images/linux/ folder. This will load the file in memory, it will be uncompressed to get the File System and the Kernel. Finally the whole Linux system can be launched !

Once it is done we get the U-Boot execution prompt on the Putty terminal.

As I said, it is quite long, for me it took 4'35 to complete. Obviously you won't use this when you need to made debug on this section !

Then we get the log of the Linux initialization.


Good to know :

UPDATE !!


I changed my USB Cable and there was a miracle !!!

The loading time reduced from 4'35 to 35 seconds !!!

So the USB cable's quality can change your life.




To log in use root:root.


Stage 6


We can see if our custom IP is still seen in the device tree with the command :




So yes, our led_test_ip is still available in the hardware.

We've done everything we had to for the hardware side.

Now we can do so much things in the software side !!!








Post Conclusion
Now we have :

- Customized the Zynq core IP to add the Linux neccessary resources,
- Checked the VIVADO project generation under Ubuntu,
- Checked the Hardware Platform generation under Ubuntu,
- Created the PetaLinux project,
- Generated the customized Linux,
- Booted the Linux system on our MiniZed board.

This is it. We've generated a Linux that knows our custom IP as a new physical peripheral.

Now we have to write some software to use our custom IP !