Hi!
I fellowed the two videos to boot from the usb disk and SD card, However both of them failed!
but when I make the internal emmu into two parts, the another can work when doing like the method
Do you have a serial console? See:
[url]http://www.jetsonhacks.com/2017/03/24/serial-console-nvidia-jetson-tx2/[/url]
If you have this it will be both easier and safer to make boot changes and test configurations.
Yes, I used the serial console.
I thought it’s easy to boot from SD card or USB disk, however the system can’t boot. So should I try again to do like mentioned above ? Or I need use another way ?
Since the method you refer to is via video it is hard to look at details (though probably valid for most all Jetsons), but here are some things to understand about making alternate boot media (this is commonly asked, so I am giving more details in case someone else needs this)…
Preconditions:
- When talking about partitions it is generally implying "GPT" partitions instead of older "BIOS" style partitions. The tools "gdisk", "gparted", and various "g" versions supercede "fdisk" and the older tools. Most of the time the o/s will do the right thing anyway for some older partitions since GPT was already BIOS aware when it was created, but not all BIOS tools can deal with GPT. Don't use fdisk for Jetson content which is intended to be part of the boot sequence. If you used the GUI tools from Ubuntu, as per the video, then this won't be an issue.
- File systems on Jetsons are expected to be ext4. Other file systems can be dealt with by Linux, but U-Boot does not understand everything which Linux understands...in order for U-Boot to read a config file it has to be able to read the file system. Make sure ext4 is what you use for any boot media. This sounds simple, but if you use some of the newer distributions, then they might be using 64-bit extensions, and U-Boot does not understand 64-bit extensions (a 64-bit ext4 is just binary data to U-Boot). If you use an Ubuntu host this isn't an issue. I use Fedora 27, and this too does not by default enable 64-bit ext4. If you use an alternate host be sure you do not have this in your "/etc/mke2fs.conf" ext4 section:
metadata_csum 64bit - Any method of copying one rootfs to a new rootfs (such as an existing eMMC rootfs to SD card) must preserve file permissions. There is no possibility of a non-Linux file system being able to do this, e.g., a VFAT SD card. If you used the video procedure this won't be a problem.
There are a lot of variations on boot details due to U-Boot having macros set up to search for alternate boot media. This can cause confusion to people making alternate boot media. If it were not for these alternate media search macros, then flashing to mmcblk0p1 would imply “/boot” of the eMMC is always used for finding out what rootfs to use. If not for alternate media search rules in U-Boot, flashing to mmcblk1p1 (SD) card would imply “/boot” of the SD is always used and eMMC’s “/boot” would be completely ignored. Consider this basic rule though: Depending on which device (eMMC versus SD card or USB SATA) is found, all other “/boot” content, on all other devices with a “/boot”, will be ignored. Once Linux boots one of these other “/boot” locations may show up, but it had no participation in the boot process.
For the case of eMMC being the boot target and finding a “rootfs=/dev/mmcblk0p1” in it, then “/boot” that you see after boot completes is actually the same “/boot” U-Boot read. For the case of eMMC’s “/boot” being read by U-Boot, but finding “rootfs=/dev/mmcblk1p1”, the rootfs of SD card would be used and the “/boot” seen after boot completes would not be the one U-Boot used. If you edit the wrong extlinux.conf, then you won’t get the results you expect.
If it turns out that you put the same extlinux.conf on both eMMC and SD card, then you can’t go wrong :)
So to create a rescue SD card or alternate boot SD card think about it as these steps:
- The SD card needs to use a valid ext4 partition type, and the partition needs to be the first partition. Using either the whole device or a different partition may fail or have unexpected consequences.
- The content of the partition must have all permissions preserved when copying in content. Only root can do this, so always use "sudo" for this step.
- The content of everything outside of "/boot" is more or less generic. The sample rootfs plus apply_binaries.sh step can accomplish this. So can copy of a rootfs of any other working content, e.g., from an updated rootfs of another Jetson using the same release.
- The part which you must look at closely is what went into "/boot" if and only if U-Boot uses that device's "/boot".
- A copy of the content of any known working "/boot" can be used after editing as alternate boot media.
- An alternate boot entry can be added which is a near-copy of the original boot entry.
- The alternate boot entry would name mmcblk1p1 instead of mmcblk0p1.
- Once you know it works (boot entries are selectable via serial console), then you can make that entry the default without destroying the original boot entry.
- If you flashed with a given release, then the "rootfs/boot/" directory will have valid content as a candidate for editing.
- Until you have flashed once the content of the host's "rootfs/boot/" will not be enough to use as a valid boot directory content.
- Your exiting Jetson's "/boot" is a candidate for copy and editing.
- If you leave the "/boot" of your alternate media empty, then if U-Boot has default search rules, it should revert to the original extlinux.conf on eMMC.
- "apply_binaries.sh" should always be run with "sudo". "apply_binaries.sh" has an optional argument to name an alternate destination. An example if you have a host with an SD card mounted on "/mnt":
sudo ./apply_binaries.sh -r /mnt - Previously installed rootfs partitions already have apply_binaries.sh content. A second application of apply_binaries.sh is not useful, but is also not harmful. This is the content which is checked from:
sha1sum -c /etc/nv_tegra_release…if the sha1sum content is not “ok”, then apply_binaries.sh would actually be useful and correct the issue (this is just one way to fix such an issue).
- Other than the "/boot" content, unpacking the sample rootfs into the first partition of an ext4 formatted SD card and using apply_binaries.sh on that partition will give you the default Jetson install.
When you copy “from one file system”, it is implied that you won’t cross partition mount points. Examples of alternate mounts would be pseudo file systems which are really in RAM and not on eMMC, e.g., “/sys”, “/proc”, “/tmp”, and sometimes (most of the time) “/dev”. Copying all of this content from a running Jetson onto SD card would copy both rootfs and “/boot” content, although you would need to edit the “/boot” extlinux.conf on the alternate media.
If you boot to SD card with an exact copy of the original rootfs from eMMC, then expect it to still run on eMMC. This is because both the eMMC extlinux.conf and SD card extlinux.conf both name “mmcblk0p1” as the rootfs. If you change the “MENU LABEL” slightly on the SD card version, e.g., add “SD” in front of all MENU LABELs, then in serial console you will see this change should it be the SD card being used for boot. Should eMMC still be used for its extlinux.conf, then the edit won’t show up.
Both SD and eMMC extlinux.conf could be edited to have dual entries pointing to eMMC and to SD…this is the best of both worlds. You then use serial console to pick the entry you want. It won’t matter which extlinux.conf is used, both will have both entries. Once you know the entry works, then just change the “default” to the entry you want in both.
Because of U-Boot search macros for finding alternate boot media it might be the SD card’s extlinux.conf which is used even if eMMC was named as the flash target (the default).
Copy as you did it should work if permissions are preserved and if the extlinux.conf is edited. The original extlinux.conf should also be edited, but default not changed until you know it works.
1 Like