Hi,
I have a problem about the mSATA connector. I changed the SATA connector to a mSATA connector on my custom carrier board. The mSATA connector only has DATA & POWER pins, not includes a SATA_DEV_SLP pin, thus may cause the problem of identifying SATA disk. And here is the tests I have done:
I changed a TX1 module on my custom carrier board instead of TX2, the SATA disk could be identified. The differents between TX1 and TX2 is the SATA_DEV_SLP signal shown on Page10 on the document of NVIDIA Jetson TX1/TX2 Developer Kit, that means the singal SATA_DEV_SLP do have some effect on the SATA identifying.
I had done another test on the P2597 carrier board: I removed the IC U1 and R315 from the P2597 carrier board, the SATA disk can still be idenfied on the P2597 carrier board, which means the singal SATA_DEV_SLP has no effect on the SATA interface.
From the tests done above, we may get a inconsistent conclusion about the signal of SATA_DEV_SLP. If the SATA_DEV_SLP signal does work on the communication of SATA, how it works? And since I cann’t get this signal on my custom carrier board with the mSATA connector, shall I modify some software in the LIUNX system to make it work?
Could you please give me some advice about it?
Looking forward for you reply, thanks!
Hi, SATA_DEV_SLP is only available on TX2, it provides the DEVSLP feature which allows the host to put the device into the low power state. It would not affect the device detection in normal situation. Since the device can not be detected on your custom board, you might need to check other items to follow OEM DG, such as power delivery, circuit design and layout design.
From the tests done before, SSD disk could be detected on my custom carrier board with TX1, but fail with TX2. Which means no hardware design issue existed on the custom carrier board, the only difference between TX1 and TX2 is the SATA_DEV_SLP signal, what do you think of it? And any other hardware circuit or software could affect the SATA detecting with TX2 module?
Looks like you have done the test without SATA_DEV_SLP signal on TX2 module + P2597 board, right? That could prove SATA_DEV_SLP will not affect the device detection and the driver has no problem, right? So suggest you to check other items to follow OEM DG, such as power delivery, circuit design and layout design.
Yes, it’s right as you said.I have checked the OED DG, there is no difference except the SATA_DEV_SLP signal on the custom carrier board.
But the test done with TX1 module + custom carriecr board works well on the SATA detection, could this prove that no hardware issue exists on the custom carrier board?
Maybe there are other differences between TX1 and TX2?
That could not prove no hardware issue, as there might be critical point in the layout design which can causes pass on TX1 while not on TX2. Do you add the power discharge circuit as that in OEM DG?
Yes, the power discharge circuit is added on the custom carrier board, and I have checked SATA curcuit carrefully more than once, and no other issue found except the SATA_DEV_SLP signal, I really don’t have any other ideas to deal with this problem.
I checked the logs printed while restarting, with TX2 it shows ata1: SATA link down (SStatus 0 SControl 300) just as no hard disk is connected.
And here is the different logs with TX1 and TX2 attached, maybe you can help to find some useful messages, thanks!
From the log it looks like the oob sequence itself has failed. SATA devslp pin will not be involved in drive enumeration.
The sequence is as below:
After s/w reset, the hardware in devices on both ends of a link automatically begins the process of detecting whether another device is present and at what speed the interface can run.
This initialization starts with OOB (Out Of Band) signaling.
After OOB signaling the link is trained or synchronized to incoming bit streams.
When link initialization is completed the target device delivers a FIS to the host to identify itself.
The OOB signalling consists of six bursts of differential signaling followed by idle period prior to the next sequence of 6 bursts.
From the description of oob sequence and test done above, TX1 could success detecting the SATA but TX2 faild, does it mean that TX1 and TX2 have diffenent detecting sequence? If so, what shall I do to make TX2 work with my custom carrier board, need I modify some files in the Linux system about oob sequence?
There is no difference between OOB sequencing between TX1 and TX2 either in HW or SW level.
This looks more like an HW issue on custom board and it has to be debugged from HW side.
Besides, could this issue be tested with our carrier board?
I have done the test bofore,and there is no problem with the P2597 carrier board.
Since I removed many unuseable hardware design in my carrier board compared with P2597, could some of these hardware removed efferct the detection?
Not sure what’s the difference between our TX1/TX2 carrier board, are there difference in rail sequencing?
No difference except the SATA_DEV_SLP signal on the custom carrier board, right?
What’s the difference of programming sequence, if any, between the two?
To start of with it would be great if we could have the values of some status registers before and after the initialization process. This would tell at what stage the initialization actually failed.
The registers to be accessed will be at the base address - 0x03507000