Jetson Xavier SoC SATA controller IP

Hello Forum,
I’ve browsed the forum for information, I’m reopening the subject, I consider that the answers given are not acceptable.

The SoC/SOM is sold with the SATA functionality, see TRM. The SATA controller can pilot an SSD device directly through the UPHY10 universal interface.

When customers buy a SOM to place on their custom carrier boards, they expect to be able to do as the TRM says they can, so yes we should be able to make a carrier board design using UPHY10 and a mechanical SATA 7-pins port to connect an SSD, and yes we should have the support of NVidia if problem arise when doing so.

Having for answers: “sorry we have never validated the SoC SATA controller” or “you need to use a PCIe-2-SATA bridge like is done on the devkit” (BTW, try to buy the Marvell bridge from a reliable and well known supplier and you’ll have fun, real customers doing real production do not buy from amazon or ali express or chinese websites) or “we will not help you in this matter” IS JUST NOT ACCEPTABLE.

Please point us to a document or else that shows the SATA controller of the SoC has been validated (I’m sure there is one, you cannot sell a SoC/SOM with this marketed feature if it does not work as specified, otherwise this becomes a legal matter), and explains the requirements/process to follow at L4T level.

(ex TI/OMAP, Samsung/Exynos)

1 Like


The features that are shown in TRM indicate the hardware capability of Xavier chip.
However, not all hardware capability has software driver implementation.

This kind of issue happens in many categories. For example, there are many features listed for camera/display I/O in TRM but actually the driver is not fully supporting them.

Currently, there is no such document that can achieve your need. You can use TX2 or TX1 that has SATA support instead.

Hi Wayne,

  1. the TRM has a complete description of the SATA controller registers.
  2. the L4T (try make menuconfig, section serial ATA) implements the full support of the SATA AHCI driver

In other words, direct access to a SSD using the SATA/HW controller inside the Xavier is fully implemented by the L4T/SW delivered with the Jetpack.

Having worked in a domain similar to yours (technical support), you should be allowed to raise any subject from this “free DEVKIT support forum” to a true “NVIDIA SOM customers technical support forum”. But apparently, there is no such thing,

I advise NVidia to see how Epiq work with its customers: we buy a devkit, we have a dedicated forum for technical support.


It is possible (though definitely not easy) that you could take the SATA driver in Linux and port it to CBoot. Both Linux kernel and CBoot have some similarities as bare metal programming. Honestly, it would be nice if all boot code of all of the different types of Jetsons had drivers for all of their I/O interfaces, but lacking this, if you are ambitious, it should be possible to start with the Linux SATA driver and port it to CBoot as well. Not a great option, but it is an option.

Hello linuxdev,

the intention is not to have the SATA SSD drive as a boot option, all we need is access to the data on the disk once the OS is up and running.

I’m not sure if Nvidia has realized that you need a license from Marvell + buy a min qt of 5K/year to get access to the PCIe-2-SATA bridge.


SATA drivers should be part of the kernel. What do you see from:
zcat /proc/config.gz | grep SATA

As is also visible in the .config (or make menuconfig) of the L4T. My initial request, based on difficulties others have had in trying to implement this SATA function, was whether or not NVidia has compiled a techdoc for this subject (lessons learned from past experiences) which would proove its Xavier SATA controller is actually working as designed.

That’s not the case, which is not a good indicator of the quality NVidia is putting in its designs validation (or they dont want to share it, which is probably closest to the truth). At TI, for each OMAP going out, a specific proprietary (non public) board was designed to be able to test every IP of the SoC on every interface it could be muxed to, in every configuration it could be used.

I don’t know of any other documents, and was only thinking of the driver. It sounds like you have other changes which I have no knowledge of, so I can’t really be of any help beyond checking if you have the driver. I’ve not worked on any custom wiring, and also have no access to other information, so there isn’t much I can do beyond what I’ve already mentioned.