The progress of GSOC2011

[Gedare Bloom]

For the scheduling issue, the idle task does not yield and does not
check for higher priority tasks to run: the OS must do so when it
makes a higher priority task runnable. So the partition OS needs to
somehow know to interrupt idle if the other, higher priority tasks are
once again runnable.

I'm not sure what is happening with the hypervisor, but I suspect that
the transition P1->P2 will save P1idle as the context of P1, and the
transition from P4->P1 will restore the context of P1 -- the idle task
-- and P1 is unaware of any changes. Perhaps P1 is missing some
interrupt to tell it that some task should be made runnable?

-Gedare

2011/7/5 张文杰 <157724595 at 163.com>:
> Dear all mentors and rtems users:
>   I am very glad to report the progress of GSOC2011 hypervisor for RTEMS. In
> the past about one month my main work is to
> merge the Hypervisor and partition OS which is based on rtems4.8.1 to the
> latest RTEMS version. Until now i have basically
> realized the goal that the sample test case can run successfully on this
> platform despite of a small bug. By the way all above
> work is based on LEON3 hardware platform.
>   About the merge of Hypervisor the main work is to modify the LEON3 BSP
> code and very little score code related to sparc cpu.
> Because the Hypervisor kernel code is independent to RTEMS code and is also
> build separately. So this part of merge is just a
> patch for LEON3 BSP to RTEMS latest version.
>   About the merge of Partition OS the main work is to development a new BSP
> for all sparc architecture and also very little
> modified code to score code related to sparc cpu. And another work is to
> update the build environment of sample test including
> Makefile and linkerfile
>   And now the sample test can successfully schedule a cycle including four
> partitions OS and each partition with three or four
> tasks. But when it schedule the second cycle it will only execute each
> partition OS‘ idle task. For example, the schedule table
> arrange the schedule order as follow:
> P1->P2->->P3->P4->P1->P2->P3->P4->......... and each partition OS arrange
> its tasks
> execution order is as follow :P1: P1A->P1B->P1C->P1idle     P2:
> P2A->P2B->P2idle   P3: P3A->P3B->P3C->P3idle  P4: P4A->
> P4B->P4C->P4idle.   so the first overall schedule cycle order is as follow：
> P1A->P1B->P1C->P1idle->P2A->P2B->P2idle->P3A->P3B->P3C->P3idle->P4A->P4B->P4C->P4idle
> The above is successfully test on the platform of Hypervisor and Partiton OS
> all based on RTEMS4.11. But when the second
> schedule cycle starts all the partiton OS is entering into idle tasks all
> the time. Tobias, any idea about this problem?
> Any comments is welcome.
>
> Wenjie
> Best Regards
>
>
>
>
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
>
>