Add files to boot sector

[chris.brown2]

Hi, I’m attempting to add files to the boot sector for a jetson nano device. I have added a linux-tegra bbappend recipe but the files are not showing up in the /boot dir. My code looks something like this:

do_install_append() {
    install -d ${D}/boot
    install -m 0644 myfile ${D}/boot/myfile
}

FILES_${PN} += "/boot/myfile"

The files just aren’t appearing in the sysroot but are appearing in the image deploy dir. I have attempted other directories also and again there are no files on the actual image. What is the best way to carry out this operation?

[linuxdev]

“/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.

[chris.brown2]

I thought I’d get called out on the word ‘sector’ lol. What I meant was the /boot directory but to be honest it could be any directory in the rootfs. The point is that the file is generated by building the linux-tegra package but doesn’t end up on the rootfs .

Although all this information in the reply is interesting, it doesn’t really tell me how to put a file into the rootfs from the linux-tegra recipe perspective i.e. meta-tegra/recipes-kernel/linux/linux-tegra_4.9.bb.

All the files which are referenced in the conf files (unless I’m overlooking something) are passed as specific parameters to the tegra flash process which (as I understand it) is a mixture of bash scripts and python scripts calling executables inbetween to perform operations such as parsing, signing etc then ultimately flashing the final output to specific areas of the emmc. I can’t see where you can manipulate these conf files nor xml files to put an additional file into a specific area of rootfs.

[linuxdev]

The copy can depend on some permissions of the host PC. I’ll ask first, are there some individual files you might be able to copy just to demonstrate something? This doesn’t have to meet your end goal yet, but I’ll demonstrate something.

On the host PC, go to “rootfs/boot/”. Then as a demo:
touch SAMPLE_deleteme.txt

Then go to perhaps “/home” and also:
touch SAMPLE_deleteme.txt

Then flash. As long as you don’t “reuse” the image, this content should exist on the Nano after flash. Do note though that you would have to use “sudo” in both cases for that “touch” command to work. The same is true in any script.

Next, what is your exact command line for flash? Or are you flashing via the GUI? If command line, what is the exact target you name, e.g., “jetson-nano-emmc”? Can you attach the “.conf” file (e.g., in that example, it would be “jetson-nano-emmc.conf”) to the forum? I’ll see if I can make a suggested edit.

Note that those files can be edited, but it is not something most people would do. Many bash or python files are included via “sourcing” them, which makes their content available, but does not execute the content unless the right function is called. Thus I’m asking about your exact flash method, and I’m hoping you are flashing on command line (but I still need the exact command).

[chris.brown2]

The command to flash is generated by the bbclass associated with tegraflash. This outputs a file called .tegraflash.tar.gz. This file is untarred and then the ‘doflash.sh’ script is executed. The contents of this script are:
MACHINE=mymachine ./tegra210-flash-helper.sh -B 1048576 flash.xml.in mydtb.dtb mymachine.cfg 0xA4000 "" boot.img imagename.ext4 "$@"

These files are generated/handled by the image_types_tegra.bbclass located in meta-tegra/classes.

I’m not sure what manually modifying my rootfs would achieve. I know the rootfs will be flashed but it doesn’t help me in the sense that it has to be done in a recipe and a specific recipe (linux-tegra.bb) because the files are already generated by that recipe but not deployed. The tagret name is jetson-nano-emmc with regard to the conf file.