Skip to content

Xita Firmware System

Cody Fagley edited this page Jul 21, 2021 · 4 revisions

Firmware Development is the one place where developers are allowed to directly access memory addresses. To allow this, there are several strict rules and policies on how these interactions take place.

*.chip Files

In order to cross-compile to a new device, Xita requires a target Chip be named for memory mapping purposes. (At present, Raspberry Pi 3 is assumed if nothing is named.) The standard cross-compiler comes with a standard collection of files with .xdvc file extension; each of these represent Xita-compliant Chip Layouts.

The primary purpose of a .chip file is to list a collection of memory addresses that require firmware drivers. There can only be one active firmware driver for each unique name.

Proposed Format/Structure (Obviously subject to change)
--  Chip Name (used in terminal options, etc.)
rpi3
--  Set Desired Assembly Language
arch="AArch64"

--  Desired Memory Mappings and Firmware Interfaces
GPIO:  0x3F215000 + 0xD4;
BSC:   0x3F205000 + 0x1C, 
       0x3F804000 + 0x1C, 
       0x3F805000 + 0x1C;
DMA:   0x3F007000 + 0x1400,
       0x3FE05000 + 0x100;
SPI:   0x3F204000 + 0x14;
Timer: 0x3F003000 + 0x18;

Firmware Drivers

Each chip can have a collection of firmware drivers written in Xita's functional language. Each firmware driver addresses a unique named Firmware Interface, defined in the loaded .chip file.

Once the firmware driver is defined correctly, it can freely access any memory address within the predefined interface range. As an example, see the following Driver file:

--  Match up with firmware interfaces named "Timer" in `.chip` files
Firmware "Timer"

--  Legal, because Timer owns the requested address
let getStatus = 0x3F003000 *-> return

--  Illegal and will throw compiler error
--  Timer does not own this address for the defined chip
let getSPIStatus = 0x3F204000 *-> return