How to reach Jetson after flashing memory

Autonomous Machines Jetson & Embedded Systems Jetson TK1
21

The “-S 14580MiB” (case sensitive) size is a known working size and I would have to wonder if there is some sort of simple typographic error causing rejection. 14580MiB is compliant with a 512-byte block size. However, the fact that this shows as an ext4 issue while creating the image on the host makes this much more interesting. The location in the flash.sh script where this is calculated is here:

# flash.sh R24.2:
 485         local bcnt=$(( $3 / 512 ));
 486         local bcntdiv=$(( $3 % 512 ));
 487         if [ $bcnt -eq 0 -o $bcntdiv -ne 0 ]; then
 488                 echo "Error: $4 file system size has to be 512 bytes allign.";
 489                 exit 1;
 490         fi

That size is a very simple calculation and does not even require query of the JTX1. I am very curious, on your host on the command line, what is the output of:

echo $LANG

I’m thinking the script is somewhat bulletproof for this calculation, and that if it isn’t a typographic error, then the command line is being parsed wrong. Command line parsing is very straightforward, but character sets could get in the way. If that is the case then there might be quite a few locations where something strange could be going on for just that reason.

This line is harmless and expected:

Warning: missing eksfile...

This part is hard evidence that something in the flash script itself is failing (it isn’t the JTX1 failing, it’s the flash software):

File "/home/joel/nvidia/Linux_for_Tegra/elf-get-entry.py", line 73
print '0x%x' % ep
^
SyntaxError: Missing parentheses in call to 'print'
Could not determine entry point of bootloader binary

When I flash with this same L4T version I do not have this error. I use Fedora, so the CentOS should probably work too. In addition to the “echo $LANG” question, is there anything special at all about the host where the elf-get-entry.py error showed up?

If the host does not have something odd going on, such as because of LANG or use of a VM, then I would have to suspect that the driver package and sample rootfs downloads themselves are corrupt. Many people have used this particular version of flash.sh (including myself) and never had that particular error…which occurs prior to ever touching the Jetson.

Probably the next step is to completely delete everything in the driver and sample rootfs downloads and re-install them on your host just to be certain there is nothing getting in the way due to corruption. Be careful to use only a web browser for the download, don’t use utilities like wget.

22

Before I do this
(and yes, I had used a web browser for the download)

I chose 64 bit for the package.
Both Linux machines are x86_64.
-rw-r–r–. 1 root root 163379161 Nov 12 08:13 Tegra210_Linux_R24.2.0_aarch64.tbz2

and this is the file I used.

Just wanting to be sure it is the same as yours.

Thanks-

Joel

23

That file would be correct for a JTX1. Aarch64 identifies the CPU, t210 identifies the SoC, and R24.2.0 is the most recent sample rootfs for directly downloading. I am not where I can check the byte size at the moment, but I would freshly download both the driver package and the rootfs just to be certain. If you downloaded it twice and ran “sha1sum” on each and they match, then you have a consistent download. There may even be a sha1sum list somewhere.

Linux 64-bit is the correct driver package. This is of course separate from the rootfs, and this is also the part which was behaving oddly. So far there is no reason to question the rootfs, but the driver package had the parsing errors and python errors. It would still be of interest to know the output of “echo $LANG”. There is a chance of a bug in the driver package for alternate LANG.

24

Thanks as always.
I will do this later today - but - I only had one download, that Tegra file.
You mention there are two?
I used the file in both steps - I’m getting the sense I didn’t do it right.

I’ll look later today for 2 downloads instead of one…

25

You also need Tegra_Linux_Sample-Root-Filesystem_R24.2.0_aarch64.tbz2. Both files (TX1) are from:
https://developer.nvidia.com/embedded/linux-tegra

The one you have with flash.sh is the “Jetson TX1 64-bit Driver Package”. The other is “64-bit Sample Root Filesystem”. Driver package does not need to be unpacked sudo, but within the “rootfs” directory sample rootfs needs to be unpacked sudo. In the same directory with flash.sh is the apply_binaries.sh script which needs to run sudo as soon as sample rootfs has been unpacked. After that you can flash however you want, e.g.:

sudo ./flash.sh -S 14580MiB jetson-tx1 mmcblk0p1
26

Linuxdev, I cannot tell you how helpful you are.
You were patient and detailed.

Let me explain what happened. I had not known there were TWO downloads.
In the second step, from the rootfs, I was re-using the first TAR file.
This time, I downloaded the second one, and it was much bigger, and from rootfs, I unpacked it, and sent it over…
voila.
I’ve got a working beast.
I’m so pleased.
I haven’t tried wireless yet - but I’ve got it Ethernet.
I’m ssh’d in, and I"m updating Linux.

One note - the “-S 14580 MiB” - did not work.
It complained about 512 k again.
I took that off - the Web instructions don’t call for that - and it ran through just fine.

Next up, I need to learn how it works… Jetpack… Machine Learning… etc. etc.

Thanks again. I don’t know who you are - but you were REALLY helpful.