cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
6,623 Views
Registered: ‎04-24-2017

petalinux-build fails on device-tree generation

Hi,
I can't build petalinux for the MicroZed. I always get this error when it gets to the device tree generation. This error doesn't provide me with any clue as to what is wrong.
Any help would be greatly appreciated.

 

Thanks!


~F

 


ERROR: [Common 17-167] Type error

ERROR: [Common 17-39] 'rdi::col_lreplace' failed due to earlier errors.

ERROR: [Hsi 55-1545] Problem running tcl command ::sw_device_tree::post_generate : ERROR: [Common 17-39] 'rdi::col_lreplace' failed due to earlier errors.

 

while executing

"lreplace $all_drivers $first_occur_pos $first_occur_pos $console_element"

("foreach" body line 12)

invoked from within

"foreach drv_handle $all_drivers {

set alias_str [get_property CONFIG.dtg.alias $drv_handle]

if {[string match -nocase $alias_str "serial"]} {

i..."

(procedure "update_alias" line 25)

invoked from within

"update_alias $os_handle"

(procedure "::sw_device_tree::post_generate" line 3)

invoked from within

"::sw_device_tree::post_generate device_tree"

ERROR: [Hsi 55-1443] Error(s) while running TCL procedure post_generate()

generate_target failed

while executing

"error "generate_target failed""

invoked from within

"if {[catch {hsi generate_target -dir $project} res]} {

error "generate_target failed"

}"

(file "/home/petalinux/TESTPROJECT/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/device-tree-generation/xilinx+gitAUTOINC+11f81055d1-r0/dtge..." line 33)

WARNING: /home/petalinux/TESTPROJECT/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/device-tree-generation/xilinx+gitAUTOINC+11f81055d1-r0/temp/run.do_configure.17298:1 exit 1 from 'eval xsct /home/petalinux/TESTPROJECT/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/device-tree-generation/xilinx+gitAUTOINC+11f81055d1-r0/dtgen.tcl -ws /home/petalinux/TESTPROJECT/build/../components/plnx_workspace -pname device-tree-generation -rp /home/petalinux/TESTPROJECT/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/device-tree-generation/xilinx+gitAUTOINC+11f81055d1-r0/git -processor ps7_cortexa9_0 -hdf /home/petalinux/TESTPROJECT/build/tmp/deploy/images/plnx_arm/Xilinx-plnx_arm.hdf -arch 32 ${APP_ARG} ${MISC_ARG}'

ERROR: Function failed: do_configure (log file is located at /home/petalinux/TESTPROJECT/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/device-tree-generation/xilinx+gitAUTOINC+11f81055d1-r0/temp/log.do_configure.17298)

0 Kudos
16 Replies
Highlighted
6,430 Views
Registered: ‎04-10-2015

Hi itco0001, 

Hi Xilinx Support,

 

Same here, but while building for zynq...

 

Did not find any resolution so far, this blocking...

 

Thanks in advance for any support!

0 Kudos
Highlighted
6,426 Views
Registered: ‎04-10-2015

It seems that another post relates to this already: https://forums.xilinx.com/t5/Embedded-Linux/Petalinux-2017-1-Generate-Device-Tree-Error/td-p/764415

 

But no solution so far.

0 Kudos
Highlighted
Moderator
Moderator
6,391 Views
Registered: ‎12-04-2016

Hi All

 

Can you please try this:

 1. Go to <petalinux_proj> directory and remove the below directories:

  1. rm -rf components/plnx_workspace/
  2. rm -rf build/cache build/tmp

Do the re-build

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
6,309 Views
Registered: ‎10-06-2016

Hi @tico0001 and @sylvain.ellisys

 

An AR has been posted addressing this issue:

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

 

Looks like the fact of using uart1 as a console it's making the build process fail.


Ibai
Don’t forget to reply, kudo, and accept as solution.
0 Kudos
Highlighted
Visitor
Visitor
6,299 Views
Registered: ‎04-24-2017

Hi @sylvain.ellisys and others. I'm not using UART1 so that didn't solve any issues for me. I read on another thread that activating both UART0 and UART1 might be a workaround.

 

As for me, I ended up moving to 2016.2 and everything works great.

 

~Tico

0 Kudos
Highlighted
Visitor
Visitor
6,293 Views
Registered: ‎04-24-2017

@shabbirk Since I had already moved to 2016.2 I did not get a chance to try your solution. Hopefully @sylvain.ellisys can try it out.

 

~Tico

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
6,290 Views
Registered: ‎10-06-2016

Hi @tico0001

 

Could you post how does look like the end your system-top.dts file? I mean the code where bootargs and aliases are defined? I mean as in some other post I saw that aliases where switching the uart numbers so that may be causing an issue too.


Ibai
Don’t forget to reply, kudo, and accept as solution.
0 Kudos
Highlighted
Visitor
Visitor
6,286 Views
Registered: ‎04-24-2017

Unfortunately, since I moved to 2016.2 I don't have the other files. I'm staying on 2016.2 for a while since it's working with no issues.
0 Kudos
Highlighted
6,286 Views
Registered: ‎04-10-2015

Hi @tico0001,

 

Thank you for the message.

 

Yes: with 2016.2 everything's work smooth and nice. Very unfortunately I have to move to 2017.1, so I have no choices but to find a solution.

 

