On Tue, Dec 15, 2015 at 10:23 PM, Gernot Heiser gernot@nicta.com.au wrote:
Nice!
Just so I understand the setup: Does seL4 run in some super-privileged (hypervisor) mode or do seL4 and RTEMS run at the same privilege level on different cores? If it’s the latter, how is seL4 protected from the RTEMS side?
elfloader is running in the most privilege RISC-V level (Machine mode), but seL4 and RTEMS run on the same supervisor mode. RTEMS port doesn't do any memory management, it runs as a single address space process, hence, it can't alter its page-tables PTEs. seL4/application allocates the page directory for RTEMS, and do the mapping, before notifying the elfloader that it can boot RTEMS passing the address of the page-table and the start physical address of the allocated memory for RTEMS. elfloader (since it has the privilege) loads RTEMS from the cpio archive, and sets the other core's register that points to the allocate page-table, so RTEMS wouldn't be able to mess with memory that's not allocated with it.
I actually wanted to run seL4 in Machine mode, but it only supports base and bound protection (segments), and it's not yet supported by the toolchain (binutils).
Gernot
On 16 Dec 2015, at 9:13 , Hesham Almatary heshamelmatary@gmail.com wrote:
Hi all,
I got an RTEMS port working for RISC-V architecture along with seL4. This depends on my earlier seL4 port for RISC-V.
RTEMS runs with support of seL4 microkernel, and it runs in Supervisor mode (on another core). seL4 application would allocate and map memory for it from its untyped memory (userspace), before off-loading it to another core.
seL4 application that loads/runs RTEMS is pretty much the same as SOS.
For more details (and instructions) about how to build/run the project, see the github repo of the port [1], and/or this blog post [2]
[1] https://github.com/heshamelmatary/rtems-riscv [2] http://heshamelmatary.blogspot.co.uk/2015/12/rtems-port-for-risc-v-withwitho...
Cheers,
Hesham
Devel mailing list Devel@sel4.systems https://sel4.systems/lists/listinfo/devel
The information in this e-mail may be confidential and subject to legal professional privilege and/or copyright. National ICT Australia Limited accepts no liability for any damage caused by this email or its attachments.