SATA SSD not detected after reboot

Autonomous Machines Jetson & Embedded Systems Jetson TX1
1

I’ve been experimenting with using an SSD in the SATA slot for secondary (not rootfs) storage, and running into an issue where sometimes the SATA controller does not detect the device after a reboot (PXSSTS register is zero). It always works after cycling power, though.

Usually it alternates - reboot once, no detection; reboot again, and the drive is detected.

These are SATA and mSATA (via adapter card) devices for embedded systems. I don’t have this issue when using them on other hosts, so I’m pretty sure they’re OK. Experiments using a regular HDD from a laptop in the TX1 dev kit’s SATA slot are also successful - always detected on reboot. And I’m not trying to hotplug these devices; they’re always connected.

Is there something I can try to debug/resolve this?

2

Hi madisox,

May I know your BSP version on your TX1? R24.1/64bit OS? or other?

What’s the model of your SSD?

Thanks

3

It’s R24.1, 64-bit.

I’ve tried a few, but for my latest tests I’ve been using a Toshiba THNSNJ256WMCU and Innodisk 3MG2-P. Both are mSATA parts.

Thanks,
-Matt

4

Maybe this guide by jetsonhacks can help you.

5

I ran some further tests and came up with a workaround for the issue.

I had been using a customized kernel, so I started with some comparisons against the stock L4T kernel and configuration. I found I couldn’t reproduce the issue with the stock kernel. I also noticed that with my custom kernel, I would see the problem if I reduced kernel logging to the console using loglevel=3 on my kernel command line, but the SATA drive would always be detected if I left on all logging. That wasn’t really satisfactory, though, so I did some further digging.

One thing I noted was that the SSDs I’m testing all support DEVSLP. Since the problem manifested itself at device initialization time, I wondered if there was some kind of interaction between the Tegra’s power management and the drives’ DEVSLP feature. The following patch appears to work around the problem:

diff --git a/drivers/ata/ahci-tegra.c b/drivers/ata/ahci-tegra.c
index 138de56..55d8f4d 100644
--- a/drivers/ata/ahci-tegra.c
+++ b/drivers/ata/ahci-tegra.c
@@ -3065,7 +3065,7 @@ static int tegra_ahci_init_one(struct platform_device *pdev)
                if (!(hpriv->port_map & (1 << i)))
                        ap->ops = &ata_dummy_port_ops;
                else
-                       ap->target_lpm_policy = ATA_LPM_MIN_POWER;
+                       ap->target_lpm_policy = ATA_LPM_MAX_POWER;
        }
 
        rc = ahci_reset_controller(host);

With this change, the SSD is reliably detected on every boot. The libahci code will enable the drive’s DEVSLP feature with the ATA_LPM_MIN_POWER policy, and will disable it otherwise, which reinforces my suspicion that there’s some kind of timing issue or other interaction that was causing the problem.

6

Hi madisox,

Is there a way to change the lpm_policy directly on the system without recompiling the kernel and flash the Tegra again?

Best!.

7

Not with the 3.10 kernel in R24.x. With the 4.4 kernel in R28.x, NVIDIA added some device tree settings. They default to disabling devslp and setting the lpm policy to the maximum power.

8

Hi, nice to know, unfortunately, I have to use kernel 3.10 because of the custom Auvidea 106 carrier board, I tried loglevel=6 on kernel command line because with 3 I still had the problem with my Samsung 850 EVO SSD, at least I can work now, I will try with the patch that you provided.

Thanks a lot.