Clarification on proper method to extend /proc/cmdline on NVIDIA Thor (Ubuntu BSP)

Autonomous Vehicles DRIVE AGX Thor DRIVE AGX Thor General
1

DRIVE OS Version: 7.0.3

Issue Description:
Hello NVIDIA team,

I’m working with an Ubuntu-based NVIDIA Thor platform and would like clarification on the intended and supported way to extend the kernel command line (/proc/cmdline) on this BSP.

Current observations

On the running system, /proc/cmdline is populated exclusively from the boot chain and contains entries like:

aurixfw=AFW root=/dev/vblkdev0 usr_fs=... rw_overlay=... nvlog=...

There is no initrd= or ramdisk= parameter, and /boot inside the root filesystem is empty. This suggests that the kernel boots with an embedded initramfs, not one loaded from the filesystem.

Kernel configuration experiments

I tested the following kernel configurations:

CONFIG_CMDLINE="bootconfig"
CONFIG_CMDLINE_FROM_BOOTLOADER=y
CONFIG_CMDLINE_FORCE=n

With this setup:

  • /proc/cmdline does not include bootconfig
  • CONFIG_CMDLINE appears to be ignored when CONFIG_CMDLINE_FROM_BOOTLOADER=y

This behavior is consistent with upstream Linux semantics, but it raises a question about the supported way to add kernel parameters on Thor.

Use case

My goal is to add a minimal kernel parameter (specifically bootconfig) in order to enable kernel bootconfig parsing, without breaking or overriding the vendor-provided boot arguments.

Clarification requested

Could you please clarify the recommended / supported approach on NVIDIA Thor to extend kernel boot arguments?

Specifically:

  1. Is the expected method to:
  • modify bootloader / DT bootargs, or
  • rebuild the kernel with CONFIG_CMDLINE_FROM_BOOTLOADER=n, or
  • enable CONFIG_BOOT_CONFIG_FORCE=y, or
  • modify an embedded boot image / ramdisk artifact (e.g. target image)?
  1. Is CONFIG_CMDLINE_FROM_BOOTLOADER=y intentionally enforcing a strict bootloader-only cmdline policy on Thor?
  2. If the bootloader cmdline is considered authoritative, is there a supported mechanism to append kernel arguments without overriding existing vendor parameters?

Understanding the intended design here would help ensure changes remain aligned with the BSP’s supported boot flow and do not conflict with safety-critical or platform-specific boot requirements.

Thank you in advance for the clarification.

Best regards,
Mykhailo

Related topic: How to enable / mount cgroup v1 (legacy or hybrid) on NVIDIA DRIVE AGX Thor

6

Dear @mykhailo.i.kozak ,
Let me check internally and get back to you.

7

@SivaRamaKrishnaNV Any updates or clarifications so far?

8

Dear @mykhailo.i.kozak ,
Does Passing Additional Kernel Parameters | NVIDIA Docs helps your use case?

9

@SivaRamaKrishnaNV Resolved, thanks