It’s interesting that I was not able to find any mention in TK1 or Jetson docs as to which SATA speeds are supported, only that it was a single lane (and I don’t know enough about SATA to know how that translates to 3 or 6 Gb). I see in the kern.log that the kernel is calling it 3 Gbps, so I’m going to guess it is SATA2. Whether 200MB/s (1Gbps) is good or bad for this drive I don’t have a clue.
I check the Technical Manual of TK1 and find that the default setting of SATA GEN3 is disabled.
(Can got it with read-only in Feature Register and CFG_SATA register)
But I can’t find any register which can enable SATA GEN3 in Techincal Manual.
Maybe it is undocumented?
I think he meant he explicitly read the CFG_SATA register (pg 2050).
He found that read only bit 14 is set to 0 which tell it that this is not GEN3 capable.
Which kinda explains why sometimes my SATA devices fail completely after a couple of link attempts
I’m not sure what the firmware effects under SATA, but there is mention of “sata” in the pm375 firmware dtb.
I see “SATA” controller listed in the system address map at physical address:
0x70020000
I also see something which might be related, “SATA_IOBIST” controller physical address:
0x70006c00
Although SATA_AUX is listed, this is listed as only an offset and not as a controller. So I am wondering which controller base address the T_SATA<0>_CFG_SATA listed offset 0x54c refers to…SATA or SATA_IOBIST (base plus 0x54c offset, bit 14 of bits 0 through 31). The issue being that there is so very much information to read before getting to that page in the SATA section and I’d hate to be looking at the wrong base address without having ever worked on SATA before.
Under u-boot this command locks up (perhaps it requires a disk to be attached?):
md.w 0x7002054c
…while this works and replies all 0 bits:
md.w 0x7000714c
Looks like the SATA_IOBIST is related to resets, but since I cannot read the 32 bit word at SATA base + the _CFG_SATA of 0x54c I’m wondering if this would change by adding a SATA device (I have no SATA drive attached).
My big question here is how was the _CFG_SATA register read? Was it from u-boot or from the kernel? Was there a SATA drive connected at the time?
An indirectly related comment is that access speed via throughput is not the same as link speed. hdparm says that it reads the buffer on the disk (not the disk itself) so this would still have a relation to SATA 2 versus 3. If I run this test on a desktop system using a standard SATA2 7200 RPM drive I get:
Timing buffered disk reads: 230 MB in 3.01 seconds = 76.38 MB/sec
…this is still FAR slower than the original poster’s reading on the SSD. I would entertain the possibility that the original test could be consistent with SATA3. After all, if the hdparm test really does measure just the throughput from buffer RAM in the disk, this could be an expected real world throughput. How fast should hdparm -t show for this disk if at Gen3 speeds?
Right now I wish I had a SATA 2 and SATA 3 disk to test with. I don’t have access to my development systems so I can’t really look yet, but there must be some obscure way to detect link speed. If it turns out the speed is just low on SATA 3 then some profiling could be done.
guillaudeu1->
The SATA driver supports only GEN1 and GEN2 drives. GEN3 drives can work but only at GEN2 speed, so the max speed will be 3Gb/s.
We support SATA specification rev 3.1 and AHCI specification rev 1.3.1, But our controller works only in Gen2 mode, It does not support GEN3. So all GEN3 drives will be enumerated in GEN2 and works at 3Gb/s speed.