Using my Jetson Nano for Preparing a Jetson Developer Kit for Use

Autonomous Machines Jetson & Embedded Systems Jetson Nano
1

I followed the instructions found here:

Preparing a Jetson Developer Kit for Use
https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%2520Linux%2520Driver%2520Package%2520Development%2520Guide%2Fquick_start.html%23wwpID0E0ND0HA

I got to, “2. Enter the following commands to untar the files and assemble the rootfs:” and successfully ran, “sudo ./apply_binaries.sh”

Now here’s my problem. I ran all this on my Jetson Nano and now want to create the SD Card image so I can flash the SD Card.

What I mean is, I have no X86 Ubuntu system to use to flash the Jetson Nano, so I would like to use a USB SD Card reader and dd to write whatever needs to be on the SD card to boot up the Jetson Nano with whatever apply_binaries.sh created.

Is this possible?

2

Hi oseberg,

If you doesn’t have x86 Ubuntu system, you can download SD Card image directly. Then using “Etcher” tool to flash image on SDCard.
Please follow Getting Start Jetson Nano Devkit steps.

3

Yes. I’ve already done that. That’s how I got my Jetson Nano up and running so that I could use it to follow the instructions for Preparing a Jetson Developer Kit for Use. I’d now like to create my own image for the SDCard. I was hoping I could do this on the Jetson Nano itself rather than on a separate computer.

4

Hi oseberg,

We are not support this.
If you’re create image on Jetson-Nano, how to put device into RCM and flash image?
Please using host machine (Ubuntu 16.04/18.04) or Etcher tools.

5

Have you heard of a USB SDCard reader? You can also write to those to flash an SDCard.

All I need to do is generate the image and write it to the SDCard.

This isn’t complicated. I just need to know how to create the SDCard image. Why wouldn’t I be able to create the image on my Jetson Nano? It’s an Ubuntu computer right? I ran “sudo ./apply_binaries.sh” and it looks like it ran without problems. It even says, “Success!” at the end.

6

Hi oseberg,

We are not try this before. You can try it.

We have the “jetson-disk-image-creator.sh” script on “JetPack_4.3_Linux_P3448/Linux_for_Tegra/tools” folder. You can use this script to create SD card image.

7

Thank you.

I found the instructions for Jetson-disk-image-createor.sh here:
https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%2520Linux%2520Driver%2520Package%2520Development%2520Guide%2Fflashing.html%23wwpID0E0PG0HA

The commands I used are:

followed by:

When I tried, “-s 4G” I got, “No space left on device” errors. How am I supposed to know how big the blob needs to be? It seems silly to make it too big, and it obviously won’t work if it’s too small. It would be most efficient to make it exactly the right size, however I don’t have a clue how to know what that exact right size is.

8

Hi oseberg,

The “sd_blob_size” is base on rootfs size.
Please make sure your Jetson-Nano sdcard size is enough.

9

My SDCard is 128GB. This is NOT the problem that caused the, “No space left on device” errors. These errors occurred while jetson-disk-image-creator.sh was creating the SDCard image file. jetson-disk-image-creator.sh was obviously not able to fit everything into a 4GB image. 6GB succeeded because jetson-disk-image-creator.sh was able to fit everything into a 6GB image.

So my question was regarding how to figure out how big the image needs to be in order to fit whatever jetson-disk-image-creator.sh wants to include.

10

Hi oseberg,

The 4GB mentioned in the script is just fro the example, create the sd card image of the size according to how much data you add into the rootfs.
Suggest you need to create > 4GB of SD card image on Nano. safer is 6GB or 8GB.

11

Right. That’s what I ended up doing. First I tried 4G as the instructions suggest. Then, when that failed, I tried 15G. After that I tried 10G, 7G, and 6G. All but 4G worked. I deleted the 15G, 10G, and 7G images because they’re just a waste of space. Then I wondered, why should I have to figure out the minimum size by trial and error? In fact, why should I even specify the size at all? Shouldn’t the script figure out the minimum size and make the image as small as possible on it’s own?

