Embedded systems do not have a BIOS/UEFI, which GRUB depends on, and so there is no GRUB. U-Boot updates could conceivably do this (the embedded equivalent to GRUB), but if U-Boot were updated, then I suspect boot would fail entirely. grub.conf either won’t exist, or will be completely ignored.
You are correct, the location of the equivalent file on a Jetson would be “/boot/extlinux/extlinux.conf”. The “APPEND” key/value pair appends to the kernel command line, but the device tree may provide part of this in earlier boot stages, followed by those boot stages performing slight edits and passing on to the next boot stage. If you look at the APPEND content “${cbootargs}”, this is how the inherited content is used to start the kernel arguments via macro expansion from the inherited previous boot stage environment.
If you look at the device tree “chosen->bootargs” node:
cd /proc/device-tree
cd chosen
cat bootargs
…then you will find the device tree content which was used to form “${cbootargs}”. The exact output of “cat /proc/cmdline” may not be an exact match for this because earlier boot stages can edit the content before passing on to the next boot stage. For example, cboot occurs prior to U-Boot, and will pass the information on to U-Boot, but may alter the content prior to doing so. To change this earlier content you would need to alter the device tree’s “chosen->bootargs” node.
A comment on this: When one boot stage hands off to another some of the result is simply from inheriting hardware in a particular stage. An example might be that a power rail is already up, clocks are running at some default speed, so on. Some of the content of the early boot stage editing may not matter to later boot stages, other than from having the hardware function (and thus not need to pass all of that information to the next boot stage, or to pass it modified). Overall though, I suspect the code which is adding the undesired isolcpus is either from the device tree, or from early boot stage edits. U-Boot itself is probably not involved other than by inheritance.
You can use serial console and interrupt U-Boot to get to its command line. Then you can examine the macros/variables which are being used, and observe if the isolcpus is part of that environment or not. If you hit a key during boot at the correct time (which is not long), then you drop into the boot environment console. Running command “boot” continues boot normally. Command “help” provides what you can do. Command “printenv” shows environment variables. You can also use “${}” syntax with “echo” and see what a variable is, e.g., “echo $foobar” would show you what is in variable “foobar”. Each of these can be altered.
Should you alter a variable in U-Boot, and then “boot”, the changes will only be for that boot. To save those changes across boots you would need to “saveenv”. You could hunt for where isolcpus is coming in to play.
