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

[ Thread Index | Date Index | More lists.tuxfamily.org/pok-devel Archives ]


Hi,

thanks Julien.

Is there a manual explaining the cross compilation of powerpc and sparc? I have some difficulties setting this up and without it 'make commit' run through.

Also can I just add the Fedora 17 naming for the tools in conf-env.pl? They are different from the ones mentioned there.

Regards,
Philipp





On 05/13/2013 03:15 PM, Julien Delange wrote:
Dear Philip,

 From what I see in your patch, everything seems correct and great.
Also, I should probably explain the rationale for having a different
libpok.a for each partition. The initial reason was that we can remove
automatically useless service using compilation macro. Then, we increase
the code coverage, that is really useful for safety-critical
applications that must comply with demanding code coverage standards.

But in your project, it may also makes no sense because this type of
optimization is out of the scope of your project. Thus, you can just
take a generic libpok.a for making a basic example or also just use a
libpok.a with all services (you would have to spot for all POK_USE*
macro to enable them) and include it to build your system.

Also, as you seem very active and willing to contribute, I will give you
access to the repository so that you can commit your changes directly.

Best,



On Sun, May 12, 2013 at 5:24 PM, Philipp Eppelt
<philipp.eppelt@xxxxxxxxxxxxxxxxxxxxx
<mailto:philipp.eppelt@xxxxxxxxxxxxxxxxxxxxx>> wrote:

    Hi,

    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/rules-partition.mk <http://rules-partition.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/.


    Regards,
    Philipp



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

        Hi,

        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
        <philipp.eppelt@xxxxxxxxxx-__dresden.de
        <mailto:philipp.eppelt@xxxxxxxxxxxxxxxxxxxxx>
        <mailto:philipp.eppelt@__mailbox.tu-dresden.de
        <mailto:philipp.eppelt@xxxxxxxxxxxxxxxxxxxxx>>> wrote:

             Hi,

             yes Wiktor used a combine script to build partition.bin,
        sizes.c and
             to compile pok.elf again. This looks like
        misc/mk/rules-main.mk <http://rules-main.mk>
             <http://rules-main.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?

             Regards,
             Philipp


             [0]
        http://wiki.rtems.org/wiki/____index.php/GSOC_2013_-_____Paravirtualization_of_RTEMS#____Build_process
        <http://wiki.rtems.org/wiki/__index.php/GSOC_2013_-___Paravirtualization_of_RTEMS#__Build_process>


        <http://wiki.rtems.org/wiki/__index.php/GSOC_2013_-___Paravirtualization_of_RTEMS#__Build_process
        <http://wiki.rtems.org/wiki/index.php/GSOC_2013_-_Paravirtualization_of_RTEMS#Build_process>>



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

                 Hi,

                 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
                 breakpoint.

                 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
                 draft
                 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
                 <philipp.eppelt@xxxxxxxxxx-____dresden.de
        <mailto:philipp.eppelt@xxxxxxxxxx-__dresden.de>
                 <mailto:philipp.eppelt@__mailbox.tu-dresden.de
        <mailto:philipp.eppelt@xxxxxxxxxxxxxxxxxxxxx>>
                 <mailto:philipp.eppelt@
        <mailto:philipp.eppelt@>__mailb__ox.tu-dresden.de
        <http://mailbox.tu-dresden.de>

                 <mailto:philipp.eppelt@__mailbox.tu-dresden.de
        <mailto:philipp.eppelt@xxxxxxxxxxxxxxxxxxxxx>>>> wrote:

                      Hi,

                      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.

                      Result:
                      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
                 symbol-file
                      switches.

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


                      Regards,
                      Philipp




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

                          Hi,

                          I am a student at Dresden University of
        Technology,
                 currently
                          applying
                          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
                          linked
                          .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
                 systems.
                          However, none of the usual tools (nm, readelf,
        objdump)
                 read the
                          resulting binary correctly, therefore I
        refrain from
                 taking this
                          way.
                          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
                 binary.
                          My first idea was to build an application in POK
                 containing all
                          'guest
                          communication functions' (e.g. disable/enable
                 interrupts, console
                          access) and to pass the fully linked file as a
        library
                 to RTEMS.
                          Then
                          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
                          partly
                          linked .ralf file could then be inserted while
        POK is
                 linked,
                          resolving
                          the undefined references. This is pretty much the
                 approach of last
                          year's student. But that would intercept with
        the build
                 process
                          of POK
                          and is therefore no satisfying approach. An custom
                 linker script
                          might
                          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?


                          Regards,
                          Philipp












Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/