12

While I wouldn’t use it in production (very few tests). I wrote a wrapper for the script that does this. “du” can be used to measure the size of a directory and it’s contents. Then my script adds a gig for the kernel, other partitions, etc, rounds up to the next power of two, and passes it to the Jetson disk image creator.

tegrity-image is the script that does this.

I agree it would be nice if it wasn’t necessary. If you’re wondering, on first boot the size of the root partition extends to fit any cars like on a Pi. As of JetPack 4.3, the resize is configurable as the last step in first boot config.

13

Cool, Thanks!

Maybe I’ll find the kernel file and use du on that too so that the size can be exact. Is there any reason to limit the size to a power of two? Why not just an even multiple of block size? The smaller the better, since it’ll waste less space.

14

Disk partitions are definitely ok with a multiple of block sizes, but some of the related disk creation software may have another limit on top of this. When the flash.sh tool itself is used it will create partitions based on either “MiB” or “GiB”, where MiB is any positive integer multiple of 1024x1024. If it is GiB, then it is a multiple of 1024x1024x1024. So I will guess that if you have a multiple of block size, and that multiple is also evenly divisible into 1024x1024 or 1024x1024x1024, then it would always work. If not an even multiple, then you may want to round up to the nearest block evenly divisible into 1024x1024.

15

IIRC, The exact sizes of all the partitions are in xml files somewhere in …/Linux_for_Tegra/bootloader/t210ref/cfg , if you want to submit a PR to parse all that, ad it to the du result, and test it, it’d be welcome. Just adding a gig and rounding up is kind of hacky and could possibly break, but in testing it always worked and was a quicker solution, so I’ve kept it.

Re: linuxdev, you can pass --si to du to get units in silly storage manufactur multiples of 1000. Multiples of 1024 will unfortunately not flash to a card evenly. This is the cause of countless bugs, confusion, and even lawsuits. Disk sizes are measured in base 10, because marketing.

For example, 2G is 2,147,483,648 in base 2, and a 2GB sd card is ~2,000,000,000. If you create a card image in G and try to flash it to a card, it won’t work. dd has similar options (from dd manual):

...N and BYTES may be followed by the following multiplicative suffixes: c =1, w =2, b =512, kB =1000,  K  =1024, MB =1000*1000, M =1024*1024, xM =M, GB =1000*1000*1000, G =1024*1024*1024, and so on for T, P, E, Z, Y ...

Yeah, I know. Ugh.

16

My original reason for mentioning 1024 is from the actual flash.sh script since this is where all sizes in the “-S ” parameter are either MiB (1024x1024) or GiB (1024x1024x1024). Leave it up to the “silly storage manufacturer multiples of 1000” to mess it up :P

“dd” really should copy exactly what it says it will, but the actual hardware is the final authority regardless the laws of physics as known to mankind, so it looks like I lose the argument for the image to be written needing multiples of 1024. I wasn’t actually referring to the size of the SD card so much as I was referring to the size of the partition as understood by flash.sh. I guess I should specify size in metric vs American vs manufacturer vs binary (“dd”).

On the other hand, at least it is easy to test on an SD card.

17

Confusingly, the --si units, aka, the International System of Units, aka metric, is the one the storage manufacturers choose, since it’s base and deviation increases the bigger your disk is, even though it makes no sense whatsoever for binary.

I know, it’s nuts, right. I mean have you ever heard somebody mention a kibibyte outside that article? It’s like these people live in a parallel universe.

RE: image size, I guess it can be of any size so long as it fits on the card. I just rounded with my script so that it wipes any free space when written, is clear what size card the image requires, and makes the image modification later easier (I haven’t tried loopback mounting the rootfs image partition to test, but that was the idea). When compressed it shrinks to about the same size anyway.

Re: flash.sh parameter. I am not sure about flash.sh but some Nvidia scripts pass the size parameter directly to dd, so the prefixes from the dd manual work.