<div dir="ltr"><div>Hi Ric, and sorry for the late reply!<br></div><div>spent some more time with this board and managed to run some executables following your advice of running the bootelf command in uboot.<br></div><div>BTW: I've successfully managed to run executables using both the upstream and the xilinx versions of uboot.<br><br></div><div>I think I will try again to find out the correct workflow for converting the ELF files with mkimage and avoiding bootelf: at the moment this is more than fine though.<br><br></div><div>Thanx alot for your help<br></div><div>Davide<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-10-09 2:13 GMT+02:00 Claus, Ric <span dir="ltr"><<a href="mailto:claus@slac.stanford.edu" target="_blank">claus@slac.stanford.edu</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
  I don’t know whether your question is still unresolved, but I’ve recently done similar things with a standard Zedboard.  However, my pattern was a little different:<br>
<br>
fathead mmc 0:5 0x3000000 hello.exe<br>
bootelf -p 0x3000000<br>
<br>
where hello.exe is just the elf image that is produced by the normal build process (i.e., no objcopy, and no mkimage).  The 0:5 is just the 5th partition on my SD card.<br>
<br>
  I was similarly struck by the no output question, but I realized that this is probably because after the program exits, bp_reset() is called, which hits the chip reset.  This happens so fast that for me I see only the first few characters the test harness puts out.  The UART never manages to get the results of the printf statements of hello.c out (see the attachment).  I thus went on to other programs that have a longer life cycle, like ticker.exe and capture.exe.  Both of those behaved properly, so I have some confidence that my explanation for not seeing output from hello.exe is correct.<br>
<br>
  The second thing I notice indoor dump is that control is being transferred to address 00000000.  That doesn’t look right, but I’m not clear on why you’re getting it.  Maybe something to do with how you’re preparing the image?  Possibly you’ve picked a load address (0x01000000) that conflicts with where your u-boot image resides?<br>
<br>
  Hopefully, something here helps you.<br>
<br>
  Cheers,<br>
                Ric<br>
<br>
</blockquote></div><br></div>