RTEMS on Zynq Microzed

Claus, Ric claus at slac.stanford.edu
Fri Oct 9 00:13:08 UTC 2015


Hi,

  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:

fathead mmc 0:5 0x3000000 hello.exe
bootelf -p 0x3000000

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.

  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.

  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?

  Hopefully, something here helps you.

  Cheers,
		Ric

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dump.txt
URL: <http://lists.rtems.org/pipermail/users/attachments/20151009/a485129c/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ATT00001.txt
URL: <http://lists.rtems.org/pipermail/users/attachments/20151009/a485129c/attachment-0001.txt>


More information about the users mailing list