Executive Summary
This guide addresses the fundamental architectural challenge of integrating the ASPEED AST1060 chip with Hubris OS. The core issue is that Hubris assumes code executes directly from Flash (XIP - eXecute In Place), while the AST1060's ROM bootloader loads images from SPI flash into RAM for execution. This document provides practical solutions for ASPEED teams to successfully deploy Hubris on AST1060 platforms.
Understanding the Challenge
Hubris OS Flash Architecture Assumptions
Hubris is designed around the assumption that task executable code is in execute-in-place Flash and immutable. The operating system expects:
- Direct code execution from Flash memory
- Memory-mapped Flash access for immediate instruction fetching
- Static task layout with predictable Flash addresses
- No runtime code relocation or loading mechanisms
The kernel doesn't do anything to the task's executable code, which is assumed to be in execute-in-place Flash and immutable. (Hubris has no equivalent to a "loader.")
AST1060 Boot Architecture Reality
The AST1060 is embedded with a high-performance ARM Cortex CPU and uses internal flash and SRAM architecture. However, the chip's boot process follows this sequence:
ROM Bootloader Execution: On power-up, the AST1060's ROM bootloader starts
- SPI Flash Reading: The ROM reads the application image from external SPI flash
- RAM Loading: The complete image is copied from SPI flash to internal SRAM
- Execution Transfer: Control jumps to the loaded code in RAM
This creates a fundamental mismatch: Hubris expects XIP from Flash, but AST1060 loads everything into RAM.
Solution Architecture
The simplest and most elegant approach is to configure Hubris to treat the AST1060's SRAM (where the ROM bootloader loads the image) as if it were Flash memory. This requires zero changes to Hubris core assumptions.
Partition the SRAM into separate image (RAM masquerading as flash) and data regions
- The ROM bootloader has already loaded everything into SRAM before Hubris starts
- SRAM is faster than real Flash for execution, improving performance
- No code changes needed in Hubris - it's purely a configuration change.
Executive Summary
This guide addresses the fundamental architectural challenge of integrating the ASPEED AST1060 chip with Hubris OS. The core issue is that Hubris assumes code executes directly from Flash (XIP - eXecute In Place), while the AST1060's ROM bootloader loads images from SPI flash into RAM for execution. This document provides practical solutions for ASPEED teams to successfully deploy Hubris on AST1060 platforms.
Understanding the Challenge
Hubris OS Flash Architecture Assumptions
Hubris is designed around the assumption that task executable code is in execute-in-place Flash and immutable. The operating system expects:
The kernel doesn't do anything to the task's executable code, which is assumed to be in execute-in-place Flash and immutable. (Hubris has no equivalent to a "loader.")
AST1060 Boot Architecture Reality
The AST1060 is embedded with a high-performance ARM Cortex CPU and uses internal flash and SRAM architecture. However, the chip's boot process follows this sequence:
ROM Bootloader Execution: On power-up, the AST1060's ROM bootloader starts
This creates a fundamental mismatch: Hubris expects XIP from Flash, but AST1060 loads everything into RAM.
Solution Architecture
The simplest and most elegant approach is to configure Hubris to treat the AST1060's SRAM (where the ROM bootloader loads the image) as if it were Flash memory. This requires zero changes to Hubris core assumptions.
Partition the SRAM into separate image (RAM masquerading as flash) and data regions