Home

Awesome

<h1 align="center"> <img width="300" src="https://raw.githubusercontent.com/EDI-Systems/M7M2_MuAmmonite/master/Documents/Demo/logo.png" alt="logo"> </h1>

Unity Platform (RVM)

点击 这里 查看中文版。

    RVM is a virtual machine monitor (VMM) specifially designed for microcontrollers (MCUs). This VMM can efficiently paravirtualize many RTOSes and bare-metal frameworks. This is a groundbreaking technology and the future of IoT systems, and delivers many possibilities previously considered impossible. With unprecedented scalability, it can run 64 virtual-machines on 1MB SRAM.

    The manual of the virtual machine monitor can be found here.

    Read Contributing and Code of Conduct if you want to contribute, and Pull Request Template when you make pull requests. This software is an official work of EDI, and thus belongs to the public domain. All copyrights reserved by EDI are granted to all entities under all applicable laws to the maximum extent.

    For vendor-supplied packages and hardware abstraction libraries, please refer to the M0P0_Library repo to download and use them properly. This VMM depends on M7M1 micro-kernel OS as well.

Introduction to virtualization

    Virtualization is a technology that creates logical copies of the same hardware thus that multiple bare-metal programs and operating systems can coexist on the same hardware platform. On the PC architecture, virtual machine monitors such as VMware and Virtual Box have been around for decades, and have since shaped our IT infrastructure till today. The main reason to run multiple virtual machines on the same piece of hardware include increased isolation, ease of deployment and flexible management of computational resources.

    There are two types of virtualization: full-virtalization and para-virtualization. The former can run an unmodified image of the operating system; while the latter requires the operating system to be modified to some extent. RVM employs the para-virtuliation technology to reduce the time and memory overhead. It provided hypercalls for many sensitive priviledged operations.

Why do we need virtualization on MCUs?

    The virtualization technology will shape the future of Internet-of-Things (IoT) systems, just like how it shaped our IT infrastructure today. However, the reasons for this are different: on microcontrollers, the reasons to use this technology is reliability, security and flexibility.

Reliability

    Traditional RTOSes employ static code analysis and certification to reach its reliability goal. However, this have proved insufficient for many scenarios; besides the RTOS itself, the following will also introduce errors in the system:

    Though these weaknesses can be mitigated with watch-dog timers (WDTs) by rebooting the system, this method only works for simple applications. For more complex applications or critical applications that cannot afford a complete reboot, traditional RTOSes can do nothing about this situation.

Security

    Traditional RTOSes generally does not consider information security as their design goal. They fail to meet security goals for future IoT systems. As stated in the reliability section, hackers can hack into the system and sabotage any part if they want to; usually a buffer overflow attack is sufficient. This is not the worst yet. The following situations can be much worse than a simple sabotage:

Flexibility

    The embedded software market have long been fragmented. Different RTOSes or software stacks target different markets, and they are mutually incompatible. This was fine because embedded systems have long been designed for a dedicated purpose; nevertheless this assumption is no longer true today. IoT devices face increasing needs to integrate multiple functions.

    Instead of developing an RTOS that supports all the features, virtualization technology can let the different stacks coexist on the same physical machine. This will allow many new possibilities, yet it does not require the programmer to changed thei mental model of RTOS software development.

Wouldn't the virtualization solution be very costly?

    Short answer: No.

    Long answer: If the virtualization features are designed carefully and used correctly (especially the communication mechanisms), the virtualization overhead is negligible. Despite being virtualized, FreeRTOS's context switch and interrupt response is just 4x of the original FreeRTOS, and is still 25x better than RT-Linux. For those CPU-hungry virtual machines that do not do I/O much, the overhead is negligible.

    Some may argue that an Unix designed for MCUs will be good enough and we don't need virtualization; however this will involve reinventing the wheel and in the end you get something no better than Linux, or another VxWorks (there are some small RTOSes that dash in this direction which we don't appreciate). Linux is not considered reliable and secure* at all in embedded systems; it is flexible but incurs unacceptable memory overhead, so this doesn't mitigate the overhead issue and instead exacerbate it. On the other hand, virtual-machines are inherently safe and modular, not to mention that the underlying RME system provides capability-based security.
*The reason why Linux is considered unsafe in embedded realm is that many embedded devices never update their kernel to the latest version. This caused them to rely on an outdated kernel whose vulnerabilities are well-known to all. You can randomly pick a ready-made tool then scan these routers and IP cameras, and get as many zombies as you want. Oh yes, this also plagues the old Android mobile phones.

