cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Observer
Observer
9,280 Views
Registered: ‎05-28-2009

Error when building device tree - "set_drv_conf_prop"

I'm trying to build the device tree for the Zynq ZC702 targeted reference design, so that it will add my new HLS component.  

I'm on Vivado 2014.2, Ubuntu 14.04

I'm now using this tag of the device tree repo.https://github.com/Xilinx/device-tree-xlnx/tree/xilinx-v2014.2.01

 

My SDK log is reporting:

4:24:41 INFO  : 'device_tree' is a board support package for an OS for which applications cannot be developed within SDK.                                               
29314:24:41 INFO  : You can configure and build project 'device_tree_bsp_0' within SDK at will, but have to export it into the appropriate third party environment to devel$
29414:24:44 ERROR :  [Hsm 55-1545] Problem running tcl command ::sw_axi_vdma::generate : invalid command name "set_drv_conf_prop"                                           
295    while executing                                                                                                                                                      
296"set_drv_conf_prop $drv_handle C_INCLUDE_SG xlnx,include-sg boolean"                                                                                                     
297    (procedure "::sw_axi_vdma::generate" line 17)                                                                                                                        
298    invoked from within                                                                                                                                                  
299"::sw_axi_vdma::generate memory_axi_vdma_1"                                                                                                                              
300 [Hsm 55-1442] Error(s) while running TCL procedure generate()                                                                                                           
30114:24:44 ERROR : Error generating bsp sources: Failed to generate BSP.                                                                                                   
30214:24:44 ERROR : Failed to generate sources for BSP project device_tree_bsp_0                                                                                            
303org.eclipse.core.runtime.CoreException: Internal error occurred while generating bsp sources. Please check the SDK Log view for further details.                         
304        at com.xilinx.sdk.sw.ui.handlers.RegenBspSourcesHandler.internalGenerateBsp(RegenBspSourcesHandler.java:178)                                                     
305        at com.xilinx.sdk.sw.ui.handlers.RegenBspSourcesHandler.access$2(RegenBspSourcesHandler.java:163)                                                                
306        at com.xilinx.sdk.sw.ui.handlers.RegenBspSourcesHandler$1$1.run(RegenBspSourcesHandler.java:131)                                                                 
307        at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2344)                                                                                        
308        at com.xilinx.sdk.sw.ui.handlers.RegenBspSourcesHandler$1.run(RegenBspSourcesHandler.java:135)                                                                   
309        at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)                                                                        
                                                                                                                                                                            
                                                                                                                                                                            
             

 

 

I have looked at a number of threads such as http://forums.xilinx.com/t5/Embedded-Linux/device-tree-generate-error/td-p/482308 to no avail.

 

Not sure what to do next? Am I at least correct that I have to do this to compile my custom HLS module driver into the kernel?

0 Kudos
29 Replies
Highlighted
Xilinx Employee
Xilinx Employee
9,248 Views
Registered: ‎09-10-2008

Hi,

I don't know HLS well yet, but I do know Linux.

Did you try to run the design thru the flow before modifying anything to see if it worked?

It sort of appears you are trying to build the device tree in the Xilinx SDK rather than Petalinux, but maybe I'm wrong. The TRD design that you are trying to build uses Petalinux to do the work from what I can tell.

Thanks
John
0 Kudos
Highlighted
Observer
Observer
9,235 Views
Registered: ‎05-28-2009

Yes, I was able to build a bit file, a petlinux .bin image, and rebuild the software from the TRD and it all works.

 

