DeosMicro

Overview

Project to get Deos support for processors that do not support virtual memory, for example ARM R and M cores.

NOTE: As of ARMv8 the 64-bit R cores now optionally support virtual memory via an MMU. Theoretically this would support Deos directly.

Proposal

For ARM R cores that are 32-bit, or 64-bit R cores that don't support an MMU, the R cores optionally have an MPU. Apparently having an MPU has been available for quite some time, since at least ARM architecture 7. This was not Aaron's understanding prior to Jan 2025, however the v7-R ARM architecture reference manual is pretty clear that an MPU was defined by the architecture. We have not researched which R cores had an MPU, but apparently many, perhaps all, did.

Ryan and Aaron were talking about how "physical" (no virtual memory) Deos could support ARM R cores that have only an MPU, or even have no MPU, and we have a high level design that substantially reduces our previous estimates. We think there could be a prototype kernel in 6-12 months. The hope is that "physical Deos" kernel would use the same code base as the "virtual Deos" kernel. In fact a high level design goal would be to make the API as close to the same as possible. There could easily be complications related to dead code, documentation, and tests.

The initial prototype would not support space partitioning, but we believe that space partitioning could be added with modest effort for processors that support an MPU. We have not done the necessary research to determine whether time partitioning could be supported or not, but our guess is that it could. The space partitioning might be somewhat coarse grained, e.g., "process A either has access to all devices or it does not have access to any device" whereas virtual Deos provides access (or not) to specific devices. It might be possible (likely would) to do better in later releases. E.g., a process can have access to at most 4 platform resources and 4 shared memory objects.

Note this does not include ARM M cores, primarily because the M cores only support Thumb instructions, but likely the M cores could be added later with modest effort. Due to restrictions on the M cores (limited number of MPU region registers), it is unlikely there would be space partitioning, or the space partitioning would be very coarse.

Applications would need to be recompiled. It is not clear whether the resulting application binaries could be shared between ARM A and R cores, or between R and M cores, or if R and M cores would be new architectures. There would definitely be at least one new architecture for the kernel.

All of the above is with "ROM level" confidence, of course.

Restrictions

There would be some notable restrictions on system configurations and to certain APIs. For example,

1. We'd likely restrict processes to all be auto created
2. There would be restrictions on various APIs, e.g., attachPlatformResourceAtAddress() would not be able to specify the address, virtualAllocDEOS's virtual address parameter would not be honored, etc.
3. Delete process, and most "free" like APIs would not be supported, e.g., virtualFreeDEOS(), freeLibraryDeos(), etc.
4. Set based cache partition would not be supported. Cache paritioning based on Way locking would depend on HW capabilities.

Design notes

Key ideas:

1. Kernel POM and user space would be allocated in a contiguous region of size specific to each process. A memory pool would be constructed representing the user space region.
2. Since virtual==physical; allocation/attach APIs would simply return the address of the "next page", or of a platform resource.
3. The VAS code would likely be replaced by a vector tracking the process' currently accessible regions, one of which would be the entire process specific user address space.
4. User thread stacks would be moved to be co-located with user-space.
5. Everything, perhaps including the kernel, would have to become PIC.
6. The effects on BSPs is unaddressed.
7. Low memory (test results, video, boot stacks, etc.) would likely have to re-arranged to group areas with similar access rights.
8. If the hyperstart was based on an MFS, then the kernelEntryAddress could just be the libkernel.so's entrypoint address within the MFS, and on boot the kernel entry code could copy the kernel where it needed to go.
9. If the HAL was broken into three parts, non-address related, hal-virt, and hal-phys, then there could be vas, pagetab, portal, and procmem code in hal-virt; and alternate vas, portal, and procmem code in hal-phys. The interfaces might need to be slightly different than current, but there are only ~50ish interesting function calls to vas and portal interfaces, so two different invariants and precondition analysis on the called functions would likely abstract most of the virt vs phys differences.

Early sales feedback

1. Customers are looking at cortex-M parts with quite limited RAM, but with FLASH that is (presumably) fast enough to execute from.
2. Multi-core is strongly desired, perhaps required in some cases.
3. AMP will required for systems comprised of both Deos and DeosMicro.
4. AMP may be required even for systems comprised of just DeosMicro.
5. Network based development tools (debugger, etc.) are required.

MPU Research

1. R52 (2016) The TRM says this processor has an MPU and optionally supports EL2. The TRM does not indicate MPU support is optional and the TRM says the number of regions is 16, 20, or 24.
2. The Arm Cortex-R Processor Comparison Table indicates all R cores (R4, 5, 7, 8, 52, 52+, and 82) have a MPU, none with less than 12 regions, and starting with R8 (released in 2016) all have 24 regions or more. Release date info from wikipedia.