Now since those were for TK1, I’m assuming something’s different and I can’t see any extlinux.conf file inside the unpacked tar files after running apply_binaries.sh. What I next did was manually copied extlinux.conf from /boot/extlinux of my Jetson TX1 eMMC to the sd card. I also modified the newly copied extlinux.conf on the SD card to have root point to the SD card instead of eMMC. So it looks like this now:
I was under the impression that uboot will first try SD card and then (if nothing was found) would boot from eMMC. If I plug in the SD card and power Jetson up, I still land in the eMMC Linux.
The file system layout information should be compatible between JTK1 and JTX1. Some of the software will differ of course, and I’m not sure of what difference there is in u-boot for JTX1 versus JTK1. I suspect they are very close or equal, as the JTX1 u-boot has only 32-bit address space (there is a significant possibility that this will change in the future).
Not an answer to your question, as I cannot confirm if lack of a bootable device causes u-boot to first search SD card…this may be. Additional notes though may apply.
During flash the Jetson will memorize where the boot loader is. This can be on eMMC (mmcblk0p1), or it can be on an external device, such as SD card (mmcblk1p1). Be careful to distinguish that boot loader and root file system are independent. I never put the boot loader on SD card during a flash, but I will put a root file system there (e.g., I’ve put Android on SD card and preserved base install, only an edit of extlinux.conf was required). When boot loader is on eMMC, the “/boot” directory the boot loader refers to is also there…if boot loader is installed to SD card, then “/boot” implies the SD card “/boot” (boot loader and kernel can, at least in part, refer to files on “/boot” of different devices). It may be best to just mirror any files for either of these on “/boot” of both the SD card and the eMMC when boot loader resides on SD card. Even when boot loader is on eMMC, I mirror those files to SD card as a reference in case of later flash.
I strongly recommend that before trying to put a boot loader on SD card, that only the root file system goes there. After placing a sample rootfs on SD card, the apply_binaries.sh script can be used, but requires the “-r PATH” option to point at the SD card mount point. apply_binaries.sh does not place all of the boot files there, some are from the sample rootfs, and some “/boot” files are modified by flash options. If you want to guarantee that the flash software does not modify the sample rootfs “/boot” directory, you must have a root partition image and select to re-use the image…generating an image does not preserve “/boot” files.
I posted a reply but don’t know what happened to it!! So here I go again:
First, thanks for you reply!
So to be honest, I don’t care about having a /boot on the SD card. All I want to do is boot the Jetson from the SD card (if an SD card is inserted – probably something similar to your Android setup). So I’m essentially making sure that a root file system is present on the SD card.
Based on what you mentioned about your Android setup, I’m assuming that I should add an entry to extlinux.conf on the eMMC’s /boot/extlinux path, that points to the SD card. Am I correct?
Now that’s what I’m doing. I mount the formatted SD card to “rootfs” insidethe “Linux_for_Tegra”. Therefore once I run apply_binaries.sh, everything is copied directly to the SD card (not sure if I still need to specify path with "-r PATH). Is there anything else that should be done besides that?
One point about “/boot” is that depending upon stage of boot, when using u-boot on eMMC but root partition on SD card, is that the different stages may search for files on the different devices…just beware that having a file on one “/boot” of one device which is accessed correctly does not assure that a different stage of boot may look at a different device (that file may no longer be valid because that path is no longer mounted from the same device). If all files of “/boot” are duplicated on both devices, then there cannot be such an issue.
If your SD card is mounted to the rootfs of the flash software, and you’ve unpacked to that, then the apply_binaries.sh should be fine…this is the default location for it. If your SD card is mounted somewhere else other than the default unpack location of the sample rootfs, then you need the “-r” option. I personally just mount the SD card on /mnt, unpack there, and apply_binaries.sh with “-r” to point at that. My default rootfs location is never modified with experimental builds.
I see… So if I understand correctly it’s safer to have /boot copied on SD card as well…
So, as I mentioned in the first post, although I did give such configuration a try, I couldn’t boot from the SD card. Not sure what else should be done to boot from the SD card. Maybe somebody could shed some light on that :)
Awesome! I can now confirm that I can boot from the SD card.
Here are the steps I followed in case anybody else got stuck like I did (adapted from http://demotomohiro.github.io/hardware/jetson_tk1/setup/sdcard.html). Note that I performed all these steps on the Jetson itself, but the steps should be the same on any host.
Make sure that your SD card is inserted, formatted with ext4 file system and is not currently mounted.
Extract the downloaded files, mount the SD card and extract the sample file system to it.
$ sudo tar xvpf Tegra210_Linux_R23.2.0_armhf.tbz2
$ sudo mount /dev/mmcblk1p1 Linux_for_Tegra/rootfs
$ cd Linux_for_Tegra/rootfs
$ sudo tar xvpf ../../Tegra_Linux_Sample-Root-Filesystem_R23.2.0_armhf.tbz2
Run apply_binaries.sh:
$ cd ..
$ sudo ./apply_binaries.sh
On your Jetson TX1, open up /boot/extlinux/extlinux.conf in a text editor and add an entry to it pointing to the installation on the SD card. Mine looks as follows:
Note how the sdcard entry is set to default.
Save the config file and reboot your Jetson. It should now load into the L4T installation on your SD card.
You could choose which OS to boot via the serial console.
In some form extlinux.conf must have an entry which can be chosen (or default) to point at /dev/mmcblk1p1 if SD card is to be booted. This is the “root=/dev/mmcblk1p1” for SD, as opposed to “root=/dev/mmcblk0p1” for eMMC. I prefer to just edit my extlinux.conf to have an extra entry pointed at SD and then use serial console to pick that (at least until tested).
Your SD card would have at least one partition, but could have more. The first partition is mmcblk1p1. You could put the SD card in a PC and run “lsblk” to see what it thinks partitions are.
If the issue is the content of the SD card, then one of the big contributing factors to odd behavior is if root permissions were not used for all steps of creating the file system (logging in as root or using sudo fixes this). E.G., some files with critical permissions would exist, but be of the wrong ownership and permissions, so they would not function as expected (the sudo command itself is one of those commands which would behave wrong if it has wrong permissions).
Keep in mind that depending on how flash was done, you may be using extlinux.conf of eMMC or of SD card. If you corrected “mmcblk1” to be “mmcblk1p1”, then I am suspicious of this error being on the other extlinux.conf (otherwise it would say mmcblk1p1 instead of mmcblk1):
[9.309994] Waiting for root device /dev/mmcblk1...
If flash was set to point at eMMC for extlinux.conf, then eMMC extlinux.conf is used…this is perfectly normal and you can still point at SD card for root file system (flash parameters are where extlinux.conf is looked for, the content of extlinux.conf is where rootfs is looked for). If flash was set to point at SD card, then this extlinux.conf will be used. Having the edit work once, but then revert to “Waiting for root device /dev/mmcblk1…” makes it plausible that the file being used was different. Just to be sure, use the same extlinux.conf on both eMMC and SD card.
gui mode doesn’t work. it gives me an error saying
“The system is running in low-graphics mode”
“your screen, graphics card, and input device settings could not be detected correctly. You will need to configure these yourself”
Normally there would be one gpt partition for the whole SD card, though this could be customized. It should show as mmcblk1p1, not mmcblk1.
For sudo, which is the Jetson’s permission? Use:
ls -l `which sudo`
The apply_binaries.sh step provides the hardware access files which allow GUI. Was this applied using sudo to the SD card? There are also issues if cables are not correct, can you describe exactly which cable types and adapters may be in use?
If it won’t boot from eMMC, then there is a strong change you flashed mmcblk1p1 instead of mmcblk0p1. This is doing as expected. You will want to flash to mmcblk0p1, and then edit the extlinux.conf in eMMC to have a new rootfs of SD card. Be very careful to not confuse root file system from extlinux.conf with where flash points the boot loader to find configuration. You will probably need to flash to mmcblk0p1 again if you want to boot without an SD card present.
Thank you linuxdev. It worked. It was actually a problem with the partition. After i created a partition, it worked fine. Do you by any chance know why that was the problem?
I’m just speculating, but programming to use any partition scheme or device in general is difficult in something as small as a boot loader (and in addition to keeping the boot loader small, coding on “bare metal” makes it more difficult). It was probably just hard coded in u-boot that if looking for an SD card that the first partition would be used…mmcblk1 is not a partition, it is a device.
I tried to let JTX1 boot from SD by following aznroscatkin’s instructions. During the boot, lots of prints could be shown on monitor, but it couldn’t enter ubuntu desktop and even terminal. There is no way for me to login via terminal. However, I could ssh to it successfully. Could anyone give me a pointer on this? The version I installed is Jetpack 2.1.
ubuntu@tegra-ubuntu:~$ uname -a
Linux tegra-ubuntu 3.10.96-tegra #1 SMP PREEMPT Tue May 17 16:31:40 PDT 2016 aarch64 aarch64 aarch64 GNU/Linux
ubuntu@tegra-ubuntu:~$
ubuntu@tegra-ubuntu:~$ head -n 1 /etc/nv_tegra_release
R23 (release), REVISION: 2.0, GCID: 6630372, BOARD: t210ref, EABI: hard, DATE: Tue Feb 9 01:49:02 UTC 2016
ubuntu@tegra-ubuntu:~$
ubuntu@tegra-ubuntu:~$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
mmcblk0rpmb 179:16 0 4M 0 disk
mmcblk0 179:0 0 14.7G 0 disk
├─mmcblk0p1 179:1 0 14G 0 part
├─mmcblk0p2 179:2 0 2M 0 part
├─mmcblk0p3 179:3 0 4M 0 part
├─mmcblk0p4 179:4 0 2M 0 part
├─mmcblk0p5 179:5 0 6M 0 part
├─mmcblk0p6 179:6 0 4M 0 part
├─mmcblk0p7 179:7 0 6M 0 part
├─mmcblk0p8 179:8 0 2M 0 part
├─mmcblk0p9 179:9 0 2M 0 part
├─mmcblk0p10 179:10 0 20M 0 part
├─mmcblk0p11 179:11 0 64M 0 part
├─mmcblk0p12 179:12 0 64M 0 part
├─mmcblk0p13 179:13 0 4M 0 part
├─mmcblk0p14 179:14 0 2M 0 part
├─mmcblk0p15 179:15 0 6M 0 part
├─mmcblk0p16 259:0 0 6M 0 part
├─mmcblk0p17 259:1 0 2M 0 part
└─mmcblk0p18 259:2 0 496M 0 part
mmcblk1 179:32 0 29.8G 0 disk
└─mmcblk1p1 179:33 0 29.8G 0 part /
ubuntu@tegra-ubuntu:~$
Unless you need a 32-bit user space I’d suggest going to R24.2. I’m not sure what the exact instructions were for the post you were following, but more detail on how you flashed would help, especially how you created the partition on the SD card. In particular, if you can mount the SD card on any Linux machine and show the relevant output of “df -H -T” for that SD card it might help.
That log looks correct, but without more of the log it is hard to tell everything that goes on. It seems as though the part which is failing is that it mounts the SD card on “/media” instead of on “/”. This would mean your extlinux.conf edit is still using the original entry. Look very close at those prior posts on the edits to extlinux.conf. Please note that the eMMC has an extlinux.conf file, and so does the SD card…until SD is mounted, the correct extlinux.conf file is the one on eMMC…once the kernel loads, extlinux.conf no longer matters (once the kernel loads it would use the SD card extlinux.conf, but you’re done with the boot loader, so that file becomes unimportant at that point during boot). Did you edit the eMMC version (you should), or did you edit the SD card version (the inert extlinux.conf)?