First thing I wanted to be able to rebuild everything in the reference design and have it still work. I was able to do that. I regenerated the Vivado project and built a new bit file. I used the wiki instructions (http://www.wiki.xilinx.com/Zynq+Base+TRD+2014.2), installed the petalinux SDK, and built a new boot.bin image with the petalinux tools. I recompiled the Qt demo software application with the SDK. This was all able to work. 
 
Then I set about trying to insert a simple custom HLS video block, and work towards higher complexity. I inserted an always-on video inverter with no registers and rebuilt the bit file, regenerated the boot.bin with the petalinux tools, and that worked.  I used streaming flow control to avoid requiring any software interaction. (HLS #pragma HLS INTERFACE ap_ctrl_none register port=return)
 
I figured out how to modify the Qt GUI with Qt designer and was able to modify that and recompile and run that on the ZC702 board. 
 
Now I wanted to add a register setting to my HLS video inverter and use a new GUI checkbox to control it. This is where I am not quite sure how to proceed. I added the Axi-lite register port to the HLS component and connected it in IPI.
 
I know the userspace program has to probably use an ioctl() call to set registers in the new HLS component. I have the Sobel HLS filter from the reference design as a guide but this part is a little opaque to me. It seems to be using the Video 4 Linux (V4L2) library here, but I don't think that should be necesary for my block.
 
I thought I probably had to rebuilt the dts device tree to get my new device into the kernel, but maybe this happens automatically when I rebuild petalinux, based on your respons.  Maybe I just have to determine what arguments to pass in the ioctl call, and don't have to rebuild the dts tree in SDK at all?
 
So, if it's already in there, I believe it will show up as a uio device, but I'm not sure which one, and I'm not sure of the ioctl number, I don't see a header file that defines _IOW or anything like that.
 

 

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
9,223 Views
Registered: ‎09-10-2008

I believe that Petalinux is going to require you to re-run the petalinux-config --get-hw-description to update the dts file to match the new h/w.  I can't say I've done this yet.  I'm looking some at HLS as I don't know about the drivers that are provided for Linux to access the device.

 

Thanks,

John

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
9,218 Views
Registered: ‎09-10-2008

After a bit of digging and talking with others I understand what is being generated in HLS for drivers I believe. It is not generating any drivers that would allow you to do ioctl calls like you were thinking (unless I'm out in the weeds).

I have not inspected any generated code yet, but I know it's using the UIO driver framework so that users can then write code that is very similar to standalone rather than like a Linux device driver.

I've done some work with UIO and it's easy to use, but it seems like the HLS code that is generated maybe takes care of getting the UIO driver started and opened for you if you use their functions.

I would expect the device tree to show a node for the HLS component which has it's address and then a compatible string that may reference the UIO driver.

In another thread, referenced below, I attached a UIO doc I did if you want to know more of the details of how it works, but maybe that's too much information.

http://lwn.net/Articles/232575/
http://forums.xilinx.com/t5/Embedded-Linux/mmap-problems-device-tree-problem/m-p/523043/highlight/true#M10655

Thanks
John
0 Kudos
Highlighted
Observer
Observer
9,210 Views
Registered: ‎05-28-2009

OK, I regenerated the petalinux .bin image after running petalinux-config --get-hw-description with my hdf file location.

 

I booted the zc702 board with this image, and looked in /sys/class/uio.  There is only one device in there, uio0, which is mapped to the AXI performance monitor.  So I think my new device did not appear. Is there some other step I'm missing?

 

My full procedure after building the .bit file and exporting the hardware is this:

#!/bin/bash
source settings.sh
cd ~/ddc/zynq_kernel/zynq_base_trd_2014_2/subsystems/linux/configs/device-tree
petalinux-config --get-hw-description=/home/user/ddc/opengl/Implementations/zvik_ref/hardware/vivado/export_hw/
petalinux-build -c device-tree -x distclean
petalinux-build
cd ~/ddc/zynq_kernel/zynq_base_trd_2014_2/images/linux
petalinux-package --boot --fsbl zynq_fsbl.elf --fpga $ZYNQ_TRD_HOME/hardware/vivado/project/zynq_base_trd_2014.2.runs/impl_1/system_top_wrapper.bit --uboot --force

 

 

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
9,208 Views
Registered: ‎09-10-2008

Not that I know of, but I'm not an expert on this yet either. I'm assuming that it did regenerate the device tree (new files). I'm not seeing any examples in the docs of how to make this work and I'm not sure if it's a Petalinux issue or not.

A "petalinux-build -x distclean" could be worthwhile just to make sure everything got rebuilt ok.

It depends on what your urgency is, the device tree entry can be added manually (pretty easily if only a register) for now if you want to try to move forward while the details of this are being investigated more.

I'm told there is a known issue with the FSBL not getting updated ps7_init info when doing the petalinux-config like you did and that you need to remove the FSBL and let it re-create it to get it to update. I'm only discussing this as I notice there is an xparameters.h file in the FSBL and you could review it to see it it has your device definition in it.
0 Kudos
Highlighted
Observer
Observer
9,202 Views
Registered: ‎05-28-2009

It looks like my device is present in the xparameters.h in the fsbl code.

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
9,200 Views
Registered: ‎09-10-2008

In that case it sounds like there's a problem with the device tree generation and adding the entry manually is the easiest solution for that. It should be just the address of the register and the compatible string since there's nothing more to it.
0 Kudos
Highlighted
Observer
Observer
9,189 Views
Registered: ‎05-28-2009

I'm not sure where the .dts file is located? It's the dts file I should be editing?

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
8,923 Views
Registered: ‎09-10-2008

in the subsystems/linux/configs/device-tree dir of the petalinux project.

There is a pl.dtsi for the PL. I typically just add a new file that I then include in the system-top.dts file after the system-conf.dtsi. You typically reference the node above (in the hierarchy) where your new node is with a "&" followed by the node name.

For example.... here I was putting the phy details into the ethernet node. The ethernet node already existed.

&ps7_ethernet_0 {
phy-handle = <&phy0>;
mdio {
#address-cells = <1>;
#size-cells = <0>;
phy0: phy@7 {
device-type = "ethernet-phy";
} ;
} ;
} ;

The pl.dtsi may already have an example like this if there's anything in the PL.

If you need a bit of help with device trees see this doc below.

http://events.linuxfoundation.org/sites/events/files/slides/petazzoni-device-tree-dummies.pdf
0 Kudos
Highlighted
Observer
Observer
8,918 Views
Registered: ‎05-28-2009

Actually, the pl.dtsi file does have an entry for my device:

 

     processing_vid_invert_0: vid-invert@43c00000 {              
                       compatible = "xlnx,vid-invert-1.0";                 
                       reg = <0x43c00000 0x10000>;                        
                       xlnx,s-axi-control-bus-addr-width = <0x5>;          
                       xlnx,s-axi-control-bus-data-width = <0x20>;         
               } ; 

 

Does the uio device get created automatically, or is something else missing?

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
8,914 Views
Registered: ‎09-10-2008

The UIO driver is already loaded and it will create the device node for you if you change the compatible to use the UIO framework. The compatible needs to be "generic-uio".

Then you should see two UIO devices (assuming the performance monitor still too) and you could take the code that HLS generates and make a petalinux application with it based on what I read.
0 Kudos
Highlighted
Observer
Observer
8,909 Views
Registered: ‎05-28-2009

OK, so I take the HLS driver and use that code in my own program, it's not getting sucked into the kernel.

 

OK, so if I edit the pl.dtsi to change the compatible parameter to generic-uio, that would have to be done manually every time I regenerate the system and run petalinux-config?  

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
8,907 Views
Registered: ‎09-10-2008

That's the reason to add a new dtsi file and then override that property so that you don't lose it when it automatically generates a device tree.
Hopefully that makes sense, the overriding a property. In other words you can specify a property multiple times in multiple dtsi files and the last one is the one that is used in the final device tree.
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
8,906 Views
Registered: ‎09-10-2008

To my knowledge no code is getting sucked into the kernel for you as UIO is for user space and the code generated for you in HLS is to allow you to write a user space app to talk to the device.
0 Kudos
Highlighted
Observer
Observer
8,900 Views
Registered: ‎05-28-2009

OK,

 

Now, my system-top.dts is a ln to zynq-zc702-base-trd-fmc.dts as described in the wiki instructions. It doesn't include system-conf.dtsi, or any other file.

 

I should /include/ my.dtsi in there still? 

 

 

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
8,880 Views
Registered: ‎09-10-2008

It looks to me like that should work, but I can't say I'm an expert on the TRD.
0 Kudos
Highlighted
Observer
Observer
8,867 Views
Registered: ‎05-28-2009

It seems to have found the node I was inserting, because if I change my file it says it doesn't find it. But the uio1 device hasn't appeared when I boot the zc702 board.
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
8,862 Views
Registered: ‎09-10-2008

You should dig thru the device tree in /proc/device-tree with the running system and see if you find the node you added. Some properties can be seen with cat, others need hexdump -C to see them. I'm reviewing the UIO doc I referred you to to make sure I didn't forget something.
0 Kudos
Highlighted
Observer
Observer
9,593 Views
Registered: ‎05-28-2009

In the pl.dtsi file, the reference design HLS component, a Sobel filter, is referred to like this:

processing_image_filter_1: image-filter@400d0000 {
			compatible = "xlnx,image-filter-1.0";
			interrupt-parent = <&ps7_scugic_0>;
			interrupts = <0 58 4>;
			reg = <0x400d0000 0x10000>;
			xlnx,s-axi-control-bus-addr-width = <0x9>;
			xlnx,s-axi-control-bus-data-width = <0x20>;
		} ;

 Howevver, when I poke around in the real system there seems to be a device tree node called 

axi_hls@400d0000

compatible: xlnx,axi-hls-sobel.xlnx,axi-hls

 

Does this suggest that maybe the device tree I'm editing on my workstation is not getting used in the image, and some other device tree is? 

0 Kudos
Highlighted
Observer
Observer
9,591 Views
Registered: ‎05-28-2009

Actually, the system-top.dts defines it that way, so maybe my previous post is mistaken.

 

Maybe I'll try adding an entry directly to the system-top.dts.

 

Since there are no includes in it, it seems possible that the pl.dtsi and other .dtsi files aren't being used at all?

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
9,587 Views
Registered: ‎09-10-2008

It's hard for me to understand what all is happening as I'm not trying to replicate it on my end, hoping to help you understand the normal way things work as the TRD may be a bit different.

The dtb file for the device tree is in the images/linux directory and can be uncompiled to verify what was built into the image. The device tree compiler (dtc) is located in your petalinux install but wasn't in the path last time I did this (uncompiled a dtb). I had to add it to the path after finding the executable.

You can do something like "dtc -I dtb -O dts -o test.dts system.dtb" assuming it's system.dtb which it usually is. Then you'll have a next text file that is the original dts file minus some labels/names that can't be reverse compiled.
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
9,569 Views
Registered: ‎09-10-2008

Here's what I hear from the TRD team about the TRD and device trees:

 

We’re not using dt generator for the TRD. Our devicetrees are handcrafted. We create a dt node for the HLS generated sobel filter that follows the v4l2 dt structure and model, for other cores uio might be the right framework. It also depends on what driver you are using of course e.g. we also don’t use the generated uio driver since we’re doing video and v4l2 is the framework of choice. 

0 Kudos
Highlighted
Scholar
Scholar
9,561 Views
Registered: ‎09-05-2011

Just wanted to add that we did have issues in PetaLinux device tree generation for some IPs. A list of those IPs can be found in the following AR:
http://www.xilinx.com/support/answers/60970.html
0 Kudos
Highlighted
Observer
Observer
9,555 Views
Registered: ‎05-28-2009

OK, this all makes sense. There's just the one hand-crafted .dts file that is being included.  I added my device to that one.

 

I still wasn't seeing it but that was because I wasn't coping over the image.ub file to the sd card, which is where the device tree is located. I wasn't copying it because the reference design QT app crashes with my built image.ub file, and was doing that before.

 

Long story short: regarding this thread, if I copy over the image.ub file I can actually see my own HLS UIO device appear in /sys/class/uio now. So the original problem I started with is now resolved and making sense.

 

However, I still have to resolve this crash because I need that to work since my video IP is in the same path as the Sobel reference HLS IP.  I think the image.ub file is just a dtb blob, so I should be able to decompile it with dtc and compare the prebuilt one that works with the one I have and see what's different.

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
9,553 Views
Registered: ‎09-10-2008

Good, that's progress.  

 

The image.ub is the kernel image with a ramdisk and device tree dtb built into it and there's no way to unroll those images from that one image (that I know of or easily).

 

I'm still not clear what your issue is as it sounds like something is not getting built right with the kernel? I'm assuming it's using the wrong device tree is what you mean.

 

If that's true, you just need to understand what device it is using and alter the correct one.

 

Thanks

John

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
9,550 Views
Registered: ‎03-13-2012


linnj wrote:

The image.ub is the kernel image with a ramdisk and device tree dtb built into it and there's no way to unroll those images from that one image (that I know of or easily).

 


U-Boot comes with a dumpimage utility. I don't know whether it works with FIT-, but I tried it with legacy images.

https://github.com/Xilinx/u-boot-xlnx/blob/master-next/tools/dumpimage.c

0 Kudos
Highlighted
Observer
Observer
9,546 Views
Registered: ‎05-28-2009

Thanks, I'll try that.

 

I'm not sure what the issue is now either. 

 

When I turn on the Sobel filter with the image.ub I generate myself, the app exits and I get a shifted console on the screen (3/4s off the screen), and on the uart it says:

[info] :: HDMI input resolution 0x0
[info] :: HDMI input resolution 0x0
ERROR(../src/mediactl_helper.c:169) : Unable to setup formats: Invalid argument (22)

 

I just thought that perhaps there was some difference between the prebuild device tree and the one I was using, which is still the TRD handcrafted one as far as I know.

0 Kudos
Highlighted
Observer
Observer
9,530 Views
Registered: ‎05-28-2009

It doesn't work with FIT.

 

dumpimage: extract_datafile undefined for FIT Image support

0 Kudos