GIET-VM documentation

A) Mapping_Info data structure

B) Peripherals Drivers

The GIET_VM supports two types of peripheral components: External peripherals are located in one single cluster (called cluster_io, and identified by the X_IO,Y_IO variables); Internal peripherals are replicated in all clusters.

Each driver xxx_driver define two low-level functions _xxx_get_register() and _xxx_set_register() to access the peripheral addressable registers. These functions are in charge to compute the peripheral registers addresses, taking into account the peripheral base address, the register index, and the cluster coordinates:

• External peripherals: All accesses use virtual addresses if the MMU (Memory management Unit) is activated, or physical addresses if it is not. In this case, the physical address is computed as pbase = SEG_XXX_BASE + cluster_io << 32.

• Internal peripherals: All accesses use virtual addresses, and the MMU must be activated. The peripheral virtual base address is computed as vbase = SEG_XXX_BASE + cluster_xy * PERI_CLUSTER_INCREMENT.

The SEG_XXX_BASE , X_IO, Y_IO, and PERI_CLUSTER_INCREMENT variables must be defined in the hard_config.h" file.

BDV (Block Device controller)

CMA (Chained Buffer DMA controller)

DMA (Multi-Channels DMA controller)

FBF (Frame Buffer controller)?

HBA (AHCI Disk controller)

ICU (Interrupt controller)?

IOB (I/O Bridge controller)

IOC (Generic I/O controller)

MMC (Memory Cache controller)

NIC (Gigabit Ethernet Network controller)

PIC (External Peripherals Interrupt controller)

SIM (Monitor controller)

SPI (SPI Disk controller)?

TIM (Multi Timers controller)

TTY (Multi Terminals TTY controller)

XCU (Extended Interrupt controller)

C) Shared kernel functions

The boot code and the kernel code are two separated compilation units, but some functions are used by both the boot code and the kernel code:

• They are used by the boot-loader in the static phase, to build the page tables and initialize the schedulers and the peripherals.
• They are used by the kernel in the dynamic phase, to handle events such as interrupts, exceptions and syscalls.

CP0 registers access functions

CP2 registers access functions

Physical addressing functions

Locks access functions

TTY0 access functions

Task context access functions

Mapping access functions

Physical memory allocators

Virtual to physical address translation

Miscelaneous kernel functions?

Y) Boot-loader functions

W) Kernel functions

The GIET acronym stands for Gestionnaire Interruptions, Exceptions & Trappes.

This section describe the kernel functions, supporting Interrupts, Exceptions and Traps (i.e. syscalls).

Interrupt Handler

Exception Handler

Syscall Handler

Context Switch Handler

Z) User level libraries

This section describes the user libraries :

Stdio library

This library contains all system calls allowing an application to access a protected ressource (peripheral register, or protected processor register). Each function in this library contains at least one SYSCALL instruction to enter the kernel mode.

Stdlib user library

This library contains various utility functions that do not use system calls.

MWMR user library

This library defines a communication middleware supporting channelised communications in a multi-tasks parallel application. This middleware does not use system calls.

Barrier user library

This library contains functions used to synchronize severals tasks in a multi-task parallel application. Most of these functions do not use system calls.

Spin_lock user library

This library contains functions used to provide exclusive access to a shared ressource in a multi-task parallel application. These functions do not use system calls.

Malloc user library

This library contains functions allowing an user application to dynamically allocate virtual memory from the application heap. When the target architecture is clusterized (several physical banks), the heap is physically distributed on the clusters, and there is actually on allocator per cluster.