01-05-2015 02:19 PM
I've just set up a new development environment which includes Vivado, SDK and Peta-Linux Tools, all 2014.4 on Linux.
I've also installed the Zedboard BSP, Avnet-Digilent-ZedBoard-2014.4, and am attempting to config+boot one of the pre-built images using the command 'petalinux-boot --jtag --prebuilt 3', at which point I get the following error message,
INFO: Configuring the FPGA... INFO: XMD commands is shown as follows. fpga -f "/<snip>/Avnet-Digilent-ZedBoard-2014.4/pre-built/linux/implementation/download.bit" after 2 INFO: Downloading bitstream to the target. rlwrap: warning: your $TERM is 'xterm' but rlwrap couldn't find it in the terminfo database. Expect some problems.: Inappropriate ioctl for device ****** Xilinx Microprocessor Debugger (XMD) EngineExecuting user script : /tmp/tmp.LHBNXdTQlo Error Executing User Script : /tmp/tmp.LHBNXdTQlo Error :: ERROR: Connection to Board Failed Unknown Error Occured Cable is not connected to the host ****** XMD v2014.4 (64-bit) **** SW Build 1071353 on Tue Nov 18 16:44:35 MST 2014 ** Copyright 1986-2014 Xilinx, Inc. All Rights Reserved. ERROR: FPGA configuration failed.
I'm not sure what exactly the warning about readline is saying, or if it is relevant to my issue, but as you can see the tool is failing at the configuration stage. It complains about the board not being connected, however this is clearly not the case as I can configure it perfectly fine with that bitfile using the XMD console manually.
Maybe I'm missing something simple. The board jumpers are set to JTAG mode, the cables are connected and working, the environment settings files for vivado, sdk and petalinux-tools have all been sourced, and the board can be configued manually without error. I don't have any more debugging information to go on, nor do I actually know what the script the tool is failing on is doing, because it deletes the temp file before I can get a look. At this point I don't know enough about how the tool works to take a stab at what where the breakage might be occurring, so I would appreciate any insight somebody might have. Thanks.
01-05-2015 04:32 PM - edited 01-05-2015 04:49 PM
Have you tried to connect to the processor using XMD/SDK?
What is the usage of your home drive? I have seen some similar error message when my home drive in linux was full
01-05-2015 05:23 PM
01-05-2015 08:45 PM
01-05-2015 10:41 PM
01-06-2015 02:02 PM
Thanks for the replies guys.
Achutha -- The board is a Zedboard, ZC702 is just a typo. I meant 7Z020, i.e. the part name. The board is connected using the Digilent USB-JTAG port, I believe it's the same as the one on the ZC02.
NOTE: If it's possible for someone to amend the title of this thread to remove that typo, it might help with people's searches in the future. I don't seem to be allowed to do edits.
Smarell -- I've tried both things you mention in (1); no effect. Re: (2), I usually use the XMD through the SDK as that is usually where I am when I run into these issues. I'll see if using standalone XMD makes a difference when I get back to the lab.
There's been a development, however. Just before I left last night I noticed that the situation is actually closer to the following:
1. If I reboot and run Vivado/SDK/XMD, the tools work as expected without any issues.
2. If I use JTAG via Vivado/SDK and then try to use petalinux-boot while those tools are still open, it fails with my previously stated error. (this seems like it might be expected behavior, although I can't really comment on that).
3. If I try (2), but first close Vivado/SDK, petalinux-boot succeeds in configuring the device, but fails later when it tries to load the kernel image. It's possible that the later failure is a separate issue, I have to investigate further.
4. If I try to petalinux-boot immediately after reboot without using any other tools, I get the same behavior as (3).
5. The kicker: in any of those the situations 2-4, once petalinux-boot fails I can't connect to the board any more using any tool until the computer is rebooted. It feels like a dangling pid/lock/whatever is left behind after the failure. Still no idea what is actually *causing* the failure.
01-07-2015 12:56 PM
01-07-2015 04:49 PM
stephenm -- If petalinux-boot fails, disconnecting the cable from XMD like you suggest doesn't work.
XMD% xdisconnect -cable X 0#Cable Disconnected $ XMD% exit
XMD% fpga -f "<snip>/Avnet-Digilent-ZedBoard-2014.4/pre-built/linux/implementation/download.bit"
ERROR: Connection to Board Failed
Unknown Error Occured
Cable is not connected to the host
It claims it's disconnected, but neither XMD nor any other tool can talk to the board. I never had any issue like this until I tried to use the petalinux tools, even without explicitly closing XMD cable sessions.
So like you say, one problem/symptom is likely a cable issue with some lock not getting released. I don't expect to be able to use the JTAG resource from multiple tools simultaneously, however it seems to me that there are still two issues:
1. Even when petalinux-boot succeeds in configuring the PL+PS, it subsequently fails to load the kernel image (if I am trying to boot to a runlevel '3'). As I mentioned above, it's possible that this is a separate issue, but it might also be the same/related to the cable problems. For example, maybe does it start one session to configure the fpga, which succeeds, close that session (or fail to do so), and then fails while attempting to start a new session to load the zimage?
2. Even if it's expected behavior for the cable resource to not be released when a tool fails--unfortunate design as that might be; the reality is that sometimes things fail, and we can't go rebooting every time some closed source tool kicks the bucket for mysterious reasons--there is still something *causing* the failure in the first place. I assume petalinux-boot isn't designed as a one-time-use tool ;-)
To clarify, if I reboot clean, run petalinux-boot at runlevel 1 and it works, then try again, it breaks. So even if I could alleviate the intertool problems by disconnecting with the XMD console (which I can't), something is still breaking. Does that make sense, or am I not getting something you're saying?
01-13-2015 11:22 AM
Nobody has any further suggestions for debugging this? The embedded side of my development has pretty well come to a standstill, and I don't really have much insight into the toolchain, so it's really just shots in the dark on my end. Maybe some specific permissions that need to be set?
01-20-2015 03:17 PM
I stumbled across this thread looking for info about the "rlwrap: your $TERM is xterm....:expect some problems."
I am using a ZC706 board, but I get the above warning, and then my board configures fine. This doesn't necessarily help you, but based on my getting the same warning, and then not having a problem programming, I'd suspect that the warning isn't part of the problem you are seeing.
01-22-2015 02:46 PM
In regards to being able to boot to runlevel 1 but then the kernel image download failing, this thread might be useful: