In "/boot/extlinux/extlinux.conf " you’ll notice that the “APPEND” key/value pair has in it:
APPEND ${cbootargs} root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4
Only the “root=” and to the right are actually configured from extlinux.conf. “${cbootargs}” is inherited from U-Boot. U-Boot gets this from the device tree.
If you use a serial console and start boot, but hit a key when it reaches this, it’ll stop and drop into a U-Boot shell:
[0003.736] I> <b>tegrabl_load_kernel_and_dtb: Done</b>
U-Boot 2016.07-g9c3b9a4 (Mar 01 2018 - 20:41:10 -0800)
TEGRA186
Model: NVIDIA P2771-0000-500
DRAM: 7.8 GiB
MC: Tegra SD/MMC: 0, Tegra SD/MMC: 1
*** Warning - bad CRC, using default environment
In: serial
Out: serial
Err: serial
Net: eth0: ethernet@2490000
<b>Hit any key to stop autoboot:</b> 0
Within this shell you can run command “help” for general help, or “printenv” to see environment variables. To specifically see the content of “cbootargs” you can run either of these:
printenv cbootargs
echo <b>$</b>cbootargs
You can set a new value for a variable with the “setenv” command (“help setenv”). Note that if you do this, then the change will be for only one boot, and will be lost after that…the cbootargs variable will revert to its old value. To save permenently you would do the same edit, and then “saveenv”. It’s good to test before saving. Be sure to write down the original value in case you need to restore it later. However, I don’t know for sure if the method of merging cbootargs from the device tree would still override your change even after a saveenv (if the variable were not created through inheritance, then I’m sure it would be saved…you might have to test to see if the inheritance mechanism of cbootargs overwrites saveenv changes).
The second way to change this is by changing the device tree. Details on actually saving a new device tree through the flash.sh tool differs depending on release, but you get an exact match of your running system no matter which release you use (and this can be both saved as a reference and a copy edited before using the correct device tree install for that particular release). To get a device tree from a running system:
dtc -I fs -O dts -o extracted.dts /proc/device-tree
# Save a reference copy somewhere, then edit for cbootargs within extracted.dts, then convert extracted.dts back to dtb binary:
dtc -I dts -O dtb new_binary_tree.dtb extracted.dts
Flashing this new_binary_tree.dtb should do the job.
As to actual edits, search with the dts for "bootargs = ". Note that serial console is via the “console=ttyS0,115200n8”, and regular console is via “console=tty0”. If you disable the serial console side you’ll lose the ability to interact with the bootloader until you flash a new device tree…just remove the “console=tty0” part.
Also note that cbootargs is not necessarily an exact match too device tree “bootargs”. The cboot stage occurs prior to U-Boot and may merge some details in to the bootargs of the device tree before passing it on to U-Boot…and then it becomes “cbootargs” (for U-Boot) instead of “bootargs” (device tree).
Trivia: The details of merging early device tree with edits is why the FDT key/value pair in extlinux.conf is no longer used…and why only some of the parameters of the kernell command line can be overridden with the APPEND key/value pair of extlinux.conf. The parameters shown can be overridden, but things may not go as expected when overriding some of the other values due to interaction at the cboot stage with the device tree version. Maybe one of these days we’ll get back to being able to use the FDT entry again…don’t know.