You might want to look at the “taskset” command for affinity.
Jetson is not a “standard” microcontroller, it is actually a very advanced full computer that happens to be physically small and low power use. Understand that bare metal coding applies to a boot loader, and cross compile tool chains generally indirectly name this as what they are designed for; cross compile tool chains which have a kernel to run them are usually specifically named with something like “linux-arm-gnueabihf…”. Linux for running under linux, arm for the cpu type, gnueabi for linux calling conventions version “e”, “hf” for hard float calling convention. The boot loader will run from a bare metal version, the kernel can run from either bare metal or not (but almost always runs the gnueabihf), and everything which runs under the operating system must run gnueabihf, not bare metal.
Making code run on a single core (core affinity) is unrelated to the flash process. Whatever is in your sample rootfs at the time of flash gets put onto the root file system of Jetson. If you have a program built as a kernel driver to use a single core, and put that driver into the kernel that is flashed, you get what you want; or if your sample rootfs contains the right taskset command during init, you also get what you want.
Boot loader is just the software which Jetson hardware hands off to after hardware is capable of giving control to something else. Nothing runs in the boot loader unless it is manually set up, e.g., you can’t even use the eMMC memory or RAM without something setting it up in some minimal way; the boot loader does this. When the environment is capable of being accessed then the boot loader begins kernel load, which is where all the nice “automated” abilities begin (e.g., in “C” language a local variable is automatically allocated, but even when “C” is used in a boot loader, allocation of the same local variable would need manual allocation).
Perhaps a more functional description for the boot loader is made by comparing desktop motherboards to embedded systems. Desktop systems generally have a BIOS (or something more modern) which has an ability to detect various hardware and provide a uniform interface to report that information to the kernel and boot loader. Since there are a large number of removable slots in a desktop, this is rather important. This also takes up a lot of physical space on the motherboard, along with memory. When you compare to an embedded system there is no BIOS (or equivalent) for embedded. In order for the embedded system to hand off to the kernel the boot loader itself must be hard coded to know about the hardware onboard and report it to the kernel (but since there are very few removable slots on embedded this doesn’t matter). Boot loader plus BIOS or hard coded information hands off to kernel and then boot loader goes away. The kernel understands both bare metal and gnueabihf and is the adapter between bare metal and an operating system.