classical sata drive problem

i have connected classical drive with 800mz/5v consumption.
i see ahci in dmesg, but not detected any drive:
[ 2.649617] tegra-ahci 3507000.ahci-sata: AHCI 0001.0301 32 slots 2 ports 3 Gbps 0x1 impl platform mode
[ 2.649629] tegra-ahci 3507000.ahci-sata: flags: 64bit ncq sntf pm led pmp pio slum part deso sadm apst
[ 2.651085] scsi host0: tegra_ahci
[ 2.651511] scsi host1: tegra_ahci
[ 2.651729] ata1: SATA max UDMA/133 mmio [mem 0x03507000-0x03508fff] port 0x100 irq 25
[ 2.651732] ata2: DUMMY

lsblk shows only mmcblk0 entries

l4t version is 28.2.1

you may also try

df -h


fdisk -l


sudo apt-get install gparted
sudo gparted

those are useful when drives are detected but not filesystems/partition.

i don’t see any drive detected. as i don’t have at hand external power for drive to see whether it draws too much power from tx2

An ordinary (non-SSD) disk which isn’t “exotic” (e.g., typical power draw from 7200 rpm) should be ok via the SATA+power connector of the dev board.

When I connect an ordinary SATA drive this way I see “/dev/sda”. My dmesg from boot changes to:

[    3.418791] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[    3.467569] ata1.00: ATA-7: ST3400620AS, 3.AAD, max UDMA/133
[    3.467573] ata1.00: 781422768 sectors, multi 0: LBA48 NCQ (depth 31/32)
[    3.525867] ata1.00: configured for UDMA/133
[    3.539121] scsi 0:0:0:0: Direct-Access     ATA      ST3400620AS      D    PQ: 0 ANSI: 5
[    3.539547] sd 0:0:0:0: [sda] 781422768 512-byte logical blocks: (400 GB/373 GiB)
[    3.539684] sd 0:0:0:0: [sda] Write Protect is off
[    3.539689] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[    3.539747] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    3.565548] random: nonblocking pool is initialized
[    3.600069]  sda: sda1 sda2
[    3.600660] sd 0:0:0:0: [sda] Attached SCSI disk

…plus lsblk shows sda and its partitions.

I am using this cable (22-pin) without any other power connection:

It would be dangerous to the Jetson to connect/disconnect a SATA drive to the SATA port while it is running, but if you have a “hot swap” carrier, then it would be possible to add or remove a drive while the system is up and running. Keep in mind that these carriers are actually “warm swap” (despite marketing), meaning they prevent electrical damage, but that software is also required if a partition in use is to become truly hot swap (such as a failed drive in a RAID array)…such a tray is good for adding or removing drives which are not mounted. Some examples:

(Do note that there are some fairly significant reliability differences between these, so read any review of these before using)

I would suggest you get such a tray so that you can boot without the drive, and then pop the drive into the bay and see what “dmesg --follow” shows during the drive connect or disconnect. This would also allow you to try multiple drives.

Btw, the cable I am using is:

None of the TX1 or TX2 allows SATA hot plugging or swapping the drives when the OS is running.
The SATA drive must to be present when the system boots up!

We found this out the hard way (when a product based on Tegra was finished). We have also thought that SATA would have the hotplug capability, but no… this is NVIDIA. Forget about things working as you are used to on other platforms, or even as they are written in the specifications.

The SATA drivers are one big hack, with an AHCI controller being created from a static memory region defined by DT. We have tried to make a module from it - it can be done, but you will not get redetection when you do a rmmod/modprobe. As it crashes on the second modprobe.

My thread from last year:

I’m not actually suggesting trying to use the drive as hot swap. The goal is to see if the kernel sees anything. Even if it has a kernel OOPS this would be useful to know something was visible on the bus (it’s just a debug tool).

As is, with no debug information at all (perhaps a higher level kernel debug level could be added…not sure what to change…perhaps someone at NVIDIA can suggest a boot parameter for verbose SATA logging), one would have to resort to something like a SATA protocol analyzer or at least some sort of view to see if there is any signal at all to the connector (in which case it’d be cheaper/faster to just RMA now…but then it might turn out to still be a problem for some other reason).

It is worth asking at this point though if there is anything customized with this kernel or device tree, and to ask if there is anything unusual about the drive itself.