🥮 mooncakes.io

    SongYZZZ/moon-firmware/validation does not have a README file

    CheckLevel

    source
    pub(all) enum CheckLevel {
      Disabled
      Warning
      Error
    } derive(Eq, 
    Debug    )

    Whether entry checks are disabled, advisory, or required for acceptance.

    CortexMReleaseOptions

    source
    pub(all) struct CortexMReleaseOptions {
      flash : 
    AddressRange
      ram : Array[
    AddressRange    ]
      vector_address : Int64
      page_size : Int
      erase_value : Byte
      stack_alignment : Int
      max_pages : Int
      max_output_bytes : Int
    } derive(Eq, 
    Debug    )

    Explicit Cortex-M target contract. RAM ranges accept a stack pointer at their exclusive end because startup stacks commonly begin at the top of RAM. Flash boundaries must be aligned to page_size so a whole-page plan cannot silently touch bytes outside the declared programming region.

    CortexMReleaseOptions::new

    source

    Construct a conservative release contract for one Flash and one RAM range.

    CortexMReleaseReport

    source

    Complete release-gate evidence. Layout and page plans remain available to callers; target-specific vector findings are accumulated instead of failing at the first bad field.

    CortexMReleaseReport::flash_plan

    source

    Validated flash-page plan, absent when layout or vector checks reject.

    CortexMReleaseReport::is_valid

    source
    fn CortexMReleaseReport::is_valid(self : CortexMReleaseReport) -> Bool

    A release passes only when address layout and Cortex-M vector checks pass and a bounded whole-page programming plan can be produced.

    CortexMReleaseReport::layout_report

    source

    Generic payload and optional metadata-entry layout evidence.

    CortexMReleaseReport::release_issues

    source

    Target-specific findings in deterministic validation order.

    CortexMReleaseReport::render

    source
    fn CortexMReleaseReport::render(self : CortexMReleaseReport) -> String

    Render release evidence without embedding firmware payload bytes.

    CortexMReleaseReport::vector_table

    source

    Decoded vector information, absent when the first eight bytes are missing.

    FlashOptions

    source
    pub(all) struct FlashOptions {
      page_size : Int
      erase_value : Byte
      max_pages : Int
      max_output_bytes : Int
      allowed_range : 
    AddressRange    ?
    } derive(Eq, 
    Debug    )

    Bounded whole-page programming settings. Page boundaries are aligned to address zero. erase_value must be chosen explicitly for the target device. allowed_range, when present, must contain every entire touched page.

    FlashOptions::new

    source
    fn FlashOptions::new(page_size : Int, erase_value : Byte) -> FlashOptions

    Plan with an explicit erase value and conservative allocation budgets. Page size must be a power of two from 1 through 1048576 bytes.

    FlashPage

    source

    One complete programming page. source_ranges identifies original occupied bytes so applications can distinguish payload from erased padding, even when payload bytes happen to equal the erase value.

    FlashPlan

    source
    pub struct FlashPlan {
      pages : Array[FlashPage]
      payload_bytes : Int
      output_bytes : Int
      erase_fill_bytes : Int
      page_size : Int
      erase_value : Byte
    } derive(Eq, 
    Debug    )

    Deterministic pages sorted by address. Only touched pages are included; untouched address gaps are not erased or represented in this plan. This is a data plan, not a flash programmer or device erase instruction.

    FlashPlan::render_manifest

    source
    fn FlashPlan::render_manifest(self : FlashPlan) -> String

    Summarize programmed addresses and padding without rendering payload bytes. The manifest helps inspect an erase plan before any device is contacted.

    LayoutIssue

    source
    pub struct LayoutIssue {
      rule : LayoutRule
      level : CheckLevel
      range : 
    AddressRange    ?
      region : String?
      message : String
    } derive(Eq, 
    Debug    )

    A specific violation. Ranges are half-open, matching the memory model. region is provided when an entry belongs to a non-executable named region.

    LayoutOptions

    source
    pub(all) struct LayoutOptions {
      regions : Array[MemoryRegion]
      segment_start_alignment : Int
      segment_length_alignment : Int
      max_payload_bytes : Int
      max_span_bytes : Int64
      entry_required : CheckLevel
      entry_mapped : CheckLevel
      entry_executable : CheckLevel
      entry_alignment : Int
      clear_entry_thumb_bit : Bool
    } derive(Eq, 
    Debug    )

    Layout constraints. Empty regions allow no payload; use one full-address region to permit any address. Entry normalization never changes the image. Alignment values are positive powers of two, and 1 disables alignment.

    LayoutOptions::new

    source

    Default constraints for an explicit target region list. Payload must fit those regions; entry placement problems are warnings, not parse errors.

    LayoutReport

    source
    pub struct LayoutReport {
      issues : Array[LayoutIssue]
      payload_bytes : Int
      address_span : Int64
      segment_count : Int
      checked_entry : Int64?
    } derive(Eq, 
    Debug    )

    Complete deterministic result. Invalid configuration raises FirmwareError; a valid configuration reports every layout violation without fail-fast.

    LayoutReport::is_valid

    source
    fn LayoutReport::is_valid(self : LayoutReport) -> Bool

    Warnings do not reject an image. A report can be accepted while advisory entry placement checks remain visible in issues.

    LayoutReport::render

    source
    fn LayoutReport::render(self : LayoutReport) -> String

    Produce a readable validation report without discarding typed rule data.

    LayoutRule

    source
    pub(all) enum LayoutRule {
      OutsideAllowedRegions
      SegmentStartAlignment
      SegmentLengthAlignment
      PayloadBudget
      SpanBudget
      MissingEntry
      EntryNotMapped
      EntryNotExecutable
      EntryAlignment
    } derive(Eq, 
    Debug    )

    Stable categories for machine-readable target-layout results.

    MemoryRegion

    source
    pub(all) struct MemoryRegion {
      name : String
      range : 
    AddressRange
      executable : Bool
    } derive(Eq, 
    Debug    )

    Named target region. Disjoint regions describe the allowed payload union; executable marks regions in which an execution entry is permitted.

    ReleaseIssue

    source
    pub struct ReleaseIssue {
      rule : ReleaseRule
      address : Int64?
      message : String
    } derive(Eq, 
    Debug    )

    One target-specific release violation with an optional relevant address.

    ReleaseIssue::at_address

    source
    fn ReleaseIssue::at_address(self : ReleaseIssue) -> Int64?

    ReleaseIssue::category

    source
    fn ReleaseIssue::category(self : ReleaseIssue) -> ReleaseRule

    ReleaseIssue::description

    source
    fn ReleaseIssue::description(self : ReleaseIssue) -> String

    ReleaseRule

    source
    pub(all) enum ReleaseRule {
      VectorTableMissing
      StackPointerOutsideRam
      StackPointerMisaligned
      ResetThumbBitMissing
      ResetHandlerOutsideFlash
      ResetHandlerUnmapped
    } derive(Eq, 
    Debug    )

    Stable reasons why a Cortex-M release image is rejected by its target gate.

    plan_flash_pages

    source

    Build complete bytes only for pages containing occupied firmware addresses. Missing bytes within touched pages use erase_value, including bytes outside image bounds. This deliberately does not preserve existing device content: callers must obtain/merge that content first when retention is required. Page count, allocation limits and permitted programming bounds are checked before page buffers are allocated. The input image is never modified.

    validate_cortex_m_release

    source

    Validate a firmware image as a Cortex-M release artifact and build the exact set of touched whole Flash pages. This function performs no device I/O.

    validate_layout

    source

    Validate occupied address ranges, budgets, alignment and execution entry against a board layout. Work is proportional to payload/segment snapshots and region boundaries, never the numeric distance between sparse segments. Diagnostic order is budgets, occupied regions in address order, then entry.

    Source Files

    Powered by MoonBit

    Site sourceReport issuePackagesBuild queueSkillsStatistics

    © 2026 mooncakes.io