Skip to content

Boot Phase 1b.4: resolve partition-relative -> absolute disk LBA for DATA.IMG extents #21

Description

@StruckGuide8154

Context

The UEFI loader (src/boot/uefi_loader_storage_extents.inc, resolve_data_img_extents) walks the FAT32 \EFI\BOOT\DATA.IMG cluster chain while firmware block I/O is alive and coalesces the runs into the extent table at STORAGE_EXTENTS_ADDR (Phases 1b.2 and 1b.3 — both implemented). The captured extents are partition-relative LBAs.

What's missing (Phase 1b.4)

To let a future kernel backing driver write dirty ramdisk pages back to the ESP, the extents must be translated to absolute disk LBAs by adding the partition start LBA, read from the boot device's DevicePath HARDDRIVE (MEDIA_HARDDRIVE_DP) node.

Why deferred

No kernel block-device backing driver (NVMe / USB-MSC) exists yet, so VBE_STORAGE_CLASS_OFF stays 0 and ramdisk_flush is a no-op. The partition-relative extents already captured are correct input for this fixup; only the +partition_start offset and the class/LUN publish are missing.

Acceptance

  • Parse the boot device DevicePath, find the HARDDRIVE node, read PartitionStart.
  • Add PartitionStart to each extent's start LBA before publishing.
  • Set VBE_STORAGE_CLASS_OFF/VBE_STORAGE_LUN_OFF when a backing driver lands.
  • Keep the no-backing-driver path a safe no-op (fail-closed).

Tracked from a former TODO Phase 1b.4 in-code marker (maintainability-todo.md §4.3).

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions