a friend of mine and me, are just getting started with the freshly arrived Jetson TK1. We booted, installed the NVidia Stuff, downloaded the CUDA Examples (so yes, ethernet / internet works) and they run fine.
What i am trying to achieve now, is to make the Jetson run from an SATA SSD, to make development as fast as possible, as well as to be “unlimited” in disk space.
1.) does the described way work with the internal SATA port as well?
2.) how would i determine, or change, the boot order (MMC, USB, SATA)?
In my imagination, there should be an easy way to just put an image on the SATA SSD (an exact copy of the mmc, for example) and tell the bootloader (or bios or whatever) “you boot from there, from now on”.
Sorry, for possibly noobish questions, i just don’t want to break things :P Every hint is very much appreciated =)
thx for your answer :) after i found out that the integrated eMMC 4.51 is not the slowest, i will first try to work with S-ATA as pure space supply. nevertheless it is great to know that the formerly intended way actually works :)
Is /mmc1 an SD card mounted on your PC? Is is mounted with “noexec” (running “mount” might tell the options)? “noexec” means that you can’t execute anything on that mount point.
I booted up an Ubuntu VM on a Macbook and connected the Jetson in recovery mode. From what I can tell flashing to sda1 is now kernel panicking because of some missing data or an expectected ext2/3/4 partition - originally I partitioned as per the guide from the forums as sda1,sda2,sda3 but it looks more like the system just needs to have a single or double partition made up of the root and perhaps a swap point.
I compiled the drivers and grabbed the firmware for my 3160 per some other folks on here suggested, and right now am writing to the mmc0 to see if this thing works out with the new drives - also added the zram support since we’re limited to the 2GB.
Working on getting pyrit and a good dictionary file for some Pen Testing examples if the wireless drivers actually work out okay.
Will try the sda1 as soon as I’m done confirming that the kernel modules actually load correctly.
If USB as well as internal SATA are adressed with sda1, how is the boot order determined? And how would the flash tool know where to flash, if just “sda1” is specified?
Apologies again for so much questions, i’m really new to both TK1 and linux, i seem not to understand too well ;)
The flash tool doesn’t see the SATA port. All it can see is the onboard. Mind you, I haven’t tried with usb storage.
The current u-boot version doesn’t support booting a kernel directly from SATA.
You CAN boot a kernel from the eMMC and it will understand SATA and USB and be able to mount the root ( / ) filesystem off of them. Typical detection order in the kernel will be SATA then USB. So if you had SATA and USB, the SATA would most likely be sda while the usb would be sdb.
Perhaps useful to know…the list of bootable devices is very important (someone already mentioned it, e.g., mmcblk0p1 is eMMC, mmcblk1p1 is SD), but none of them will show up unless the micro-B USB is connected and the Jetson is started with the recovery button held down. The Jetson then becomes a USB device for use by the flash.sh program on the host. Unless that occurs, the flash.sh cannot succeed.
Permissions are very important, and not optional. Failure to unpack packages on the host as root (e.g., via sudo) will cause failure. Failure to preserve permissions during unpack may cause bizarre behavior. Failure to have /dev/loop0 will cause failure (can be created if it doesn’t exist via losetup --find as root). Failure to flash as root will cause failure.
Once flash.sh is run, the entire file system is created on the host machine and loopback mounted. The file is bootloader/system.img. There is an option to re-use this instead of creating it each time; creating this is the big time consumer. If you build on sda and tell it to make the partition 100GiB, then you will have to create a file 100 GB in size on your host…and have much time to twiddle thumbs while waiting. Should you choose to boot from sda, you don’t necessarily have to make your partition for boot huge…this could still be 14GiB and then remaining hard drive mounted somewhere like /usr/local/.
The ability to pick boot devices and have a menu requires that (a), one boots using the serial console (any other connection will not have access to boot menus), and also that (b) boot loader chosen is u-boot (I could add the requirement of a fast eye, as you don’t have long after power up to hit a button to stop default boot; if you stop u-boot too soon, run the command line “boot” and the boot device choice appears immediately).
fastboot boots exactly to the -k 6 partition, and is not editable after install; u-boot looks in the /boot/ directory, and allows multiple bootable kernels and edit of the boot menu, plus by default picks boot order of external bootable devices first, internal after (I have not used SATA devices personally). Should you have u-boot installed (requires re-flash with the -L option specifically picking bootloader/u-boot.bin instead of bootloader/fastboot.bin) your boot options on serial console are similar to grub and very flexible.
I suggest upgrading from R19.2 to R19.3, and during the upgrade specifying u-boot.
You can’t use grub or linux-image packages usually on ARM devices, they are for the X86 world. Embedded ARM devices often has very specific bootloaders and kernels and you need to follow board specific instructions to flash them.
kulve just mentioned grub is not used on Jetson, as embedded does not use this. Addtional info, if you get the L4T distribution, fastboot replaces grub by default; fastboot has no options during boot, it is hardwired. U-boot is optional with L4T, it allows much like GRUB, although you need the serial console to see and use it. U-boot can be flashed during L4T flash if you specify to use this. I highly recommend R19.3’s u-boot.
Once u-boot is installed, you can add new kernels to /boot without flashing, and copy/edit the default entry in /boot/extlinux.conf. The kernel must be the zImage format…whatever comes with other distributions, you’d want to obtain it as kernel source, built it with that configuration on the Jetson, copy it to /boot, and add/edit an entry in extlinux.conf. I currently have 4 kernels (version names added to file name of zImage), depending on what I do, none of which required flash. For various reasons, I also copy the uncompressed vmlinux image and System.map of each kernel version to /boot, but this is not required.