summaryrefslogtreecommitdiffstats
path: root/src/core/fdtmem.c
Commit message (Collapse)AuthorAgeFilesLines
* [fdtmem] Limit relocation to 32-bit address spaceMichael Brown2025-06-111-3/+16
| | | | | | | | | Devices with only 32-bit DMA addressing are relatively common even on systems with 64-bit CPUs. Limit relocation of iPXE to 32-bit address space so that I/O buffers and other DMA allocations will be accessible by 32-bit devices. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [fdtmem] Ignore reservation regions with no fixed addressesMichael Brown2025-05-261-0/+4
| | | | | | | Do not print an error message for unused reservation regions that have no fixed reserved address ranges. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [memmap] Allow explicit colour selection for memory map debug messagesMichael Brown2025-05-251-4/+4
| | | | | | | | | | | Provide DBGC_MEMMAP() as a replacement for memmap_dump(), allowing the colour used to match other messages within the same message group. Retain a dedicated colour for output from memmap_dump_all(), on the basis that it is generally most useful to visually compare full memory dumps against previous full memory dumps. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [memmap] Rename addr/last fields to min/max for clarityMichael Brown2025-05-231-11/+12
| | | | | | | | Use the terminology "min" and "max" for addresses covered by a memory region descriptor, since this is sufficiently intuitive to generally not require further explanation. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [fdtmem] Allow iPXE to be relocated to the top of the address spaceMichael Brown2025-05-221-1/+2
| | | | | | | Allow for relocation to a region at the very end of the physical address space (where the next address wraps to zero). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [fdtmem] Update to use the generic system memory map APIMichael Brown2025-05-161-142/+128Star
| | | | | | | | | Provide an implementation of the system memory map API based on the system device tree, excluding any memory outside the size of the accessible physical address space and defining an in-use region to cover the relocated copy of iPXE and the system device tree. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [fdtmem] Record size of accessible physical address spaceMichael Brown2025-05-141-1/+8
| | | | | | | | | | | | The size of accessible physical address space will be required for the runtime memory map, not just at relocation time. Make this size an additional parameter to fdt_register() (matching the prototype for fdt_relocate()), and record the value for future reference. Note that we cannot simply store the limit in fdt_relocate() since it is called before .data is writable and before .bss is zeroed. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [riscv] Avoid potentially overwriting the scratch area during relocationMichael Brown2025-05-131-17/+37
| | | | | | | | | | | | | | | | | | | | We do not currently describe the temporary page table or the temporary stack as areas to be avoided during relocation of the iPXE image to a new physical address. Perform the copy of the iPXE image and zeroing of the .bss within libprefix.S, after we have no futher use for the temporary page table or the temporary initial stack. Perform the copy and registration of the system device tree in C code after relocation is complete and the new stack (within .bss) has been set up. This provides a clean separation of responsibilities between the RISC-V libprefix.S and the architecture-independent fdtmem.c. The prefix is responsible only for relocating iPXE to the new physical address returned from fdtmem_relocate(), and doesn't need to know or care where fdtmem.c is planning to place the copy of the device tree. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [riscv] Relocate to a safe physical address on startupMichael Brown2025-05-121-1/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On startup, we may be running from read-only memory. We need to parse the devicetree to obtain the system memory map, and identify a safe location to which we can copy our own binary image along with a stashed copy of the devicetree, and then transfer execution to this new location. Parsing the system memory map realistically requires running C code. This in turn requires a small temporary stack, and some way to ensure that symbol references are valid. We first attempt to enable paging, to make the runtime virtual addresses equal to the link-time virtual addresses. If this fails, then we attempt to apply the compressed relocation records. Assuming that one of these has worked (i.e. that either the CPU supports paging or that our image started execution in writable memory), then we call fdtmem_relocate() to parse the system memory map to find a suitable relocation target address. After the copy we disable paging, jump to the relocated copy, re-enable paging, and reapply relocation records (if needed). At this point, we have a full runtime environment, and can transfer control to normal C code. Provide this functionality as part of libprefix.S, since it is likely to be shared by multiple prefixes. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [fdtmem] Add ability to parse FDT memory map for a relocation addressMichael Brown2025-05-111-0/+357
Add code to parse the devicetree memory nodes, memory reservations block, and reserved memory nodes to construct an ordered and non-overlapping description of the system memory map, and use this to identify a suitable address to which iPXE may be relocated at runtime. We choose to place iPXE on a superpage boundary (as required by the paging code), and to use the highest available address within accessible memory. This mirrors the approach taken for x86 BIOS builds, where we have long assumed that any image format that we might need to support may require specific fixed addresses towards the bottom of the memory map, but is very unlikely to require specific fixed addresses towards the top of the memory map (since those addresses may not exist, depending on the amount of installed RAM). Signed-off-by: Michael Brown <mcb30@ipxe.org>