TK1 L4t-21.4 , sata disk cannot be identified

 The jetson-tk1 development board Burn with l4t-21.4/l4t-21.7 , there is a problem that sata hard disk has no nodes,  the disk  cannot be identified. When the development board is re-burned with the l4t-21.8 , that disk problem has been resolved.

Then, we have did some experiments, as follows:

  1. l4t-21.8 ==> OK
  2. l4t-21.4 ==> NG
  3. l4t-21.7 ==> NG
  4. l4t-21.4 rootfs + l4t-21.8 uboot kernel dtb ==> OK
  5. l4t-21.4 uboot dtb rootfs + l4t-21.8 kernel ==> NG
  6. l4t-21.4 uboot rootfs + l4t-21.8 kernel dtb ==> kernel not started
  7. l4t-21.4 kernel dtb rootfs + l4t-21.8 uboot ==> kernel not started
  8. l4t-21.4 kernel rootfs + l4t-21.8 uboot dtb ==> kernel not started

I suspect the problem is in uboot. The version of uboot in l4t-21.8 is 2018.05, and the version of uboot in l4t-21.7 is 2014.10. There are too many differences between the two versions.I want to find out what changes have fixed the problem.
Our current system is tailored based on R21.4, I want to find a solution with minimal change to debug this SATA problem.Can you help me locate the problem ?

when disk not identified ,kernel log:help
[ 7.583906] input: gpio-keys.3 as /devices/platform/gpio-keys.3/input/input1
[ 7.593234] as3722-rtc as3722-rtc.1: setting system clock to 2000-01-01 02:40:03 UTC (946694403)
[ 7.605738] ALSA device list:
[ 7.610031] #0: HDA NVIDIA Tegra at 0x70038000 irq 113
[ 7.616732] #1: tegra-rt5639
[ 14.259735] ata1: softreset failed (1st FIS failed)
[ 24.269731] ata1: softreset failed (1st FIS failed)
[ 59.279729] ata1: softreset failed (1st FIS failed)
[ 59.289750] ata1: limiting SATA link speed to 1.5 Gbps
[ 64.500739] ata1: softreset failed (device not ready)
[ 64.511068] ata1: reset failed, giving up
[ 64.532332] EXT4-fs (mmcblk0p1): couldn’t mount as ext3 due to feature incompatibilities
[ 64.545305] EXT4-fs (mmcblk0p1): couldn’t mount as ext2 due to feature incompatibilities
[ 64.568022] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data mode. Opts: (null)
[ 64.580672] VFS: Mounted root (ext4 filesystem) on device 179:1.
[ 64.590404] devtmpfs: mounted


Are you sure this is due to the uboot? What is the result if you use 21.8 uboot + rest of driver package in 21.4?

ok I see the result-> l4t-21.4 kernel dtb rootfs + l4t-21.8 uboot ==> kernel not started

What is the dmesg of this case?

not sure,just a guess.
use 21.8 uboot + rest of driver package in 21.4 , log:

Retrieving file: /boot/tegra124-jetson_tk1-pm375-000-c00-00.dtb
59637 bytes read in 78 ms (746.1 KiB/s)

Flattened Device Tree blob at 82000000

Booting using the fdt blob at 0x82000000
Using Device Tree in place at 82000000, end 820118f4
couldn’t find /cpus
ERROR: arch-specific fdt fixup failed

  • must RESET the board to recover.

FDT creation failed! hanging…### ERROR ### Please RESET the board ###


We just checked the uboot source but there are much diff.

There are some ata driver changes here. Maybe you could apply them.;a=shortlog;h=refs/tags/tegra-l4t-r21.8-3;pg=24;a=shortlog;h=refs/tags/tegra-l4t-r21.8-3;pg=25

Also, you could try to narrow down the scope with r21.7 uboot too. We shall see which release is able to resolve issue first.

I had did this test:


I would suggest to compare the device tree between 21.4 and 21.8. Also, try to cherry-pick those changes related to ata driver.

the change in uboot:
sata@70020000 {
compatible = “nvidia,tegra124-ahci”;
reg = <0x70027000 0x2000>, /* AHCI /
<0x70020000 0x7000>; /
interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&tegra_car TEGRA124_CLK_SATA>,
<&tegra_car TEGRA124_CLK_SATA_OOB>,
<&tegra_car TEGRA124_CLK_CML1>,
<&tegra_car TEGRA124_CLK_PLL_E>;
clock-names = “sata”, “sata-oob”, “cml1”, “pll_e”;
resets = <&tegra_car 124>,
<&tegra_car 123>,
<&tegra_car 129>;
reset-names = “sata”, “sata-oob”, “sata-cold”;
phys = <&padctl TEGRA_XUSB_PADCTL_SATA>;
phy-names = “sata-phy”;
status = “disabled”;
I had tyied this, after recompiling, the problem is still there.

We are making some attempts in the driver source, but the two versions uboot code are structurely different, I can’t locate which changes are related to this bug.

So, could you help us .

Did you really mean to disable this SATA controller (versus: status = “okay”)

This piece of code was obtained from tegra124.dtsi in R21.8’s u-boot.,it make sata work.

And,I had tyied use status = “okay”; , SATA still not good.

Do you see this:

…from browsing to that same node in “/proc/device-tree/…sata@70020000” (e.g., cd there, “cat sata@70020000”)? I’m just trying to find out if the tree changes actually made their way into the final tree the kernel actually sees.