Changes between Version 36 and Version 37 of GSoC/2013/ParavirtualizationOfRTEMS


Ignore:
Timestamp:
Sep 17, 2013, 5:16:38 PM (6 years ago)
Author:
Phipse
Comment:

/* Paravirtualization layer */

Legend:

Unmodified
Added
Removed
Modified
  • GSoC/2013/ParavirtualizationOfRTEMS

    v36 v37  
    5959
    6060The listed functions describe the interface functions provided by the host system.
    61 The CPU-BSP separation is just to get a good overview.
    62 
    63 But I have to add, that it looks neat this way.
    64 And it might ease the port of other architectures in the future, because just the CPU part needs to be adapted.
    65 Maybe the BSP can be even reused on other architectures.
     61The list is seperated into CPU dependent functions and common BSP functions.
     62This leads to a redefinition of the CPU part and maybe the BSP functionality can be reused on other architectures.
     63The files can be found in c/src/lib/libbsp/i386/virtualpok/include/.
    6664==  CPU functions (i386)  ==
    6765
    68  *  requestIRQ
    69  *  detachIRQ
    70  *  enableInterrupts
    71  *  disableInterrupts
    72  *  flashInterrupts
    73  *  getInterruptLevel
    74  *  idleThread
    75  *  tbc
     66 *  _CPU_Virtual_Irq_request( int vector )
     67 *  _CPU_Virtual_Irq_detach( int vector )
     68 *  _CPU_Virtual_Interrupts_enable( int _level )
     69 *  _CPU_Virtual_Interrupts_disable( int _level )
     70 *  _CPU_Virtual_Interrupts_flash( int _level )
     71 *  _CPU_Virtual_Interrupts_open(void)
     72 *  _CPU_Virtual_Interrupts_close(void)
     73 *  _CPU_Virtual_idle_thread(void)
     74 *  _CPU_Virtual_exec_stop_error( int _error )
     75
    7676==  BSP functions (i386)  ==
    7777
    78  *  '''faultHandler''' -> is called by POK, when a fault occurrs; This function is required in L4RTEMS, too.
    79  *  console_init
    80  *  console_write
    81  *  console_read
    82  *  clock_init
    83  *  clock_read
    84  *  timer_init
    85  *  timer_set
    86  *  timer_read
    87  *  tbc
     78 *  _BSP_Virtual_Console_init(void)
     79 *  _BSP_Virtual_Console_read(void) -- not used, as POK can't read from console
     80 *  _BSP_Virtual_Console_write(char* c)
     81 *  _BSP_Virtual_faulthandler(void)
     82 *  _BSP_Virtual_Clock_init(void)
     83 *  _BSP_Virtual_Clock_read(void)
     84 *  _BSP_Virtual_getworkspacearea(void)
    8885=  RTEMS startup as a guest  =
    8986
    9087
    91 In L4RTEMS the wrapper task loads the RTEMS elf-binary, stores the initial IP and SP in the vCPU registers and starts the vCPU.
    92 Therefore the binary is passed as a command line argument.
    93 
    94 We need to keep in mind, that issue should NOT lead to hacks in the virtualization layer of RTEMS.
    95 It is more of a hypervisor/host issue and needs to be resolved in this scope and this scope only.
    96 
    97 How can we start RTEMS on POK?
    98 The closest abstraction to the L4-vCPU I have found in POK is the software partition itself.
    99 However, if we can make it, we need to change the partitions SP,IP and EAX register, while running on it.
    100 This looks like a hack and not like a careful design.
    101 
    102 But there are other options.
    103 One I can think of is:
    104  *  compiling the library in POK.
    105  *  provide the lib to RTEMS and compile the application.
    106  *  pass the binary back to POK and combine kernel and binary.
    107 
    108 This approach was partly used in the GSoC 2012 project.
    109 
    110 Another approach would be :
    111  *  compile RTEMS and do a first linking run
    112  *  compile POK and pass the partly linked RTEMS file along
    113   *  The POK starter function would do the env setup and then call the RTEMS start() (0x10000c)
    114 
    115 
    116 Both approaches might to consider this:
    117 
    118 Thanks to DrJoel:
    119 "If it is "ld -r", then it may still need a real linking with linkcmds to be at a known address range to insert into the Pok link."
    120 
     88We settled with the following design:
     89 *  Compile POK including the partition, leading to libpart.a in generated-code/cpu/partX/
     90 *  Copy libpart.a to the RTEMS BSP virtualpok/ and compile RTEMS for i386 and the virtualpok BSP
     91 *  The resulting binaries from the samples directory can be used as pok partition binaries
     92 *  Copy for examples hello.exe to part1/part1.elf and run the kernel compilation again
     93 *  The kernel will start the partition and therefore RTEMS
    12194==  Compile POK partitions  ==
    12295
     
    146119Invoking with ''make last'' produces the expected result: The size.c file contains the size of hello.exe and nm partitions.bin shows the RTEMS symbols.
    147120
    148 However, POK fails at start up, I didn't figure out where exactly, yet, but it looks like an issue while loading the binary.
    149 The pok_boot() function runs through and the execution crashes with SIGQUIT at the first asm instruction in pok_dispatch_space.
     121The hello world works fine. Read this [http://phipse.github.io/rtems/blog/2013/07/08/HelloWorld/ blog post] for further information.
    150122==  Build process  ==
    151123
     
    161133As POK starts partitions by loading the ELF-binary and jumping in on the entry_ip specified in the ELF-header, RTEMS should start fine.
    162134On the RTEMS side the use of the virtualization layer functions works without issues, as the function implementations are passed via the library.
     135
     136Read [http://phipse.github.io/rtems/blog/2013/07/08/HelloWorld/ this blog post] on how to build hello world.
    163137=  Virtual CPU Issue  =
    164138