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:
l4t-21.8 ==> OK
l4t-21.4 ==> NG
l4t-21.7 ==> NG
l4t-21.4 rootfs + l4t-21.8 uboot kernel dtb ==> OK
l4t-21.4 uboot dtb rootfs + l4t-21.8 kernel ==> NG
l4t-21.4 uboot rootfs + l4t-21.8 kernel dtb ==> kernel not started
l4t-21.4 kernel dtb rootfs + l4t-21.8 uboot ==> kernel not started
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
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
the change in uboot：
sata@70020000 {
compatible = “nvidia,tegra124-ahci”;
reg = <0x70027000 0x2000>, /* AHCI /
<0x70020000 0x7000>; / SATA */
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.
…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.