Re: [pok-devel] Start a guest binary in a partition

[ Thread Index | Date Index | More Archives ]


I can only find libpok/libpok.a. As libpok.a is generated for every partition I think it would be nice, if it resides in the partitions directory in generated-code/cpu/partX/ to save it from being overwritten by the libpok.a for the next partition.

For the project it is essential, as several RTEMS instances with different needs and other partitions should be running in the system (one day). However, I don't know if any constraints apply to the generated-code/ directory, preventing libpok.a to reside in the partX/ dir.

I modified misc/mk/ to copy the current libpok to the current partition directory. The patch is attached and I hope its accurate.
It worked for example/partitions-threads/.


On 05/12/2013 06:00 AM, Julien Delange wrote:

As far as I remember, POK builds a library that is then linked with the
code. For each partition, it builds a libpok.a tailored according to the
requirements of the partition. Then, you would need to link the libpok.a
of the partition to your RTEMS instance.
Also, I think the approach and your design seems to be clean. This is
good because most of the time, along the project, we use some hacks and
other tricks to address some problems/issues we do not expect. Then,
starting with a good design in mind is a good start :-)

On Fri, May 10, 2013 at 11:16 AM, Philipp Eppelt
<mailto:philipp.eppelt@xxxxxxxxxxxxxxxxxxxxx>> wrote:


    yes Wiktor used a combine script to build partition.bin, sizes.c and
    to compile pok.elf again. This looks like misc/mk/
    My approach still utilizes this script to fuse everything together.

    I wrote about it in the RTEMS wiki [0] and here it is:

    * Design the POK system via an AADL model.
    * Keep the size of the final binary, including RTEMS, in mind.
    * Build the POK container for the RTEMS code --> Library
    * Take the library and pass it to RTEMS at compile time.
    * Use the last years pok_rtems_combine script to add the final
    binary as partition.

    This is a clean approach on both sides. POK will be configured with
    the AADL model and the partition binary implements the POK side of
    the communication interface. As POK starts partitions by loading the
    ELF-binary and jumping in on the entry_ip specified in the
    ELF-header, RTEMS should start fine. On the RTEMS side the use of
    the virtualization layer functions works without issues, as the
    function implementations are passed via the library.

    Is it possible to tell the tool-chain to build a library file?
    When the elf is loaded the entry_IP is saved in the pok_partitions
    array and my guess is, it is used to start the binary. But how does
    the AADL subprogram source_name property play into this?

    What do you think of this approach?



    On 05/04/2013 06:16 AM, Julien Delange wrote:


        Indeed, the binaries are concatenated with the kernel to built the
        binary to load on the target. As far as I remember, this was
        also the
        approach used by the student last year but it was done manually (not
        integrated with the actual toolchain). If you want to break, you
        need to
        know the address in RTEMS + the start address of the partition.
        That is
        why in the POK debug mode (as far as I remember), we show the start
        address of a partition. Then, you should be able to put your

        Please ask other question if you need. I am no longer developing
        POK but
        I hope that actual (anybody from owi, tpt ?) and old (Laurent ?)
        developers would help so that we might be able to design a first
        of proof of example of POK as an RTEMS virtualisation layer. On
        my side,
        I will do my best to answer the rest of knowledge I have :-)

        On Fri, May 3, 2013 at 6:17 AM, Philipp Eppelt
        <mailto:philipp.eppelt@xxxxxxxxxxxxxxxxxxxxx>>> wrote:


             I tried to inject an RTEMS binary into POK.
             By modifying the generated-code/cpu/Makefile to use hello.exe
             (RTEMS) as partition binary instead of part1/part1.elf and I
             introduced a makefile rule just depending on $(TARGET), so the
             partitions and kernel aren't rebuild.

             partitions.bin -> nm shows the RTEMS symbols
             sizes.c -> contains the size of hello.exe

             make run spins in a reload cycle.
             However, I did at least expect the binary to be loaded, but
        I didn't
             manage to confirm this with make run-gdb. It behaves
        strange, as
             breakpoints are accepted but the execution won't stop at
        the defined
             breakpoint. Sometimes it does after various tries and

             Do you have some recommendations to solve this gdb issue?
             Or an idea how I can confirm the successful loading of the


             On 05/02/2013 07:39 PM, Philipp Eppelt wrote:


                 I am a student at Dresden University of Technology,
                 to Google Summer of Code for the RTEMS project.

                 The purpose of my project is to design and implement a
                 paravirtualization layer in RTEMS to ease
        virtualization. As
                 proof-of-concept I like to use POK as host system.

                 In last year's GSoC a student used POK to run RTEMS
        with the
                 goal to get
                 RTEMS ARINC 653 compliant.
                 He introduced new syscalls to POK and combined the
        RTEMS partly
                 .ralf file with the POK binary. He used cat to pipe both
                 binaries into
                 the same file and used some 'magic' to fuse the two
                 However, none of the usual tools (nm, readelf, objdump)
        read the
                 resulting binary correctly, therefore I refrain from
        taking this
                 Additionally, I don't want to use direct syscalls from the
                 guest, as the
                 virtualization layer in RTEMS should be portable.

                 Now I am searching for a way to start the RTEMS guest
                 My first idea was to build an application in POK
        containing all
                 communication functions' (e.g. disable/enable
        interrupts, console
                 access) and to pass the fully linked file as a library
        to RTEMS.
                 the RTEMS build process would run without errors, as
        the missing
                 function implementations are provided.
                 But I don't know, how I can call the RTEMS bsp_start()
        function for
                 instance, as POK doesn't know about this at compile time.

                 The second idea was to build RTEMS first. This will
        fail due to
                 undefined references cause by the 'communication
        functions'. The
                 linked .ralf file could then be inserted while POK is
                 the undefined references. This is pretty much the
        approach of last
                 year's student. But that would intercept with the build
                 of POK
                 and is therefore no satisfying approach. An custom
        linker script
                 resolve the issues with the tools, though.

                 So I am a little stuck here and seeking guidance.
                 Do you have another idea?
                 Is there some source code supporting foreign binaries to be
                 executed in
                 a partition?
                 Do you know of projects doing something similar?


Index: misc/mk/
--- misc/mk/	(revision 45)
+++ misc/mk/	(working copy)
@@ -14,6 +14,7 @@
 	$(CD) $(POK_PATH)/libpok && $(MAKE) distclean all
+	$(CP) $(POK_PATH)/libpok/libpok.a `pwd`/
 	$(ECHO) $(ECHO_FLAGS) $(ECHO_FLAGS_ONELINE) "[Assemble partition $@ "

Mail converted by MHonArc 2.6.19+