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

On Fri, May 10, 2013 at 11:16 AM, Philipp Eppelt <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.
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

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@mailbox.tu-dresden.de>> 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