RTOS to RTOS
I plan to run an RTOS like Nuttx as a process for other RTOSs like FreeRTOS so that freertos and Nuttx tasks running as a Freertos task will coexist.
Would this be a feasible implementation given that the underlying hardware is a single core ARM cortex A8 processor? What changes might be required if the implementation is not based on the VM concept?
source to share
Your requirement, in a nutshell, is to allow the GUEST RTOS to fully operate in the areas of the main BASIC BASE. The first answer would be to use a virtualization extension, but the A8 processor doesn't have that, so it will drive that option. Without virtualization extensions, you need to resort to one of the following methods and require a lot of code changes.
Option 1 - Port the GUIDE OS API
Take all of your GUEST OS APIs and replace their implementation so that it mimics the required API behavior using the OS HOST API. Technically now your GUEST OS will not have a scheduler and will be scaled down to a portability level on top of your HOST OS. This method is used by companies when they need their software solutions to work across multiple RTOSs. They will write their RTOS based software solution. When a client comes to them with a request to run software on their RTOS, they simply port the RTOS API implementations to the client RTOS.
Option 2 - Para-virtualization
Your guest user and RTOS kernel space should be running as inside your OS user space. Let's divide the problem into several parts.
Processing privileged instructions
When your guest OS, executing Kernel Mode, tries to execute a privileged instruction, it will abort the undef command. You must modify your host kernel's undef command interrupt handler to capture / intercept these instructions and act on them. All privileged instructions must be captured / intercepted and "simulated". There are a few instructions that won't catch a trap, but will need to be handled by modifying the code. For example. If your kernel code reads CPSR to confirm execution mode, CPSR will say that mode is user mode. (This instruction will not interrupt the command, so you will not be able to follow the trap and simulate the model. The only way is to identify, search, and replace these instructions in your GUEST OS codebase.)
Memory control unit
If a privilege violation occurs, Data Abort will run on your host OS. It should be redirected to the guest OS.
Interrupts
You will need to replace the GUEST OS interrupt controller driver with dummy SVC calls that will call your OS HOST to set interrupts.
Timers
You will need to modify your GUEST timer driver to account for "lost" ticks when you perform OS HOST tasks.
Hardware Drivers
All other hardware drivers used by your GUEST OS must be modified to allow device sharing between GUEST and HOST.
Planners
Your GUEST OS scheduler is now running inside (and thus free) another scheduler (OS HOST scheduler).
source to share
It is possible. You need to share resources: memory, timers, interrupts, etc. Thus, the Host OS (FreeRTOS) does not even "know" about the resources used by the Guest OS (Nuttx).
For Cortex-A8, you can use IRQ for FreeRTOS and FIQ for GuestOS. This will keep you from rewriting the IRQ controller (but again, make sure the Host is not in control of the FIQ after GuestOS starts up).
Some changes may be required to switch context: you need to separate the Host-Host context switch, Host-Guest (and Guest-Host) switch, and the guest guest context.
source to share
While not a direct answer to your question, address this issue at the development level, separate the code that depends on the hardware (create an API), and make the application level code independent of the underlying OS or runtime, i.e. rather implementation specific. let it depend on the API.
where ever needed a port of hardware (OS) dependent programming code to base OS / Runtime
source to share