Hello Guys,
We are confused on the flash process.
When flashing(connect orin with host pc) ,we use this command:
sudo bash flash.sh jetson-agx-orin-devkit mmcblk0p1
Scripts in the flash.sh is so long that we do not know which works on the host pc or on the orin.
We wonder if there are scripts that for one thing we can split all the image and zip them into one file, for the other thing, we could flash the zip file into orin.
This will work better if we can keep all the flashed file together as one version.
Thank you very much if you could help me with issue.
Hi @yazhuan.zhang and welcoeme to the NVIDIA developer forums.
I think this question might better be asked in the AGX Orin specific forum category. I took the liberty of moving this post over there.
Thanks!
Hi,
I am not sure what you are talking about.
For example, what do you mean “works on Orin”? What do you mean work?
Are you talking about flash process, or you are talking about a file that will be existed on Orin after boot?
Are you speaking of the partitions? If so, think of partitions other than rootfs as boot content plus a software equivalent of a BIOS. There might also be some setup in some QSPI memory. If you are wanting to simply perform a binary write of all content from a single image, then that isn’t practical since Jetsons in recovery mode are not just a mass storage device.
Hi，we are now using “sudo bash flash.sh jetson-agx-orin-devkit mmcblk0p1” to flash the orin device.
It takes us nearly half an hour.
We found there are steps to build image.
So we want to know
1.how many images will be flashed into orin?
2. is it possible that we can split the build image part process and the flash process?
How to do it?
Incidentally, the image flashed is always the “Linux_for_Tegra/bootloader/system.img” file. This is what the image generation step creates (sort of).
When I say “sort of”, I mean that a full image (raw) is first generated. This is moved to file name “bootloader/system.img.raw”. Then the “mksparse” utility creates a “sparse” image with NULL byte filler for the “empty” part of the filesystem. The sparse file is what “system.img” is when generation is complete. The space consumed by files in the filesystem is the size of the sparse image, while the full partition size is the size of the raw image. As the filesystem space fills up, the sparse file approaches the size of the raw file.
Either sparse or raw file can be flashed, and the result is the same other than time due to USB transfer speed limitations of two different size files. Raw files can be loopback mounted, edited, examined, so on, but sparse files need tools to deal with them for any purpose other than flashing. A clone will give you both.
The command line option “-r” says to “reuse the existing image” and to not generate a new image. If you’ve flashed just once without “-r”, then you already have “bootloader/system.img” and don’t need to generate it again. If and only if you want that image on every Jetson, then you will save time by using the “-r” option when flashing the same image. Example:
sudo ./flash.sh -r jetson-agx-orin-devkit mmcblk0p1
You could even replace system.img with a clone from a Jetson with a fully updated system. Imagine first installing the Jetson and it has all of the apt-get upgrade completed already up to that date? You would have to be careful to remove the login user name/pass before putting it into a production line, but it would save a lot of time updating (or even adding custom packages). You can do this with the raw image, and then use mksparse with the ‘0’ byte as the fill character. Then you’d have an updated backup image fully up to date, with optional packages, and in both sparse and raw formats for reuse.
One thing to consider regarding production units is that California added laws against default name/pass. This is why Jetsons switched to a “first boot account setup” scheme. Then the customer is adding this. However, if you were using a clone, you would essentially want to reverse or neutralize the first boot setup so the end user could do this.
Also, there is a directory, “/etc/skel”. That directory is a “skeleton” of new accounts when new accounts are not specified with details. It is a default user setup. You could modify that with any end user customization, e.g., if you want the PATH in the environment to be customized, then you could edit the “/etc/skel/.bashrc” for that. Or you could add symbolic links to a full path to some program directory you’ve added. You could even add some README file in “/etc/skel/Documents/README”.
Hi ,thank you!
So the important point are those:
1.We can use -r to reduce flashing time after first flash.
2.We can modify “/etc/skel ” to aviod first boot account setup scheme .
Am I right?
Point 1 is correct. Point 2 is not correct.
You still have first boot account setup if you modify /etc/skel. The point here though is that if you customize /etc/skel, then when new accounts are created, they will also be modified per your /etc/skel modifications. As an example, if you have some custom software with a custom path, and if you don’t adjust /etc/skel, then it implies after creating the account you would need to configure for your custom software to find it; if /etc/skel already has that customization, then the created new account would already have that set up without any additional steps. /etc/skel is the frame around which new login accounts are designed when the /home content is added.
Is there anyway to aviod first boot account setup scheme ?
If on the host PC, in the “Linux_for_Tegra/” directory, you run this you can avoid first boot setup:
sudo ./tools/l4t_create_default_user.sh
This puts the account into the content which gets flashed. You can do this once and from then on flash will be set up with that user already on the system. Just don’t do that if you are shipping to California.
Hi,
Got it.
we tried.
so we can set username and password.
How about hostname?Is it neccessary？
Hostname is just a file in “/etc”. This can also be a result of DHCP ethernet setup. On your host PC (which has all of the man pages installed; Jetsons usually don’t have man pages installed by default) check this out:
man -S 5 hostname
To see everything related to hostname, you can go through all man pages on the topic; when you type q to exit the man pages it will cycle to the next section:
man -a hostname
Hostname is not necessary. There is a sethostname system call that other software (usually networking) might use to set something if it is needed. Check out:
cat /etc/hostname
hostname
(both commands should lead to the same answer)
You’d have to be more specific and detailed to know how to answer regarding hostname. A detailed scenario might be of use.
Ok ,git it. Thank you very much for you kind help!
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.