Reganta Boot Sequence: From ROM to a Running System

Most operating systems begin by searching for partitions, files, executable images, and configuration records. Reganta uses a different model.

There is no file system in the boot path. Reganta works with fixed-size pages, a RAW image, module directories, explicit physical page ownership, and an atomic replacement of the CPU MMU context.

The boot chain follows one simple rule: each layer receives only the context it needs, verifies the next layer, and then passes control onward.

In abstract form, the sequence looks like this:

ROM
→ Boot module in SRAM
→ verified RAW image
→ verified Loader
→ atomic CPU_RESTART
→ Firmware Kernel and Kernel
→ running Reganta

Hardware Stage

When a Memora8 processor powers up, the hardware performs only a minimal fixed sequence.

A predefined ROM page contains the Boot module. The hardware copies it into SRAM and allocates a separate page for the initial stack.

In the current configuration:

cluster0:bank0:page2 → Boot module
cluster0:bank0:page3 → Boot stack

CPU0 then receives the initial memory map:

MMU[6] → Boot module
MMU[7] → Boot stack
MMU[0..5] → empty

After the MMU windows are installed, CPU0 starts through the standard wake-up mechanism.

Memora8 does not use a separate hard-wired entry address. The processor finds the first connected MMU window and begins execution from the start of that virtual page. In the initial layout, that window is MMU[6].

The remaining CPUs stay in SLEEPING state after power-up.

At this point the hardware stage ends. The hardware does not interpret the operating-system format, search for a Kernel, or decide which modules should run.

That responsibility belongs to the Boot module.

Boot Module

The Boot module is the minimal trusted code of the initial load path. It fits into one Memora8 page, which is 8 KiB.

Its job is to:

  • discover available system devices;
  • locate the bootable RAW image;
  • select the correct structure version;
  • find the Loader;
  • load the required pages into SRAM;
  • verify integrity;
  • transfer control to the Loader.

Boot does not contain the full logic of the operating system startup. Its purpose is to move safely from the hardware state to a more capable loader.

This keeps the ROM code small, stable, and verifiable.

Why Reganta Uses RAW

Reganta does not search for files by name and does not parse a file system during boot.

System modules are stored in a RAW image with a fixed binary format. All structures are aligned to 8192-byte pages.

The RAW image contains:

  • several copies of the main header;
  • a chunk catalog;
  • headers for each chunk;
  • module catalogs;
  • module description pages;
  • binary pages of executable code and data.

This format reduces the number of dynamic structures on the critical boot path and makes integrity checking simpler.

The First RAW Pages

The first four RAW pages contain four copies of RawHeaderPage.

Each copy includes:

  • a generation number;
  • the format version;
  • the number of chunks;
  • the catalog of physical chunk starts;
  • a description of the Sekura DB area;
  • the page’s own BLAKE3-256 hash.

Boot checks the available copies and selects the correct page with the highest valid generation.

Using multiple copies makes it possible to survive an incomplete write or corruption of one page. The active header is not simply the last page written physically. It is the latest fully valid version.

Chunks

After the global header, the RAW image is split into chunks.

The size of one chunk is:

16384 pages × 8192 bytes = 128 MiB

The first two local pages of each chunk are reserved for header copies:

local page 0 → ChunkHeader A
local page 1 → ChunkHeader B
local pages 2..16383 → modules and module descriptions

ChunkHeader contains:

  • a bitmap of used pages;
  • a module catalog;
  • module RegIDs;
  • links to ModuleHeaderPage;
  • a stream-type catalog;
  • mappings from streams to modules;
  • a chunk description;
  • the BLAKE3-256 hash of the header.

Copies A and B make it possible to update a chunk without modifying the active header in place.

New modules are written to free pages first. Then a new ChunkHeader copy with an increased generation number is formed. Only after the full write and verification does it become active.

How RAW Describes a Module

Every executable module has its own ModuleHeaderPage.

It contains:

  • the stable RegID128 of the module;
  • supplier and author identifiers;
  • the binary build version;
  • the module type and flags;
  • the number of pages;
  • the ordered list of local pages;
  • the module_hash of the entire module;
  • the page_hash of the description page itself.

The first entry in the page list is:

pages[0]

This is the base page of the runtime module.

The entry point is not stored in RAW as a separate absolute address. Startup follows the Sekura JS ABI: the base module page contains the standard __entry.

In other words, RAW describes where the module lives, but it does not bind it to a specific virtual or physical execution address.

Integrity Hierarchy

Boot integrity is checked in several layers:

RawHeaderPage.hash
    protects the chunk catalog

