cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
3,782 Views
Registered: ‎04-20-2017

Axi Timer Bug DeviceTreeGeneration in Vivavdo/Petalinux 2017.4

Jump to solution

since we upgraded our design, vivado, petalinux to 2017.4  petalinux device tree generation fails as soon as the axi timer module is present.

 

closer examination showed, that in pl.dtsi (I am not sure on how the file is created exactly, aside from that it gets extrated during petalinux-build from the .hdf file) the clock frequency entry is messed up...

 

		axi_timer_0: timer@42800000 {
			clock-frequency = <1e+08>;
			clock-names = "ref_clk";
			clocks = <&clkc 0>;

it holds the right value, but in decimal instead of hex.  because of that petalinux-build cant parse the pl.dtsi and faild with error.

if I manually edit it after importing an hdf file, all works nice...but kills my automated build process...

 

jsut overwriting the entry over system.dtsi does not work...as the changes are applied after the pl.dtsi is parsed (which already causes the error and failing the build process)

 

any idea on where to fix this? Its very annying to manualedit the pl.dtsi after every hw import, which occus at every new build and make automated building impossible

 

 

 

1 Solution

Accepted Solutions
stephenm
Xilinx Employee
Xilinx Employee
3,778 Views
Registered: ‎09-12-2007

Hey Guys,

 

I have created a patch (for 2017.4) for the DTG to catch this, and covert from the exp.

 

To use this in Petalinux, you can copy the attached patch into your:

project-spec\meta-user\recipes-bsp\device-tree\files

 

Then update the device-tree-generation_%.bbappend, as shown below:

 

SRC_URI_append ="\
file://system-user.dtsi \
file://0001_clk_patch.patch \
"
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"

 

Then to test just use the command:

petalinux-build -c device-tree

 

This works for me, the pl.dts is created as expected:

axi_timer_0: timer@42800000 {
clock-frequency = <100000000>;
clock-names = "ref_clk";
clocks = <&clkc 0>;

 

Also, I dont get any compile issues in the DTC

 

 

 

View solution in original post

18 Replies
shabbirk
Moderator
Moderator
3,743 Views
Registered: ‎12-04-2016

Hi

 

Could you please share the axi timer entry of pl.dtsi and your modified system-user.dtsi, that is throwing the error? Actually you have to write the complete axi_timer device node entries in system-user.dtsi including the clock frequency change that causes the bug

 

Note:- Take care of syntax while writing in system-user.dtsi, should look something like this:-

/include/ "system-conf.dtsi"

{

axi_timer_0 {
	clock-frequency = <1e+08>;
	clock-names = "ref_clk";
	clocks = <&clkc 0>;
};

};

 

Best Regards

Shabbir

3,706 Views
Registered: ‎04-20-2017
Nono what I shared is already the excerpt of the pl.dtsi showing the relevant part of the axi timer.

The point is that already in the pl.dtsi the decimal value for frequency is written, regardless of the presents of any system-user.dtsi.


The system user dtsi approach was just one idea on workaround, which did not work bec the pl.dtsi is already causing the error before system-user.dtsi is touched. (I know how edit the device nodes with system user. Dtsi and I edit several entries in my design)
0 Kudos
stephenm
Xilinx Employee
Xilinx Employee
3,675 Views
Registered: ‎09-12-2007

The devicetree is created using the devicetree generator tool. This uses the HDF to extract the relevant information here.


The pl.dtsi is created first, but this can be over-layed by the system-user.dtsi.

 

/include/ "system-conf.dtsi"

{
    &axi_timer_0 {
       clock-frequency = <100000000>;
       clock-names = "ref_clk";
       clocks = <&clkc 0>;
     };
};

 

 

If you make the change here, then the plnx_aarch64-system.dts will be updated in components\plnx_workspace\device-tree\device-tree-generation to reflect this.

 

So, for example, update the system-user.dtsi, and rebuild the DT:
petalinux-build -c device-tree

 

Then check the components\plnx_workspace\device-tree\device-tree-generation\plnx_aarch64-system.dts to verify that the node was updated.

0 Kudos
3,598 Views
Registered: ‎04-20-2017

your proposed solution does not work.

 

when petalinux-build -c device-tree is started I can see that the pl.dtsi inside /components/plnx_workspace/device-tree/device-tree-generation...gets updated while petalinux-build -c device-tree is running.

The wrong decimal value is there then.

 

then petalinux-build -c device-tree  throws the error before!! any changes from system-user.dtsi get applied to it. petalinux-build -c device-tree never reaches the point where any changes of system-user.dtsi get applied, as the process fails already when parsing the pl.dtsi, not when doing anything with it...

 

 

0 Kudos
eazrael
Observer
Observer
3,538 Views
Registered: ‎05-19-2017

Same problem here. A fix in system-user.dtsi won't work as overloading a value won't remove the syntax error from pl.dtsi.

0 Kudos
3,479 Views
Registered: ‎04-20-2017
My workaround (still a nuisance as build process takes longer)
-import hw
-petalinux-build - c device tree (which fails, but regenerates the pl.dtsi)
-sed -i -e 's/<1e+08>/<100000000>/g' ./pl.dtsi
(modify pl.dtsi with SED command)
-petalinux-build (runs without error)
0 Kudos
stephenm
Xilinx Employee
Xilinx Employee
3,459 Views
Registered: ‎09-12-2007

if you send the hdf, ill create a DTG patch for you

0 Kudos
eazrael
Observer
Observer
3,439 Views
Registered: ‎05-19-2017

My HDF is attached to this message. I doubt there are any secrets in it. 

 

IMHO the VTC is also not generated correctly. It misses the clock information. But as this is no syntax error, overloading in system-user.dtsi is easy:

&v_tc_0 {
			clock-names = "s_axi_aclk";
			clocks = <&clkc 15>;
;

I tried to solve it myself, but I haven't found any code for VTC in the DTG at https://github.com/Xilinx/device-tree-xlnx. What is the relationship of the DTG in the github repo and the tools/hsm/data/embeddedsw/XilinxProcessorIPLib directory shipped with Petalinux? 

0 Kudos
stephenm
Xilinx Employee
Xilinx Employee
3,779 Views
Registered: ‎09-12-2007

Hey Guys,

 

I have created a patch (for 2017.4) for the DTG to catch this, and covert from the exp.

 

To use this in Petalinux, you can copy the attached patch into your:

project-spec\meta-user\recipes-bsp\device-tree\files

 

Then update the device-tree-generation_%.bbappend, as shown below:

 

SRC_URI_append ="\
file://system-user.dtsi \
file://0001_clk_patch.patch \
"
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"

 

Then to test just use the command:

petalinux-build -c device-tree

 

This works for me, the pl.dts is created as expected:

axi_timer_0: timer@42800000 {
clock-frequency = <100000000>;
clock-names = "ref_clk";
clocks = <&clkc 0>;

 

Also, I dont get any compile issues in the DTC

 

 

 

View solution in original post

stephenm
Xilinx Employee
Xilinx Employee
3,108 Views
Registered: ‎09-12-2007

To answer you other question, the DTG is downloaded from github:

https://github.com/Xilinx/device-tree-xlnx

 

The petalinux also uses some HSI utilities, but this is seperate.

 

 

The DTG is quite trivial really. It is TCL based, and uses the HSI utilities (mentioned above)

These HSI utilites are used to open the HDF, read the cell properties, get connections ect..

You can see these HSI commands:

https://www.xilinx.com/support/documentation/sw_manuals/xilinx2017_4/ug1138-generating-basic-software-platforms.pdf

 

I also created an AR a while back that will shed some light on this topic for you:

https://www.xilinx.com/support/answers/64980.html 

 

Anyway, back to the DTG...

If you are interested in see what goes on under the hood, you can get the DTG from github, and create a HSI script

to create the devicetree (this is how I tested the patch I created previously). I have created a wiki page that you can use here:

http://www.wiki.xilinx.com/ZCU102+Image+creation+in+OSL+flow

 

See the build device tree section. Note: the script uses psu_cortexa53_0, you would need to change this to ps7_cortexa9_0

 

The entry point in the DTG, is in the file below:

device-tree-xlnx\device_tree\data\device_tree.tcl

 

So, see the generate proc here. So, it will get all the driver (get_drivers). It will use the HSI to open the HDF,

and will get all the IP used here (hsi::get_cells *).

hsi.PNG

 

It will then cross check all the IP_NAME, against the supported_peripheral in the MDD for each driver. For example:

prop.PNG

 

Then the TCL code in each driver will be executed. However, most of the work is done in the generate proc mentioned above, and this is a good starting point for any debugging.

 

In relation to the VTC, I dont see the driver for this in the DTG. So, this would explain why this is missing

 

 

 

eazrael
Observer
Observer
3,100 Views
Registered: ‎05-19-2017

The patch works. Thanks :-) 

 

Any many thanks for the explanation of the DTG. I found some pieces through grepping and some through googling but in the end the deviations between the Github DTG and Petalinux version confused me. 

0 Kudos
stephenm
Xilinx Employee
Xilinx Employee
3,093 Views
Registered: ‎09-12-2007

I created a patch to add the vt node correctly. You can use this instead of the patch provided earlier.

0 Kudos
eazrael
Observer
Observer
3,068 Views
Registered: ‎05-19-2017

Same issue . BSP creation in the SDK also chokes on this:

 

"Running Make libs in ps7_cortexa9_0/libsrc/tmrctr_v4_4/src"
make -C ps7_cortexa9_0/libsrc/tmrctr_v4_4/src -s libs  "SHELL=CMD" "COMPILER=arm-none-eabi-gcc" "ARCHIVER=arm-none-eabi-ar" "COMPILER_FLAGS=  -O2 -c" "EXTRA_COMPILER_FLAGS=-mcpu=cortex-a9 -mfpu=vfpv3 -mfloat-abi=hard -nostartfiles -DDEBUG -O0 -g3 -Wall -Wextra"
"Compiling tmrctr"
In file included from xtmrctr_g.c:40:0:
../../../include/xparameters.h:478:40: error: invalid suffix "U" on floating constant
 #define XPAR_AXI_TIMER_0_CLOCK_FREQ_HZ 1e+08U
                                        ^
xtmrctr_g.c:52:3: note: in expansion of macro 'XPAR_AXI_TIMER_0_CLOCK_FREQ_HZ'
   XPAR_AXI_TIMER_0_CLOCK_FREQ_HZ
0 Kudos
dulloa7
Visitor
Visitor
1,941 Views
Registered: ‎03-05-2019

Your patch didn't work for me. Your second patch didn't work either. HOWEVER, I did fix your first patch for my needs:

 

+proc check_clock {clk} {
+ if { $clk == "9.9e+07" } {
+ return [file rootname "99999000"]
+ } else {
+ return $clk
+ }
+}
+

And it works just fine.

Thanks!

 

 

0 Kudos
mickh
Visitor
Visitor
332 Views
Registered: ‎07-21-2021

Hi @stephenm ,

I'm still running into this problem now, using petalinux 2020.2, trying to implement PWM with an AXI Timer 2.0 block.  My pl.dtsi includes the following snippet:

 

                axi_timer_0: timer@42800000 {
                        clock-frequency = <1e+08>;
                        clock-names = "s_axi_aclk";
                        clocks = <&clkc 15>;
                        compatible = "xlnx,axi-timer-2.0", "xlnx,xps-timer-1.00.a";
                        reg = <0x42800000 0x10000>;
                        xlnx,count-width = <0x20>;
                        xlnx,gen0-assert = <0x1>;
                        xlnx,gen1-assert = <0x1>;
                        xlnx,one-timer-only = <0x0>;
                        xlnx,trig0-assert = <0x1>;
                        xlnx,trig1-assert = <0x1>;

 

 

which the dtc (version 1.5) duly chokes on:

Subprocess output:
Error: ./project-spec/configs/../../components/plnx_workspace/device-tree/device-tree/pl.dtsi:56.24-25 syntax error
FATAL ERROR: Unable to parse input tree

Which corresponds to the clock-frequency.  Any chance this will be mainlined soon?

Cheers,

Mick

 

0 Kudos
stephenm
Xilinx Employee
Xilinx Employee
318 Views
Registered: ‎09-12-2007

@mickh can you share your XSA and I'll try on my end?

 

0 Kudos
mickh
Visitor
Visitor
305 Views
Registered: ‎07-21-2021

@stephenm I've attempted to attach it - it's quite large so I've split it into two with the GNU split utility, and I had to append .zip to try and match the mime types.  Let me know if you're unable to reconstitute it and I'll try another way

Note - only 1 of the attachments came through - I will try and post the other half in another post

Note 2 - the form is refusing the second half.  The content type matcher is broken, and by the looks of other messages has been for quite a while.  This message:

The attachment's design1.xsa.partab.zip content type (application/zip) does not match its file extension and has been removed.

doesn't make any sense.

Note 3 - it really doesn't like the second part - there is a slightly different structure to the first bytes but I don't know what the significance is.  @stephenm do you have any other way I can get the file to you?

0 Kudos
stephenm
Xilinx Employee
Xilinx Employee
294 Views
Registered: ‎09-12-2007

@mickh if you send me a PM with your email. I'll set up an ezmove

0 Kudos