RTEMS on Zynq Microzed

[Davide Viti]

Hi Ric, and sorry for the late reply!
spent some more time with this board and managed to run some executables
following your advice of running the bootelf command in uboot.
BTW: I've successfully managed to run executables using both the upstream
and the xilinx versions of uboot.

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.

Thanx alot for your help
Davide

2015-10-09 2:13 GMT+02:00 Claus, Ric <claus at slac.stanford.edu>:

> 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 HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20151112/005b50f8/attachment.html>