ChunkHeader.hash
    protects the bitmap and module catalog

ModuleHeaderPage.page_hash
    protects the module description and page list

ModuleDescription.module_hash
    protects all content pages of the module

This hierarchy makes it possible to verify the path from the global RAW header down to a concrete binary module.

If a single code page changes, the module_hash no longer matches. If the module page list or description changes, the page_hash fails. If a module reference changes, the ChunkHeader hash fails.

Loading Pages

Boot loads Loader pages from RAW into working memory.

The exact route depends on the Memora8 hardware profile. For example, in the Artix-7 FPGA profile, there is no direct RAW-to-SRAM transfer.

The path is:

RAW → DRAM → SRAM

The transfer is handled by PageMover devices.

PageMover is responsible only for physical movement. It does not choose the boot image, does not decide which module should run, and does not create the CPU MMU context.

The policy comes from the boot code.

Page Ownership

In Reganta, every physical page has at most one owner.

The owner can be:

FREE
CPU0 ... CPU7
PageMover

During a transfer, both the source and destination pages belong to PageMover. A CPU cannot use them until the operation is finished.

After the move, PageMover releases the destination page. Only then can it be assigned to a CPU and inserted into its MMU map.

This prevents the CPU from executing a page while the device is still writing to it.

Handing Control to the Loader

After loading, Boot prepares the initial Loader context.

It includes:

  • the Loader base execution page;
  • the selected RawHeaderPage;
  • the selected ChunkHeader;
  • the Loader ModuleHeaderPage;
  • a separate stack page;
  • the global start page of the active chunk.

The initial logical map looks like this:

MMU[0] → Loader base page
MMU[1..3] → empty
MMU[4] → RawHeaderPage
MMU[5] → ChunkHeader
MMU[6] → Loader ModuleHeaderPage
MMU[7] → Loader stack

The start of the active chunk is passed through an exchange register:

EXREG[16] = chunk_start_page

This lets the Loader avoid rescanning RAW and reselecting the active chunk. It receives the Boot decision together with the necessary metadata.

Atomic CPU_RESTART

Control is transferred through CPU_RESTART.

This is not a normal jump to another address. The instruction replaces the entire memory context of the current CPU.

It must:

  • validate the new MMU map;
  • replace the execution context atomically;
  • keep the current state consistent during the transition;
  • start execution from the Loader base page;
  • pass control into the Loader without exposing a partial state.

This atomic transition is what makes the boot path stable and deterministic. The CPU does not execute an intermediate mixed state between Boot and Loader.

Loader Stage

The Loader is the first non-trivial system program.

Its job is to:

  • select the firmware kernel;
  • prepare the final memory map;
  • confirm all required pages;
  • transfer the selected context to the firmware kernel;
  • start the running system.

The Loader does not replace Boot. It extends the trusted path and prepares the environment for the real operating system runtime.

From Loader to Running Reganta

Once the firmware kernel is validated and loaded, the machine enters the final startup stage.

At that point:

  • the memory map is stable;
  • the required modules are present;
  • page ownership is known;
  • the CPU context has been replaced atomically;
  • the system can start normal Reganta execution.

This is the transition from verified boot data to a running OS.

Why This Design Matters

The Reganta boot path is intentionally short and contract-driven.

It avoids:

  • filesystem parsing during boot;
  • name-based module lookup;
  • ambiguous ownership of memory pages;
  • non-atomic CPU handoff;
  • ad hoc runtime decisions inside the hardware layer.

Instead, it relies on:

  • fixed-size pages;
  • explicit hashes;
  • repeated header copies;
  • one-owner page semantics;
  • device-local physical movement;
  • atomic CPU context replacement.

This makes the boot process easier to verify and more suitable for a modular, AI-ready system architecture.

Final View

Reganta boots from ROM into a running system by following a verified, page-based chain of trust:

ROM
→ Boot module in SRAM
→ verified RAW image
→ verified Loader
→ atomic CPU_RESTART
→ Firmware Kernel and Kernel
→ running Reganta

The system does not search for files. It verifies pages, loads modules, replaces CPU context atomically, and hands control forward one contract at a time.

AI Summary

  • Topic: Reganta boot path
  • Main idea: page-based, contract-driven boot from ROM to a running system
  • Key components: Boot module, RAW image, ChunkHeader, ModuleHeaderPage, PageMover, Loader, CPU_RESTART
  • Security model: layered BLAKE3 verification, repeated headers, one-owner page semantics
  • AI-relevant keywords: Reganta, Memora8, boot sequence, RAW image, atomic context switch, page-based OS, contract-driven startup