I already had to manually port all my custom 2016.2 Makefiles to 2017.1 recipes (that wasn't trivial), and now that rootfs eventually builds correctly, I hit this device-tree issue... This is a bit annoying.

 

We also need to have control over what we do with UART: we cannot simply activate all of them in order to please the device-tree script: activating 0 or 1 or both has serious impact on our system.

 

I really hope someone from Xilinx will provide a fix soon!

0 Kudos
Highlighted
Newbie
Newbie
5,153 Views
Registered: ‎05-10-2017

Hi,

     I've run into exactly the same problem (same set of errors).  I'm using a Digilent Zybo board, and, since I wanted to do more than simply load a prebuilt Linux image onto the ARM core, I built the Digilent "Linux_bd" project in Vivado 2015.4, then opened the project in Vivado 2016.4.  After updating the IP (and correcting a couple of errors caused by the update process), I ran synthesis and implementation, generated the bitstream, and exported the hardware design from Vivado.  All of this appeared to work fine.

     Using PetaLinux 2016.4 (to match the Vivado version 2016.4), I created a Petalunux project (using petalinux-create) and configured it (using petalinux-config).  I then ran petalinux-build to build the Linus kernel, U-Boot, the Device Tree, etc.  Petalinux-build ran for a long time, building the kernel, etc., but eventually failed with the exact same set of errors shown above.  After checking what files had been generated, it appears that the process failed prior to creating a .dts (Linux Device Tree Source) file.

  The key error appears (to me at least) to be the "Type error" returned apparently during the "hsi generate_target" command.  I suspect that this means that the "generate_target" code ran into something in the .hdf (hardware description) file that it did not like.  I've taken a brief look at that file using the Microsoft XML Notebook XML file viewer, but I really can't identify what might be wrong (if indeed the problem is actually in this file).  Any clues would be greatly appreciated.  Thanks!

0 Kudos
Highlighted
5,141 Views
Registered: ‎04-10-2015

Hello @shabbirk,

 

Thanks a lot for the suggestion, but this doesn't solve anything, same issue when I petalinux-build -c device-tree right after the to rm you suggested.

 

Actually I know have an .hdf that exhibits the problem and another one that doesn't (everything build fine)!

 

But I still cannot share any of them.

 

I am trying to identify which part of the bad one is causing the build issue.

 

Any hint on how to find the issue in the haystack here?

0 Kudos
Highlighted
Moderator
Moderator
5,130 Views
Registered: ‎12-04-2016

Hi

 

In your design, make sure to add atleasr 1 UART and I2C instances, and give a try.

 

 

Best Regards

Shabbir

0 Kudos
Highlighted
5,130 Views
Registered: ‎04-10-2015

Here is what I found:

 

a) in the non working HDF, the .tcl file contains:

CONFIG.PCW_EN_UART0 {1} \
CONFIG.PCW_EN_UART1 {0} \

 

b) in the working HDF, the .tcl file contains:

CONFIG.PCW_EN_UART0 {1} \
CONFIG.PCW_EN_UART1 {1} \

 

petalinux-build -c device-tree fail with the known error when I first run petalinux-config --get-hw-description=../hdf-source with the non working HDF file inside folder "hdf-source" 

petalinux-build -c device-tree is successful with the working HDF file inside folder "hdf-source" . In this case the resulting pcw.dtsi (inside components/plnx-workspace/device-tree-generation) contains:

&uart0 {
device_type = "serial";
port-number = <1>;
status = "okay";
};
&uart1 {
device_type = "serial";
port-number = <0>;
status = "okay";

 

So with crossed 0 and 1.

 

With the non working HDF, this pcw.dtsi is not generated at all.

So it seems that indeed the whole issue is related to UART and that enabling both "solves" the problem.

Now the questions that remains are:
- How shall I do if I really need to have only one single UART?
- How this 0/1 criss-crossing will affect the behavior of my system? I didn't test is yet, but will everything I print on UART0 appear on UART1 pins (and the opposite)? Not very convenient since I extensively use UART0 ...

 

Is Xilinx planning to fix this bug somehow soon?


Any help appreciated.

 

Highlighted
Newbie
Newbie
5,055 Views
Registered: ‎05-10-2017

Unfortunately, in my case, the above situation involving the UARTs does not seem to be the problem.

 

In my case, the corresponding lines in the .tcl (extracted from the .hdf file) are as follows:

 

CONFIG.PCW_EN_UART0 {1}  \

CONFIG.PCW_EN_UART1 {1}  \

 

In my case, no pcw.dtsi file was generated (similar to the "non-working" case above).

 

It appears that my problem is probably very similar (since the exact same errors are generated), but not originating in the exactly the same place.  It looks like we need some help from Xilinx to fix this.

0 Kudos
Highlighted
5,046 Views
Registered: ‎04-10-2015

Sorry to here this @mkwilinski ...

 

I feel I just found a working HDF by chance, and it might well break again the next time I do some modification to my design.

 

This is definitely not how I wish I have to work.

 

We need Xilinx help indeed.

0 Kudos
Highlighted
4,950 Views
Registered: ‎04-10-2015

Hi everyone,

 

I think that a (temporary?) solution might be (for those who can) to enable 2 UARTs (+some I2C is seems) in HDF, and then to correct the generated UART inversion issue using system-user.dtsi, in the way trimble_pome do it here: https://forums.xilinx.com/t5/Embedded-Linux/Petalinux-v2017-1-device-tree-and-serial-ports/m-p/764945#M19692

(thanks to him).

0 Kudos