Zynq and 4.11 dynamic loader

Tue Sep 8 23:07:57 UTC 2015

On 9/8/2015 5:26 PM, Pavel Pisa wrote:
> Hello Mathew,
>
> On Tuesday 08 of September 2015 16:26:24 Mathew Benson wrote:
>> I understand 4.11 has dynamic loader support, but only for PowerPC and
>> MIPS(?).  Does anybody have dynamic loading working on the Zynq ARM?
>
> there are sources for runtime dlopen for arm, i386, m68k,
> powerpc, bfin, lm32, mips, sparc, h8300, m32r, moxie
> and v850 included in RTEMS-4.11 rtems/cpukit/libdl.
> I am not sure about status, dl01 and dl02 tests
> are disabled only for some lm3s3749, lpc23xx and lpc2362
> targets.

Good answer. :)

The sources are there but not all are working. The cpukit/configure.ac
disables the architectures which don't pass dl01 in general.

https://git.rtems.org/rtems/tree/cpukit/configure.ac#n380

That's bfin, h8300, lm32, and v850. Each has a specific ticket number
in a comment disabling it.

The tests do often find themselves disabled on BSPs which don't
have enough RAM to run them. That's why some of the small ARM
boards have it disabled at the testsuite level.

> I have tested dlopen on i386 and arm in last week
> to check what can be done with it and to find
> memory requirements etc. Chris and others are much
> more competent in this topic but I present results
> of my playing there with hope that it could be
> usesfull for somebody else.

I honestly have no idea on memory requirements. Chris would
be the one to answer that. Ultimately, you have to have memory
to write the code into. :)

I can tell you that the implementation was intended to work
on an ~25 Mhz Coldfire with 2MB RAM. So it isn't that heavy
on resources.

And the tests assume IMFS and have a tar image of the code being
dynamically loaded. The test code is small but it has to be
accounted for.

> I have included example application with dlopen shell command
> test to RTEMS OMK template project
>
> http://rtime.felk.cvut.cz/gitweb/rtems-devel.git
>
> http://rtime.felk.cvut.cz/gitweb/rtems-devel.git/tree/refs/heads/master:/rtems-omk-template/appdl
>
> Generally, next commands sequence should work for each
> RTEMS board
>
> git clone git://rtime.felk.cvut.cz/rtems-devel.git
> cd rtems-devel/rtems-omk-template/
> # setup target, i.e. path to directory where RTEMS support
> # for given board is isntalled
> echo "RTEMS_MAKEFILE_PATH=/opt/rtems4.11/arm-rtems4.11/lpc17xx_ea_ram" >config.target
> # setup optional tests (dlopen is not enabled by default in my test)
> cat >config.omk <<EOF
> CONFIG_OC_APP_APPNET=y
> CONFIG_OC_APP_APPNET_TELNETD=y
> CONFIG_OC_APP_APPDL=y
> CONFIG_OC_APP_APPDL_NET=y
> CONFIG_OC_APP_APPDL_TELNETD=y
> CONFIG_OC_APP_DL_PRINT=y
> EOF
>
> make
>
> You find linked application with symbol table exported
>
> _compiled/lpc17xx_ea_ram/bin/appdl
>
> Inclusion of export table is controlled by per application
> option applicationname_EXPORTSYMBOLS = y
> You need rtems-sysms tool form https://git.rtems.org/rtems-tools/
> repository installed.
>
> The symbol table for ARM is build in my case (see "make V=1" output)
> as linking application the first without symbol table (appdl.prelink)
> and then generating symbol table by rtems-syms and linking with
> appdl-symbol-table.o included.
>
> Symbol table preparation command
>
> rtems-syms -e -c "arm-rtems4.11-gcc --pipe -B/opt/rtems4.11/arm-rtems4.11/lpc17xx_ea_ram/lib/
>    -specs bsp_specs -qrtems -march=armv7-m -mthumb
>    -I /home/pi/tmp/rtems-devel/rtems-omk-template/_compiled/lpc17xx_ea_ram/include
>    -Wall  -O2 -g  -I /home/pi/tmp/rtems-devel/rtems-omk-template/_build/lpc17xx_ea_ram/user/appdl"
>    -S appdl-symbol-table.c -o appdl-symb      ol-table.o appdl.prelink
>
> The most form the invocation is specification of C compiler
> and its flags.
>
> I have not prepared simple way to specify that some plugins,
> shared objects should be compiled as relocatable ELFs for
> our infrastructure yet. I probably try to define it as equivalent
> of shared_LIBRARIES support which we have in Linux OMK variant.
>
> I have used hack for testing now, where I link complete application
> image, i.e. example for my board
>
> _compiled/lpc17xx_ea_ram/bin-tests/appdl_print
>
> and copy its (single) object file to IMFS initial data location
>
> mkdir appdl/rootfs/bin
> cp _build/lpc17xx_ea_ram/user/appdl/examples/appdl_print.o appdl/rootfs/bin
>
> and rerun
>
> make clean all
>
> That way the relocatable object file can be found
> in running shell in directory /bin and can be loaded
>
> ls /bin
> dlopen /bin/appdl_print.o main arg1 arg2 arg3
>
> Example can include network, so loading over TFTP,
> NFS or other RTEMS supported transports is possible
> as well.
>
> There are more related things which I have not
> solved yet and would be happy for others ideas.
>
> The main problem is that I would like to have
> some generic kernel image which exports not only
> actually used symbols but ideally all standard
> POSIX calls and support functions as well as
> RTEMS services.
>
> One simple and naive solution, which I have tried,
> is use of "-Xlinker --whole-archive" option
> during appdl.prelink linking.
> But that does not work there are more compnents
> and device drivers which cannot be included
> without application provided configuration tables
> etc. I know that there has been some support
> to build generic RTEMS kernel in past with
> right set of symbols exported (Eric Norum, EPICS).
> But I have newer tried that.
>
> I can imagine to use NM on RTEMS and Newlib C/m
> ibraries and select some reasonable way which
> objects are providing generic APIs and link these
> or ask their symbols as extrn during prelink
> phase. But that is not much elegant either.
>
> When I have tried to run dlopen more times on same
> object then there is problem that some small amount
> of memory is allocated each time, this means, that
> use of dlopen directly from some scripting environment
> without dlclose (which is risky, because called function
> can create threads) would need some other protection
> against multiple dlopen calls specifying same file.
>
> But generally, I have been really pleased how simple
> id RTEMS dlopen use and how far it is compliant
> to POSIX/more heavy OSes al Linux.
>
> Best wishes,
>
>                  Pavel Pisa
>
> ==================================================
>   PiKRON s.r.o.       Phone/Fax: +420 284684676
>   Kankovskeho 1235    Phone:     +420 234697622
>   182 00 Praha 8      WWW:   http://www.pikron.com/
>   Czech Republic      e-mail:  pikron at pikron.com
> ==================================================
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users
>

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985