Context switch time and interrupt response time are inflated by 4x. Is it acceptable?

    For MCUs that are supported by RVM, yes. Because this VMM targets high-end MCUs, where the bare-metal RTOS response time is a overkill for many sensors and actuators. A Cortex-M4 @ 180MHz running virtualized FreeRTOS will have the same interrupt response time and context switch time of a Cortex-M3 @ 72MHz running bare-metal FreeRTOS.

    In terms of I/O response time, the Cortex-M3 is sufficient; we choose to use Cortex-M4 in these applications for enhanced computing capability, not response time. If your application does need a very low response time, you can write RME native applications, which have similar response time when compared to FreeRTOS. If you are using something faster than Cortex-M4 (e.g. Cortex-M7, TMS320C66X), you can ignore the overhead issue.

How much do I need to change my existing code to port it to the VMM?

    Very little; please read the manual for details. Actually many software packets are already available on the platform, so there's no need to port by yourself. For a comprehensive list of them, read the section below.

Available system components

    All the systems that have been virtualized on RVM is shown below. If a github link is provided, the component is available for now. New ports are being added at a constant rate.

List of hyper calls

HypercallNumberDescription
RVM_HYP_ENAINT0Enable virtual machine interrupts
RVM_HYP_DISINT1Disable virtual machine interrupts
RVM_HYP_REGINT2Register a virtual machine interrupt
RVM_HYP_DELINT3Delete a virtual machine interrupt
RVM_HYP_REGEVT4Register a virtual machine event
RVM_HYP_DELEVT5Delete a virtual machine event
RVM_HYP_WAITEVT6Wait for an interrupt or event to come
RVM_HYP_SENDEVT7Send an event to a virtual machine
RVM_HYP_QUERYEVT8Search for an event
RVM_HYP_QUERYVM9Search for a virtual machine
RVM_HYP_TIMPROG10Reprogram virtual machine timer interrupt interval
RVM_HYP_PRINT11Print to console

Typical performance figures for all supported architectures

Single-core microcontrollers

MachineToolchainRTOSFlashSRAMYieldMailSemMail/ISem/IMem
Cortex-M4Keil uVision 5RMP
Cortex-M4Keil uVision 5FreeRTOS
Cortex-M4Keil uVision 5uCOSIII
Cortex-M4Keil uVision 5RT-Thread
Cortex-M7Keil uVision 5RMP2.092.2910681179122114021444176
Cortex-M7Keil uVision 5FreeRTOS
Cortex-M7Keil uVision 5uCOSIII
Cortex-M7Keil uVision 5RT-Thread
Cortex-R4TI CCS7RMP
Cortex-R5TI CCS7RMP
MIPS M14kXC32-GCCRMP

*Cortex-R4 and Cortex-R5 are listed here as single-core architectures because their main selling point is CPU redundancy, thus from the viewpoint of the programmer they behave as if they have only one core. Dual-core mode of these two processors are not supported.

    Flash and SRAM consumption is calculated in kB, while the other figures are calculated in CPU clock cycles. All values listed here are typical (useful system) values, not minimum values, because minimum values on system size seldom make any real sense. HAL library are also included in the size numbers.

Multi-core microcontrollers

MachineToolchainRTOSFlashSRAMYieldMailSemMail/ISem/IMem
Cortex-R7TBDRMP
Cortex-R8TBDRMP
TMS320C66XTI CCS7RMP

    Flash and SRAM consumption is calculated in kB, while the other figures are calculated in CPU clock cycles. HAL library are also included in the size numbers. The absolute minimum value for MPU-based microprocessor-profile RME is about 64k ROM/32k RAM.

    In the 2 tables above, all compiler options are the highest optimization (usually -O3) and optimized for time.

Getting Started

    These instructions will get you a copy of the project up and running on your local machine for development and testing purposes. See deployment for notes on how to deploy the project on a live system.

Prerequisites

    You need to choose a hardware platform listed above to run the tests. M7M1 is also needed t run the tests.

Compilation

    The Vendor Toolchain or GNU Makefile projects for various microcontrollers are available in the Project folder. Refer to the readme files in each folder for specific instructions about how to run them. However, keep in mind that some examples may need vendor-specific libraries such as the STM HAL. Some additional drivers may be required too.

    If you are using the windows operating system, copy the binary to C converter to the folder that contains your compiler.

    Keil\ARM\ARMCC\bin\bincopy.exe
    gcc-installation-folder\bincopy.exe

Running the tests

    To run the sample programs, simply download them into the development board and start step-by-step debugging. All hardware the example will use is the serial port, and it is configured for you in the example.

Deployment

    When deploying this into a production system, it is recommended that you read the manual in the Documents folder carefully to configure all options correctly. It is not recommended to configure the kernel yourself, anyway; it included too many details. Please use the default configuration file as much as possible. Also, read the user guide for the specific platform you are using.

Built With

    Other toolchains are neither recommended nor supported at this point, though it might be possible to support them later on.

Contributing

    Please read CONTRIBUTING.md for details on our code of conduct, and the process for submitting pull requests to us.

EDI Project Information

    Mutate - Mesazoa - Ammonite (M7M2 R2T1)