“/boot
” isn’t what “boot sector” actually means; boot sector is from older style BIOS partition schemes. Can I confirm that what you want to do is to add files to “/boot
” in the flash software of the host PC you are flashing from, such that it appears in the flashed product?
Also, which model of Nano are you working with? The dev kit does not have any eMMC memory, and the SD card is mounted directly to the module; any eMMC model uses a third party carrier board, and the SD card is on the carrier board, not the module. To some degree, the answer depends on what model you are using.
For what follows, this is just a sort of “general” statement, and is not entirely correct when SD card models are concerned. For an eMMC model, this is correct, but there are other modifications being left out which are needed for a third party carrier board. The basic idea is still correct.
From the perspective of the host PC, the content of the directory “Linux_for_Tegra/rootfs/
” is mostly a verbatim copy of what goes into the flashed image. There are some files in “rootfs/boot/
” though which are modified.
JetPack/SDK Manager is just a GUI front end to the actual flash software, but if you were to flash on command line, an eMMC model might flash something like this:
sudo ./flash.sh jetson-nano-emmc mmcblk0p1
To create a log from that flash, you could append:
2>&1 | tee log_flash.txt
Which would become:
sudo ./flash.sh jetson-nano-emmc mmcblk0p1 2>&1 | tee log_flash.txt
Regardless of model, I suggest you create a log of a command line flash (and keep that log for reference), although the target of the flash might differ.
The detail of interest is that the target arguments to flash.sh
adjust what is done. The jetson-nano-emmc
specifies some boot content, and there is reference content in other subdirectories of “Linux_for_Tegra/
” which gets copied to a “staging” location, and then from the staging location to “Linux_for_Tegra/rootfs/boot/
”.
If you are generating a new image, and if that edited content is not part of what is copied from a reference location, then simply editing “rootfs/
” is sufficient (I do this with home directory content and ssh
keys and some “rootfs/etc/
” configuration). This is essentially what the “sudo ./apply_binaries.sh
” script does, and also what “sudo tools/l4t_create_default_user.sh
” does.
If you are generating a new image, but that content is part of what the target specification copies from a reference, then you need to have your edit placed in a reference location; then the copy (due to that flash parameter) will take place from the flash itself prior to generating the image.
Something you may be interested in, which might make your particular code less important, is knowing what the “jetson-nano-emmc
” target is in this example:
sudo ./flash.sh jetson-nano-emmc mmcblk0p1
Each target corresponds to a “.conf
” file. So if the target is jetson-nano-emmc
, then this file is referenced:
jetson-nano-emmc.conf
In the Linux_for_Tegra/
directory, run this command:
ls -l *.conf
Note that there are a lot of .conf
files. Many are symbolic links to more obscure names. The actual specification of what to copy and where to put it is a combination of:
- The module itself.
- The carrier board.
For example:
jetson-nano-emmc.conf -> p3449-0000+p3448-0002.conf
Half of that more obscure file name is the designation for the module; the other half is the designation for the carrier board model. jetson-nano-emmc
is just an easy alias to remember so you don’t need to remember the “p-something
” designation of module and carrier board.
Notice that in the .conf
you will find one or more “source
” statements. Those statements include content from another file. There will also normally exist an XML file to include the name of. This builds up combinations of carrier board specification and module specification.
When a third party creates their own software, then typically they will copy the closest “.conf
” file, and then edit that to point at their own module and carrier board files (and the module spec might be the same). In your case you will probably do the same, but perhaps you want the defaults other than your file copy. The .conf
is a bash
script, and so you could put the command into an alternate .conf
file. Notice that the XML file is normally under the “Linux_for_Tegra/bootloader/
” content, and contains partitioning information.
If you log the flash on command line, then you know where files are being taken from in order to get to “rootfs/boot/
”. If you then copy and edit the .conf
file for your target, then you know where to place “/boot
” content for it to reach the default image.