On 06/02/2014 06:58 PM, Youren Shen wrote:
> Hi, Everyone:
>
> Since last week,I have improved the hypercall, build a new bsp named
> testHypercall to test it.Here is the commit.[1], [2], [3]. I also write
> a blog about it[4]. I have send a email to pok email-list about the change.
>
> Then I ha
On 05/28/2014 11:26 PM, Janek van Oirschot wrote:
> As promised in last meeting, here is a screenshot of the crash that
> occurs when executing rtems-guest. This pops up after qemu shows the
> "Hello world" string. Do keep in mind that for demonstration purposes I
> left my POK at the version at w
> On 05/21/2014 03:54 PM, Gedare Bloom wrote:> On Wed, May 21, 2014 at 4:04 AM,
> Christian Mauderer
>> wrote:
>>> First of all: Thanks for your comments. You will find answers below.
>>>
>>> Am 20.05.2014 16:58, schrieb Gedare Bloom:
>>>
>>> That is correct. It's part of XtratuM. Is there some p
Update it is. Do you have other issues?
@Sebastian: Which one should be used then?
Cheers,
Philipp
On 04/29/2014 02:13 AM, Gedare Bloom wrote:
> That or the virtualpok BSP needs an update to its linkcmds. :)
>
> On Mon, Apr 28, 2014 at 8:12 PM, Gedare Bloom wrote:
>> You need to update RTEMS I
Hi Youren,
git apply $attached_patch$
I have a meeting to attend to, so I don't have the time to test it right
now; will do it later. I hope it works.
Cheers,
Philipp
On 03/21/2014 09:30 AM, Philipp Eppelt wrote:
> Hi Youren,
>
> I just looked at a fresh RTEMS clone. I tho
spent me a few days to find. More details see this
> mails.
> >
> > [1].
> >
>
> http://listengine.tuxfamily.org/lists.tuxfamily.org/pok/2014/03/msg0.html
> >
> > -
> > Best Regards.
> > Youre
On 03/16/2014 01:01 PM, Youren Shen wrote:
> Hi, every one:
>
> I have write a blog about how to build the RTEMS on POK. However, the
> RTEMS can't run on POK now. Here is my blog[1].
>
> [1]. http://huaiyusched.github.io/rtems/2014/03/15/how-to-run-rtems-on-pok/
> --
> Best Regards.
> Youren Sh
On 03/11/2014 01:28 AM, Gedare Bloom wrote:
> On Mon, Mar 10, 2014 at 6:48 PM, Philipp Eppelt
> wrote:
>> On 03/10/2014 04:24 PM, Youren Shen wrote:
>>> What make me confused is the relation
>>> between pok_arch_event_register and pok_meta_handler_init. It seems you
On 03/10/2014 04:24 PM, Youren Shen wrote:
> What make me confused is the relation
> between pok_arch_event_register and pok_meta_handler_init. It seems you
> divided the irq vector to two parts in pok_arch_event_register, Less 32
> or more than 32. It looks like you have already design some hyperc
On 03/07/2014 02:07 PM, Gedare Bloom wrote:
> On Fri, Mar 7, 2014 at 4:44 AM, Philipp Eppelt
> wrote:
>> On 03/06/2014 06:58 PM, Gedare Bloom wrote:
>>> Hi Philipp,
>>>
>>> On Wed, Mar 5, 2014 at 3:48 AM, Philipp Eppelt
>>> wrote:
>>>
On 03/06/2014 06:58 PM, Gedare Bloom wrote:
> Hi Philipp,
>
> On Wed, Mar 5, 2014 at 3:48 AM, Philipp Eppelt
> wrote:
>> Hi,
>>
>> as of now it looks like we have a student picking up my work from last
>> year. While the patches for the --enable-paravirt c
Hi,
as of now it looks like we have a student picking up my work from last
year. While the patches for the --enable-paravirt configuration option
went upstream, the virtualpok BSP for i386 still has open issues.
I reviewed the discussion we had in December and January on the
virtualpok BSP for i3
Hi Youren,
can you please explain your proposed hypercall solution in more detail.
Lets assume RTEMS requests notification for an interrupt line, e.g IRQ
0. How is the request delivered from RTEMS to POK in your solution?
The big issue is the delivery of interrupts to the guest system (RTEMS):
Ho
Hi,
I just want to keep this in the loop.
Where do we want to draw the line between RTEMS and host systems?
Cheers,
Philipp
On 01/16/2014 02:53 PM, Philipp Eppelt wrote:
> On 01/14/2014 08:36 PM, Chris Johns wrote:
>> On 15/01/2014 1:58 am, Philipp Eppelt wrote:
>>> On 0
On 01/14/2014 08:36 PM, Chris Johns wrote:
> On 15/01/2014 1:58 am, Philipp Eppelt wrote:
>> On 01/14/2014 12:32 PM, Chris Johns wrote:
>>> On 14/01/2014 12:40 am, Philipp Eppelt wrote:
>>>> On 01/12/2014 10:19 PM, Chris Johns wrote:
>>>>> On 13/01/201
On 01/14/2014 12:32 PM, Chris Johns wrote:
> On 14/01/2014 12:40 am, Philipp Eppelt wrote:
>> On 01/12/2014 10:19 PM, Chris Johns wrote:
>>> On 13/01/2014 2:39 am, Philipp Eppelt wrote:
>>>> On 01/11/2014 11:50 PM, Chris Johns wrote:
>>>>> On 12/01/2014
On 01/12/2014 10:19 PM, Chris Johns wrote:
> On 13/01/2014 2:39 am, Philipp Eppelt wrote:
>> On 01/11/2014 11:50 PM, Chris Johns wrote:
>>> On 12/01/2014 12:45 am, Philipp Eppelt wrote:
>>>> On 01/10/2014 10:27 PM, Chris Johns wrote:
>>>>> On 7/01/201
On 01/11/2014 11:50 PM, Chris Johns wrote:
> On 12/01/2014 12:45 am, Philipp Eppelt wrote:
>> On 01/10/2014 10:27 PM, Chris Johns wrote:
>>> On 7/01/2014 9:14 pm, Philipp Eppelt wrote:
>>>> On 01/07/2014 04:25 AM, Chris Johns wrote:
>>>>&g
On 01/10/2014 10:27 PM, Chris Johns wrote:
> Sorry about the delay. It is the holiday season here.
Happy Holidays :)
>
> On 7/01/2014 9:14 pm, Philipp Eppelt wrote:
>> On 01/07/2014 04:25 AM, Chris Johns wrote:
>>> On 7/01/2014 12:18 pm, Joel Sherrill wrote:
>>>
On 01/07/2014 04:25 AM, Chris Johns wrote:
> On 7/01/2014 12:18 pm, Joel Sherrill wrote:
>>
>> On 1/6/2014 5:14 PM, Chris Johns wrote:
>>> On 7/01/2014 4:24 am, Joel Sherrill wrote:
>>>> On 1/6/2014 11:13 AM, Philipp Eppelt wrote:
>>>>> Where are
Where are we on this?
On 12/06/2013 03:40 PM, Gedare Bloom wrote:
> I'm generally OK with these 2 patches.
>
> On Thu, Dec 5, 2013 at 10:59 AM, Philipp Eppelt
> wrote:
>> ---
>> c/src/lib/libbsp/i386/acinclude.m4 | 2 +
>> c/src/lib
lib/libbsp/i386/virtualpok/README.virt
b/c/src/lib/libbsp/i386/virtualpok/README.virt
new file mode 100644
index 000..47382ca
--- /dev/null
+++ b/c/src/lib/libbsp/i386/virtualpok/README.virt
@@ -0,0 +1,23 @@
+Author: Philipp Eppelt
+ philipp.epp...@mailbox.tu-dresden.de
+
+This BSP is intended
100644
index 000..9f3d5a5
--- /dev/null
+++ b/cpukit/score/cpu/i386/rtems/score/virtualizationlayercpu.h
@@ -0,0 +1,91 @@
+/*
+ *
+ * COPYRIGHT (c) 2013 Philipp Eppelt.
+ *philipp.epp...@mailbox.tu-dresden.de
+ *
+ * Purpose: CPU part of the virtualization layer.
+ *
+ * The lic
On 12/03/2013 05:41 PM, Gedare Bloom wrote:
> On Wed, Nov 27, 2013 at 5:55 PM, Philipp Eppelt
>> +#ifndef RTEMS_VIRT_LAYER_CPU_H
>> +#define RTEMS_VIRT_LAYER_CPU_H
>> +
>> +#ifndef ASM
>> +
>> +/* Interrupts */
>> +
>> +/**
>>
On 12/03/2013 05:49 PM, Gedare Bloom wrote:
> On Sat, Nov 30, 2013 at 4:13 AM, Philipp Eppelt
> wrote:
>> ---
>> c/src/lib/libbsp/i386/acinclude.m4 | 2 +
>> c/src/lib/libbsp/i386/virtualpok/Makefile.am | 87
>> c/src/lib/libb
---
cpukit/score/cpu/i386/rtems/score/virtualizationlayercpu.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/cpukit/score/cpu/i386/rtems/score/virtualizationlayercpu.h
b/cpukit/score/cpu/i386/rtems/score/virtualizationlayercpu.h
index ce269fa..891e9b3 100644
--- a/cpukit/score/cpu/i386/r
386_enable_interrupts( _level )
+#endif /*RTEMS_PARAVIRT*/
/** @} */
#endif
diff --git a/cpukit/score/cpu/i386/rtems/score/virtualizationlayercpu.h
b/cpukit/score/cpu/i386/rtems/score/virtualizationlayercpu.h
new file mode 100644
index 000..ce269fa
--- /dev/null
+++ b/cpukit
The first part introduces virtualizationlayer.h to i386 and adds all functions
to the corresponding files.
The second part adds guards to virtualizationlayer.h to ignore the headers if
rtems_paravirt is not enabled.
___
rtems-devel mailing list
rtems-dev
Hi,
this is a follow up to the three --enable-paravirt patches and should be
applied afterwards.
Sorry for the inconveniance,
Philipp
___
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
le.c and move that
> code into its own file, I wouldn't be opposed to it.
> But I don't consider that a hard requirement.
>
> The other two patches look OK if folks like the name.
>
> --joel
>
> On 11/27/2013 12:00 PM, Philipp Eppelt wrote:
>> ---
>>
---
cpukit/aclocal/enable-paravirt.m4 | 17 +
cpukit/configure.ac | 6 ++
2 files changed, 23 insertions(+)
create mode 100644 cpukit/aclocal/enable-paravirt.m4
diff --git a/cpukit/aclocal/enable-paravirt.m4
b/cpukit/aclocal/enable-paravirt.m4
new file mode 10
---
aclocal/enable-paravirt.m4 | 17 +
configure.ac | 1 +
2 files changed, 18 insertions(+)
create mode 100644 aclocal/enable-paravirt.m4
diff --git a/aclocal/enable-paravirt.m4 b/aclocal/enable-paravirt.m4
new file mode 100644
index 000..ff768f4
--- /dev/null
\
diff --git a/cpukit/score/cpu/i386/rtems/score/virtualizationlayercpu.h
b/cpukit/score/cpu/i386/rtems/score/virtualizationlayercpu.h
new file mode 100644
index 000..526f8d1
--- /dev/null
+++ b/cpukit/score/cpu/i386/rtems/score/virtualizationlayercpu.h
@@ -0,0 +1,84 @@
+/* Author:Philipp
---
cpukit/score/cpu/i386/cpu.c| 18 +
cpukit/score/cpu/i386/rtems/score/cpu.h| 51 --
cpukit/score/cpu/i386/rtems/score/interrupts.h | 31
3 files changed, 88 insertions(+), 12 deletions(-)
diff --git a/cpukit/score/cpu
Yes I'll implement this and send a patch in the next weeks.
On 10/14/2013 05:24 PM, Gedare Bloom wrote:
> OK. Philipp can you send a patch when you are able that adds the new flag?
> -Gedare
>
> On Mon, Oct 14, 2013 at 4:12 AM, Philipp Eppelt
> wrote:
>> On 10/14/2013
On 10/14/2013 09:09 AM, Sebastian Huber wrote:
> On 2013-10-11 19:54, Gedare Bloom wrote:
>> I would like to make one other suggestion, which is:
>> RTEMS_PARAVIRT, and --enable-paravirt.
>> This option is consistent with the language already used to describe
>> what is being done, i.e. paravirtual
loom wrote:
> Sounds good. Would it be a BSP for each hypervisor for each target CPU
> type the hypervisor runs on?
>
> -Gedare
>
> On Mon, Sep 23, 2013 at 9:10 AM, Philipp Eppelt
> wrote:
>> Hi,
>>
>> in the last days I reused my work on L4RTEMS to do a quick
nd have to sort
things out first. The obstacle at the moment is to create a library in
L4Re, which includes all L4Re dependencies and has only a few undefined
references, which can be resolved by RTEMS.
Cheers
Philipp
On 09/20/2013 09:22 AM, Philipp Eppelt wrote:
> Hi,
>
> what did I
From: Philipp Eppelt
---
c/src/lib/libcpu/i386/Makefile.am | 44
c/src/lib/libcpu/i386/configure.ac | 4 ++
c/src/lib/libcpu/i386/cpu.h| 2 +-
c/src/lib/libcpu/i386/native/cpu-score-split.c | 26 +++
.../libcpu/i386
From: Philipp Eppelt
---
c/src/lib/libbsp/i386/acinclude.m4 | 2 +
c/src/lib/libbsp/i386/virtualpok/Makefile.am | 88
c/src/lib/libbsp/i386/virtualpok/README.virt | 16 ++
c/src/lib/libbsp/i386/virtualpok/bsp_specs | 14 ++
c/src/lib/libbsp/i386
Hi,
what did I do in my project?
I designed and implemented a virtualization layer, which should ease the
virtualization of RTEMS across different hypervisors.
To test the layer and because of the ARINC 653 compliance POK was chosen
as a proof-of-concept host OS.
The project was a partial succes
rtems.org/wiki/index.php/GSOC_2013_-_Paravirtualization_of_RTEMS#Questionable_parts
It would be a big help if you could point out the parts, which are not
clear to the reader.
Cheers,
Philipp
>
> Best Regards,
> Cláudio
>
>
> On Mon, Sep 16, 2013 at 2:41 PM, Philipp Eppelt
> <m
On 09/17/2013 05:08 PM, Joel Sherrill wrote:
> On 9/17/2013 9:51 AM, Rempel, Cynthia wrote:
>>>
>>> From: rtems-devel-boun...@rtems.org [rtems-devel-boun...@rtems.org]
>>> on behalf of Philipp Eppelt [philipp.epp...@mailbox.tu
Hi,
in my GSOC project I aim for a virtualized version of RTEMS. I develop
it for the i386 target and moved the interrupt.h code to libcpu to be
included dependent on the CPU target. So a native cpu still gets the
normal code, but the virtual one will call the virtualization layer.
This leads to
Hi Cindy,
yes, that's the next thing on my list.
Cheers
Philipp
On 09/16/2013 06:39 PM, Rempel, Cynthia wrote:
> Hi Philipp Eppelt,
>
> Could you put that information on the wiki page for your project, so the next
> student that works on the project will know where to s
Hi,
it's suggested pencils down today and I have still trouble with the
interrupt handling.
I have this functionality:
- enable/disable interrupts for a partition
- register a handler for a partition
- partition needs to acknowledge the interrupt before more a send
The kernel handler sends the
On 08/20/2013 11:09 AM, Sebastian Huber wrote:
> On 2013-08-20 10:55, philipp.epp...@mailbox.tu-dresden.de wrote:
>> diff --git a/cpukit/score/cpu/i386/rtems/score/cpu.h
>> b/cpukit/score/cpu/i386/rtems/score/cpu.h
>> index 43422ed..68b0e53 100644
>> --- a/cpukit/score/cpu/i386/rtems/score/cpu.h
>>
This patch moves functionality from score/i386 to a newly created CPU model in
libcpu/i386 called 'native'.
---
diff --git a/cpukit/score/cpu/i386/Makefile.am
b/cpukit/score/cpu/i386/Makefile.am
index e35a81c..dc33e93 100644
--- a/cpukit/score/cpu/i386/Makefile.am
+++ b/cpukit/score/cpu/i386/Make
"
>> from interrupts.h header comment. Possibly add comment "Relocated from
>> score/cpu/i386"
>> * rename files to avoid humpBackNotation. Files in RTEMS are usually
>> alllowercase so let us follow the usual way.
>> * Remove "Date: XX/YY/&qu
ould also transition to "user mode" before calling the RTEMS handler.
>
>
>
> On Sun, Aug 18, 2013 at 7:33 PM, Philipp Eppelt
> <mailto:philipp.epp...@mailbox.tu-dresden.de>> wrote:
>
> Hi,
>
> why only talking about it and not implementing
from interfering with POK. If RTEMS registers a handler
> for a vector already user by POK (e.g. clock tick interrupt), POK cannot
> be overruled and be dependent on RTEMS to run its own code. But for a
> first iteration it's OK to ignore this.
>
>
> Cláudio
>
>
&g
after the virtualized RTEMS handler?
>
> Regards,
> Cláudio
>
>
> On Sun, Aug 18, 2013 at 12:18 AM, Philipp Eppelt
> <mailto:philipp.epp...@mailbox.tu-dresden.de>> wrote:
>
> Hi,
>
> lately I worked a lot to extend POK with necessary features
Hi,
lately I worked a lot to extend POK with necessary features to
accommodate an RTEMS partition.
Since hello world works, I need a way to pass clock ticks to the RTEMS
partition running on POK. Therefore the interrupt handling needs to
support custom handlers.
If everything works out, I can ena
utomake/local.am
diff --git a/c/src/lib/libbsp/i386/virtPok/README.virt b/c/src/lib/libbsp/i386/virtPok/README.virt
new file mode 100644
index 000..f12a947
--- /dev/null
+++ b/c/src/lib/libbsp/i386/virtPok/README.virt
@@ -0,0 +1,16 @@
+Date: 06/10/2013
+Author: Philipp Eppelt
+Purpose: Informati
git a/c/src/lib/libcpu/i386/virtual/include/cpu-score-split.h b/c/src/lib/libcpu/i386/virtual/include/cpu-score-split.h
new file mode 100644
index 000..605eaf3
--- /dev/null
+++ b/c/src/lib/libcpu/i386/virtual/include/cpu-score-split.h
@@ -0,0 +1,63 @@
+/**
+ * @file
+ *
+ * @brief Virtualized
Patch for score, removing functions using virtualization sensitive
instructions.
diff --git a/cpukit/score/cpu/i386/Makefile.am b/cpukit/score/cpu/i386/Makefile.am
index e35a81c..dc33e93 100644
--- a/cpukit/score/cpu/i386/Makefile.am
+++ b/cpukit/score/cpu/i386/Makefile.am
@@ -7,7 +7,6 @@ include_r
Hi,
I wrote a post about the changes to the i386 architecture to accommodate
virtual and native environments.
http://phipse.github.io/rtems/blog/2013/07/30/midterm-explanation/
I will send patches for cpukit/score/cpu/i386, c/src/lib/libcpu/i386 and
c/src/lib/libbsp/i386.
The first removes func
Hi,
I wrote a new blog post about the clock and interrupt issues
http://phipse.github.io/rtems/blog/2013/07/09/how-late-is-it/
Excerpt:
What we need to provide clock ticks to a partition ...
.. in POK
* Forward interrupts to registered partitions
* Register several partitions to the same interr
Hi,
I managed to compile and run the HelloWorld sample on POK. :)
Also I set up a blog explaining the build process (5 steps), the current
development status of the POK and RTEMS side and some issues I faced
(GDB, Memory & AADL Model).
Have a look:
http://phipse.github.io/rtems/
Here an ex
On 06/19/2013 09:11 PM, Gedare Bloom wrote:
On Wed, Jun 19, 2013 at 11:02 AM, Philipp Eppelt
wrote:
This is implemented in POK and libpart.a is compiled and copied to
rtems/libbsp/i386/virtPok.
The virtPok makefile creates a new library file called libpokpart.a.
If libpart.a is not present
Hi,
I got the hello sample to compile.
This means the host library works in RTEMS.
But let's start at the beginning.
I separated libcpu and score and defined native and virtual CPU's in
libcpu/i386.
The difference between the two are interrupts.h and _CPU_ISR_Set_level,
_CPU_Fatal_halt, _CPU_
On 05/15/2013 03:55 PM, Gedare Bloom wrote:
On Tue, May 14, 2013 at 11:55 AM, Philipp Eppelt
wrote:
Hi,
I looked into the libcpu/sh dir to understand how the split of the CPU code
between score/cpu and libcpu/ works.
My approach for the i386 arch brings some changes to existing files
Hi,
I looked into the libcpu/sh dir to understand how the split of the CPU
code between score/cpu and libcpu/ works.
My approach for the i386 arch brings some changes to existing files:
* score/i386/rtems/score/cpu.h
* score/i386/cpu.c
* score/i386/rtems/score/interrupts.h
The list of functi
63 matches
Mail list logo
