SATA Hotplug


I am trying to implement SATA Hotplug functionality, I run into this topic, which claims that NVidia does not support this functionality.

Has NVidia changed its approach and added the SATA Hotplug support?



Hi igal.kroyter,

Yes, we are not support SATA hotplug function.

Hi carolyuu,

When you say we do not support do you mean that you prohibit it on the hardware level or on the software level (like libahci driver)?
AFAIK, UBUNTU supports the eSATA hotplug capability since version 12.0.


It does not support due to hardware issue.


could you please elaborate on the hardware issue, this capability is an essential feature in our project and I must have it working…

I can share nothing here. It is just a not supported feature.
Also, I think SATA standard does not require hotplug so we didn’t put it into design.

I don’t know about the specific case of a Jetson, but normally you need to add extra hardware (such as a removable carrier) to get “warm swap” (meaning no electrical damage to remove and add a drive on a running system). The “warm swap” has the ability to be come “hot swap” only if the right software is added, e.g., if the drive is set up as RAID.

Have you added warm swap hardware, e.g., a removable tray advertised as “hot swap” (which is misleading since it is really warm swap, but this is how they are advertised)? Once this is in place you could look at basic information on Linux hot swap and the software involved should be the same. I do not know whether or not there is some other limitation of the drive controller to make hot swap impossible.


thanks for the reply.

We have implemented HW wise the connectivity which supposed to support the disconnection and re-connection of the SSD on the SATA Bus. I just could not get it why is - software-wise - the kernel cannot activate the SATA initialization at any time. In fact it is searching the SSD at some point during the bring up process, so why can’t this process start up be delayed by a minute or so…

I’ll appreciate, if could point me to Linux kernel drivers that handles the Hot-Swap capability.


Perhaps it is SSD and not SATA…don’t know. However, what happens if you monitor “dmesg --follow” while adding or removing a regular non-SSD drive?

I haven’t looked at the hot swap software in a long time. I don’t know that the TX2 has the ability, but take a look at this:

Try to see what happens when you manually force a rescan.

Note that on a desktop PC system the motherboard BIOS may have to have a configurable option enabled to allow hotplug. An embedded system does not have a BIOS, it only has U-Boot and the pre-boot environment leading up to the o/s loading. As to where in the design or configuration something might be missing I have no knowledge.

I found this URL fairly informative on the topic:

Do try with a regular SATA hard drive as well to rule out complications from an SSD.

linuxdev, hi,

No response on the terminal while insertion and removal, in case that the SSD (Solid-State-Disk) is introduced to the Jetson after enumeration stage.

I see no devices under (when the disk is connected, but not powered on):

  • /sys/class/scsi_device
  • /sys/class/scsi_host
  • /sys/block/

and a rescan did not help.

Do you know how to postponed the SSD enumeration?

There is most likely a way to do this, but someone from NVIDIA will need to suggest how to specifically accomplish this on a TX2 (I don’t know).

Is there anyone in NVidia, that could support and provide a way to postponed the SATA enumeration process?
That is instead of initiating the SATA enumeration during the kernel bring up I’d like to activate this initiation function much later after the Operating System is on and working.


How about build ahci-tegra driver as a module and load it later after OS is on?

WayneWWW, hi,

thanks for the reply. This was my original intention, but I failed doing it.
Here is how I tried to do it:

  1. Configure file tegra18_defconfig:
    • CONFIG_ATA=m
  2. make tegra18_defconfig
  4. modprobe ahci_tegra

I have failed applying the modprobe.


I am not sure how “” works. You should be better following the steps in L4T document.
Please note that “modprobe” only searches the path which is same as the result of “uname -r”.

For example,

If you use image from Jetpack, the result of “uname -r” may like “4.9-tegra”.
Under such case, “sudo modprobe” would search /lib/modules/4.9-tegra.

However, if you build image by yourself, normally that revision would be different.
If you don’t have corresponding path, modprobe cannot find your kernel modules.

WayneWWW, hi,

are CONFIG_ATA and CONFIG_SATA_AHCI drivers have to be modules or only the CONFIG_SATA_AHCI_TEGRA?

FYI, if you change settings in a menu editor (e.g., “make menuconfig” or “make nconfig”), then an ability to set as a module implies it can be a module; conversely, a lack of a module setting means it can’t be a module.

If you need access to that driver during boot, prior to having access to the file system, then you’d need integrated (or an initrd…which can be a problem, so integrated is better).

Hi linuxdev,

I do not need the driver during boot.

I have set both CONFIG_SATA_AHCI and CONFIG_SATA_AHCI_TEGRA to [b]m/b. Because only setting the CONFIG_SATA_AHCI_TEGRA and try to modprobe it caused a terminal message of symbols’ contradiction.

Is there a procedure how to do it?

How did you set it to “m”? Was it through something like “make menuconfig”? Or was it editing “.config” directly? If the former, then this is ok; if the latter, then you can’t do that.

If it turns out this can be built as a module, then logs are needed to know more about what went wrong. Normally you would get symbol errors if you add a feature which depends on another feature, and that other feature is not present…in theory this won’t happen if you use something like “make menuconfig”. Note that if this is the reason for a symbol failure, then this will fail either integrated or in module format…being a module or not won’t change what other features were selected (except if “make menuconfig” is used it might automatically add the related features).

Another reason for a symbol error is if you’ve compiled code from one kernel version and try to run it in another version.

The easiest place to start is to know what your starting configuration was, and then whether you modified it via “make menuconfig” or via direct edit of “.config”. How did your configuration start, and how did you edit this?


I have configured it manually directly in the configuration file.