changed cbootargs, did a saveenv, rebooted and cbootargs reverted, my changes were lost
cbootargs is not a variable you can set and save. As the name implies, the value of that variable is passed from Cboot, the bootloader that precedes U-Boot.
Your answer is worthless.
You assume the customer knows about cboot and can find any documentation on cboot.
Customers might be have a lot of linux experience, and are trying to find the bread crumbs of nvidia information on boot sequence.
I have yet to find a Theory of Operation Document that talks about the boot process for nvidia
Then cbootargs should not be part of printenv in the u-boot.
You can’t put env variables in u-boot that u-boot does not control. So how do I get to the cboot environment and make changes?
So answer the question on how to change cbootargs!
On a regular PC there is a BIOS which sets up clocks and power rails and such. This then adds a couple of drivers, and presents a uniform interface to the bootloader which boots the operating system. Because no embedded system has this, it becomes necessary to do all of that work in software, which in turn is more or less “early boot stages”. Docs are available on those boot stages, though most people won’t read this.
C-Boot preceeds U-Boot, and it is U-Boot which is first boot stage from publicly sourced software. U-Boot inherits part of its boot environment from those previous boot stages, and other parts are created within U-Boot itself. Since the C-Boot arguments are set up by C-Boot there is no chance for U-Boot to simply override this.
One could create U-Boot macros to copy C-Boot args, and then live edit, or perhaps one would edit C-Boot itself. In some cases the device tree itself is read by C-Boot, and thus C-Boot might have inherited something as well. The nice part there is that the device tree is easily edited without editing either C-Boot or U-Boot. For your specific content this is the case, and you can install a new device tree without editing C-Boot or U-Boot.
I imagine you will have a bit of a learning curve for device trees, but this isn’t actually too difficult. The main problem is that installing and editing will have details you’ll have to read the official docs on. See this (you will need to go there, log in, and then go there again since redirect does not work):
https://developer.nvidia.com/embedded/downloads#?tx=$product,jetson_tx2
(then look for “L4T Documentation” for your release)
This is a shorter device tree explanation, but be careful to use the information for your specific release (installing a device tree has different instructions for different releases…the latest release listed applies to R32.3.1):
https://elinux.org/Jetson/TX2_DTB
The gist is that a device tree is a way to pass arguments to drivers such that the arguments do not need to be hard coded into the driver itself. Within the device tree is a node called “chosen”, and within this is a node called “bootargs”. It is through editing device tree node “bootargs” that you will get edits to “cbootargs”. This is the beginning of the chain of everything inheriting this throughout boot.
The package with command “dtc” is “device-tree-compiler”, and this can be added via:
sudo apt-get install device-tree-compiler
If you want to see your final device tree once boot is complete, then this will show you the source code version:
dtc -I fs -O dts -o extracted_tree.dts /proc/device-tree
(you can then examine “extracted_tree.dts” with an editor, search for “chosen”, and then within that “bootargs”)
Note that the files in “/proc/device-tree” can be read, and that this is actually the kernel RAM and not real files…this content exactly reflects the final tree which the kernel read. For example:
cat /proc/device-tree/chosen/bootargs
If you make an edit to this via installing a new device tree, then upon boot you will see that reflected in the above “cat” command.
Most of the work will be in finding which device tree file to put in place in the host PC’s software, and then using the eLinux.org flash instructions to flash just the device tree.
linuxdev
Thanks,
“Docs are available on those boot stages, though most people won’t read this.”
This is another worthless statement, alway give links/titles or the best way to get to the document, so if others find this info, they will get the pointer to a good document. I would like to look at the document and stash it away if need in the future.
The link was given, but it didn’t highlight due to limitations in the forum software:
https://developer.nvidia.com/embedded/downloads#?tx=$product,jetson_tx2
Or, just https://developer.nvidia.com/embedded/downloads, then check TX2, and look for (literally) “Documentation” (the longer URL is just the change from checking “tx2”).
linuxdev,
“I imagine you will have a bit of a learning curve for device trees, but this isn’t actually too difficult. The main problem is that installing and editing will have details you’ll have to read the official docs on. See this (you will need to go there, log in, and then go there again since redirect does not work):
https://developer.nvidia.com/embedded/downloads#?tx=$product,jetson_tx2
(then look for “L4T Documentation” for your release)”
Another worthless piece of information, kind of like a cat and a laser pointer, you should tell customers the exact section in the documentation to use. Or you need to write a tested cookbook receipt on exactly how to get the task done, with notes about differences for the most recent release and notes if there are differences for device( nano, tx2, etc).
I have found that the document is not alway correct. Looking forward to step by step how to accomplish the task.
Thanks,
Terry
Sorry, there is a lot of background needed to work on bare metal booting…thus there is no such thing as a simple recipe or answer. saveenv does work, but only on variables in the environment. You’re trying to edit an argument passed on command line from one stage to the next. Editing the device tree is the way to change this, and no direct interaction with any of the boot stages is actually used to make this change. Thus, back to device tree. If you run into questions on the device tree you can always ask, but it is hard to cover a topic that broad since it is an entire book.
hello terrysu50z,
according to the Jetson TX2 Boot Flow, C-Boot runs before U-Boot.
also, u-boot env has nothing to do with cbootargs.
thanks