Actions
Forum Thread Details
  • State Not Answered
  • Replies 5 replies
  • Subscribers 355 subscribers
  • Views 416 views
  • Users 0 members are here
Related

Zedboard can't run progream

Former Member

  I'm a newbie to Zedboard,and now I have met some problems, but I don't know what's wrong . I have tried to move linux on Zedboard, and I have followed the tutorial on Zedboard.org support-Reference Designs/Tutorials-Ubuntu Desktop Linux.
  Now, my board can start Linux with HDMI signal out .That's what I want .And common orders like rm,ls etc also wokrs well. But when I wrote a program to test , something wrong happened.
  I have written a simple program that just used a printf .I used the cross comoiler arm-xilinx-linux-gnueabi-gcc to compile it in the VMware,and then I put it into the Zedboard. But when I ran this program on the board, I didn't see any messages that should printed by the printf in the terminal. Also,there is no messages to show that the program is wrong. The program is just run ,and printf nothing. I have no idea what's wrong with it, so I wrote another program which used fprintf to write "hello world" into an empty txt file. I also use cross compiler to compile it ,and ran it on the board. This time , after running, I saw nothing in the empty txt file,and I think the program may just not run at all.
  by the way ,all the functions of the two programs were tested to be right.
  so I want to know what's wrong with it ?maybe the file uImage is  lack of  some function? or there are some other questions?
  Thanks in advance.

  • 0

    Hi flag1234,

    Could be something basic like a libc compatibility.  I think that the Ubuntu Desktop binaries get built with the Linaro GCC cross compiler.

    Since you have Ubuntu Desktop Linux running on ZedBoard, you should be able to use the native Linaro ARM compiler on your ZedBoard to try and build your application (and then run it) all from ZedBoard without using your PC to cross compile.

    Regards,

    -Kevin

  • 0 in reply to zedhed

    Hi Kevin,
    I have tested to run a problem just used the board witoout PC, this time ,it can run as it should .But I found it a little difficult to edit C source files on the board because the linux system sometimes not worked so good as PC has. If I can edit files on PC VMwares and then compile them ,and run on the board, it will be great . so I still hope if there is a cross compiler I can use . Do you have any ideas ?
    Thanks in advance.

  • 0 in reply to Former Member

    sorry,it's my fault to spell 'program' as 'problem' in the first sentence .

  • 0

    Kevin is correct that the version of glibc differs between the host build environment and the target.  The problem is really that the target system is built from a much more recent version of Linux than the host system, and requires a minimum glibc of 2.19, while the host builds executables with 2.17.  The result is that the executable is created with a requirement for a runtime that does not meet the minimum requirements of 2.6.32 for the target;  in fact I think you'll find it is looking for 2.6.16. 

    You can use the file command ("file <executable>) on both host and target to verify the differences in an executable.  You can also use the ldd command (ldd - - version) to check what runtime is required by the build system.

    Unfortunately, from some online research, it appears that updating the tool-chain on the host is non-trivial, and in fact several places recommend that you upgrade the entire OS to a level that supports the runtime you need on the target.  This is often not possible when the embedded target is running a modern kernel, well ahead of the latest LTS release.  There is some information that indicates it is possible to install a parallel tool-chain on an older Linux OS, which would circumvent the problem, but again details on the procedure are not readily available.  At least, not in the time I had to look.

    There are two possible alternatives, and Kevin has already pointed out one of them, which is building directly on the target.  The second is to link statically, which allows you to build on the host, but creates an executable many times larger than its dynamic counterpart.  In fact, the hello example I tried was 100X larger.   However, if all you are concerned about is developing, you could do this on the host and test on the target (by copying to the ext4 file system on the microSD, or using an NFS mount (preferable for development)).  And when you have everything working as you want, you can build the final on the target to get a much smaller dynamic executable.

    To link statically, simply add the -static option to your build step.

    If you have time, one other thing you could try is to use the Linaro tool-chain that is installed on an Ubuntu development host.  I don't know if the latest host version available (14.04) has a new enough library version or not.  Perhaps someone on this forum might contribute the answer to that?

    Ron

  • 0

    Hi Ron
    First thank you very much for your advice. I will try to solve the problem follow your comment. Once I have some findings, I will update on this forum.
    Thanks a lot.