SSD not recognised unless hot-loaded

Running R19.3 release on a TK1 and it recognises a normal HDD (1TB WD) when connected via SATA when the power is off and I can then lsblk after boot and it shows up under /dev/sda as sda1.
When I attach a M550 crucial 512GB SSD via SATA when the power is off it takes up to 60 seconds to go through boot and when it does boot lsblk doesn’t display any device as sda1 and I cannot mount the SSD.

However, if I hot load the SSD after boot whilst using SATA it shows up under sda1 and I can mount it with

sudo mount -t ext4 /dev/sda1 /media/ubuntu/ssdMount

What is happening/is there a known fix for this?

I haven’t followed specific drives, but there were several SSDs which had issues that were corrected in later releases. The most recent version of L4T for TK1 is R21.4, which fixed most (or all) of that. Flash R21.4 and check again (lots of fixes made that release worthwhile for many reasons, not just SSD).

Thanks for the prompt response.

I am using Point Grey cameras with this Will the modifications be stable with 21.4 as well? This is a rather specific question but it mainly concerns the fix to support USB3.0 and allow the USB memory buffer to be enlarged.

In short, all modifications to R19.3 will transfer to R21.4 or there is a similar fix?

I’m not sure what the guide is, but USB3 is stable on R21.4. Enabling it is the same in both R19.x and R21.x. I’m guessing you intended to paste in the URL for that guide, but we got the title instead. If the change was a patch then there is a strong chance the R21.4 kernel has the patch. If it is a customization I don’t know. Both kernels are 3.10.x series, so a patch applied to R19.3 and not yet implemented on R21.4 should be capable of porting “without much issue” (trademark, “user defined custom panic level”…YMMV :).

Thanks, edited the previous post to include URL and will switch over shortly.

“without much issue” = fun times ahead methinks

Ok, it looks like from the docs you gave the URL to that R21.4 and the kernel edit will be fairly trivial. If for safety you want to clone the root partition before you start, or indeed the whole TK1, see:

The first actual step would be to flash R21.4, following the regular documentation. A command line, once rootfs is in on your desktop host machine, and you have run, would be something like:

sudo ./ -S 14580MiB jetson-tk1 mmcblk0p1

You would then bring up the Jetson normally. There would be one change to /boot/extlinux/extlinux.conf, this would be to change “usb_port_owner_info=0” to instead be “usb_port_owner_info=2”. This enables USB3 on the full-size USB connector. Reboot after this file edit.

Although it may sound complicated, you would then put the kernel source on the TK1 and edit one line in one file, followed by putting the new kernel in. When using the u-boot boot loader (default of R21.x) you don’t even need to flash, you’d just copy some of the compiled files into place. It takes a bit of time, but is actually fairly pain-free.

If on your TK1 you unpack the kernel source to to your Jetson directory “/usr/src/kernels”, you will have a kernel subdirectory. Within that is file “drivers/usb/core/devio.c”. Search for the line:

static unsigned usbfs_memory_mb = 16;

edit the “16” to instead be 1000. Build the kernel and modules (setting CONFIG_LOCALVERSION) and put them in place, reboot. All of the Jetson patching and USB3 setup will be complete.

General comments on building the kernel:
when your R21.4 first runs after flashing this new L4T version, save a copy of /proc/config.gz. This is a reflection of your running kernel configuration. Uncompressing it and renaming it “.config”, placed in the kernel source tree gives you an exact copy of the running kernel’s working configuration. Keep an archive copy of this file on both the Jetson and your host. For your case you will use this exact copy without edit. The kernel is getting a code change, but configuration is remaining constant.

The module search includes CONFIG_LOCALVERSION in the .config. Before you compile the new kernel, check your Jetson’s response to “uname -r”. You will see something like 3.10.40-gdacac96". The “-gdacac96” is the suffix which goes into CONFIG_LOCALVERSION. This will cause module searches to go to the original location and avoid complicating things.

You will need to copy the zImage to /boot, probably backing up the old one. I’d rename the old one “zImage-3.10.40-gdacac96-original”, and put the new one in by copy to name “zImage-3.10.40-gdacac96-cam” (short for camera). In your /boot/extlinux/extlinux.conf, you will see something like this:

LABEL primary
      MENU LABEL primary kernel
      LINUX <b>/boot/zImage</b>

The “/boot/zImage” is where this boot entry will look for the kernel…since you installed file “/boot/zImage-3.10.40-gdacac96-cam”, you would change the entry name “zImage” to “zImage-3.10.40-gdacac96-cam”.

Any make modules_install step would automatically use the CONFIG_LOCALVERSION of “-3.10.40-gdacac96” which is what the install was originally using…any modules_install would be correct without moving things around.

If you need to know more about kernel compile or install under u-boot, just ask.