Carveout Configuration and Limits#

Overview#

This document describes:

  • DRAM memory carveout configuration steps

  • DRAM memory carveout modification steps

  • soft-limit verification coverage for existing carveouts

Verified soft limits on Thor T264: upper 48 GiB, lower 4 KiB. Platform sections below give configuration and verification details.

Linux Carveout Configuration and Limits#

Device Tree file modified:

hardware/nvidia/platform/t264/automotive/automotive-platform-configs/driveos_customer_config/nv_platforms/common/kernel-dts/linux/cust_linux_tegra264.dtsi

Steps to Configure a New Carveout#

  1. Open the Linux guest DTS overlay (reference: cust_linux_tegra264.dtsi).

  2. Locate the reserved-memory block.

  3. Add a new child node with a unique name, a compatible string for the pool type, and a reg property for start address and size. On T264, reserved-memory uses #address-cells = <2> and #size-cells = <2>; each reg has four cells <addr_hi addr_lo size_hi size_lo> (for example 48 GiB at 0x430000000 is reg = <0x4 0x30000000 0xC 0x00000000>;).

  4. For a general-purpose fixed carveout on Tegra/T264, use compatible = "nvidia,generic_carveout".

  5. Add no-map to exclude the region from the kernel linear map and buddy allocator.

  6. Set status = "okay" when the pool should be active.

  7. Confirm that no other object claims the same physical range, including sibling nodes under reserved-memory and linux,cma, if enabled.

  8. Verify that the physical range falls within the Linux guest VM’s assigned partition in the hypervisor configuration, and not within QNX or hypervisor-reserved space.

  9. Rebuild the DTB and flash to hardware.

  10. Verify on the target (replace <node> with the carveout name, for example sample_carveout or generic_carveout):

    • Device tree — status and reg:

      cat /sys/firmware/devicetree/base/reserved-memory/<node>/status
xxd /sys/firmware/devicetree/base/reserved-memory/<node>/reg

    • Memory map — reserved span (requires root on this platform):

      sudo grep <base_address_hex> /proc/iomem

    • Boot reservation — kernel log (for generic_carveout, also confirms nvmap consumer):

      sudo dmesg | grep -i <node>
sudo dmesg | grep -iE 'generic_carveout|generic-0|tegra-carveouts'

Example — generic_carveout (1024 MiB @ 0x430000000, validated on Thor T264 Linux guest):

cat /sys/firmware/devicetree/base/reserved-memory/generic_carveout/status
tr -d '\0' </sys/firmware/devicetree/base/reserved-memory/generic_carveout/compatible; echo
xxd /sys/firmware/devicetree/base/reserved-memory/generic_carveout/reg
sudo grep 430000000 /proc/iomem
sudo dmesg | grep -iE 'generic_carveout|generic-0|tegra-carveouts'

Example: reserved-memory block in cust_linux_tegra264.dtsi:

reserved-memory {
    /* Modified generic_carveout: Changed from dynamic to fixed allocation for testing */
    generic_reserved: generic_carveout {
        compatible = "nvidia,generic_carveout";
        reg = <0x4 0x30000000 0x0 0x40000000>;  /* 0x430000000, 1024 MB */
        no-map;
        status = "okay";
    };
    linux,cma {
        status = "disabled";
    };
    /* NEW: Custom sample carveout for REQ-2 accessibility testing */
    /* Fixed address matching QNX approach: 0x420000000-0x42fffffff (256 MB) */
    custom_sample_carveout: sample_carveout {
        compatible = "nvidia,generic_carveout";
        reg = <0x4 0x20000000 0x0 0x10000000>;  /* 0x420000000, 256 MB */
        no-map;
        status = "okay";
    };
};

What this example shows:

  • sample_carveout is the new carveout, 256 MiB at 0x420000000, with no-map and status = "okay".

  • linux,cma is disabled so CMA does not claim the same RAM as fixed pools.

  • generic_carveout was converted from dynamic sizing to fixed reg (1024 MiB at 0x430000000).

  • Dynamic-address carveouts are not suitable for deterministic read/size validation; carveouts that need access, read, or resize checks should be fixed using reg.

Steps to Modify an Existing Carveout#

  1. Open the same overlay and locate the target node (for example, generic_carveout or sample_carveout).

  2. Update reg (and comments) with the new start and size.

  3. Keep compatible unchanged unless the pool type changes.

  4. Re-check overlap with other reserved-memory nodes and with linux,cma if CMA is re-enabled.

Example: what “modify” means in this file:

  • generic_carveout: dynamic sizing in the base DTS was replaced with fixed reg (1024 MiB at 0x430000000), still nvidia,generic_carveout, with no-map.

  • sample_carveout: a later change mainly adjusts the numeric cells in reg (and the comment), not the node label, unless downstream software expects a rename.

Soft Limits for Linux#

Soft-limit carveout testing was not run on Linux for the GPU region (gpu-carveout) because it is not a fixed reserved-memory node. On Thor, the GPU carveout is supplied via hugetlbfs huge pages (2 MiB physically contiguous each), so the same address/size stress layouts and /dev/mem-style carveout checks do not apply. For GPU carveout sizing on Linux, see GPU Carveout.rst in the same documentation set.

Verified on Thor T264 Linux guest hardware for generic_carveout at 0x430000000: shipped 1024 MiB; upper soft limit 48 GiB (reg = <0x4 0x30000000 0xC 0x00000000>;); lower soft limit 4 KiB (reg = <0x4 0x30000000 0x0 0x1000>;)