Jp5.0.2 Xavier NX boot from SATA

Autonomous Machines Jetson & Embedded Systems Jetson Xavier NX
36

Hi,

The test is on our custom board

37

Is it possible to test this on NX devkit or AGX Xavier devkit?

38

NX devkit and AGX Xavier devkit has no SATA port

39

Yes, I know. Your SATA is also not a SATA devcie to jetson. Your design has a SATA to PCIe converter.

My point is if you can use same converter on NX/AGX devkit to test.

40

No, that is impracticable

I will check again the circuit and compare to nvme, because boot from nvme is work now

41

Hi,

Below is my summary of this issue so far. Could you confirm?

  1. Jetpack4.6.x can flash this SATA without problem.

  2. In jetpack5.0.2, when booting to emmc, you can see your SATA driver under /dev/

  3. In jetpack5.0.2, when you tried initrd flash to flash this SATA, it failed because initrd cannot enumerate SATA drive.

42

Yes, they are

43

Hi,

Could you boot into emmc case first and check/share below?

  1. zcat /proc/config.gz
  2. lspci -kn → To check if driver is binded
  3. ls -l /sys/bus/pci/driver to check which all PCIe client drivers available.
44

Hello,

It seems the reason of this issue is due to ahci driver is being built as ko file in jp5.0.2. But it was inside kernel image in jp4.

Thus, please modify the tegra_defconfig and make these two into kernel image.

CONFIG_SATA_AHCI=m
CONFIG_SATA_AHCI_PLATFORM=m

45

I check the command you offered

  1. zcat.txt (218.4 KB)
  2. lspci_kn.txt (688 Bytes)

The config of ahci driver is built as ko file exactly and is binded at 0004:01 where is the sata drive located

image
image1228×451 83.6 KB

46

I have modified the ahci dirver to be build in
CONFIG_SATA_AHCI=y
CONFIG_SATA_AHCI_PLATFORM=y

But it still showed /dev/sda is not ready

flash_uart_sata_ahciadd.txt (78.2 KB)

And sorry for having a question:
if we modified the config, the flash command will apply the driver when using initrd to flash?

47

What is your method to update your kernel image after you build it out?

48

I copy the Image under the build folder to L4T/kernel/

cp $TEGRA_KERNEL_OUT/arch/arm64/boot/Image $L4T/kernel/Image

Then flash again
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device sda1 -c ./tools/kernel_flash/flash_l4t_external.xml jetson-xavier-nx-devkit-emmc sda1

49

Let’s change to another way here. Please make sure your ahci driver is loaded up from kernel instead of kernel modules when you boot up in emmc first.

50

Is your new kernel using a different CONFIG_LOCALVERSION? I ask because this would change the output of “uname -r”, and it would verify if your new kernel (with the “=y” instead of “=m” for those drivers) is actually being used. I wonder if this kernel is actually the one being loaded.

Normally one loads a kernel from “/boot” (or a partition if not named in extlinux.conf or if security fuses are burned). This has to be from a filesystem type built in to the kernel. Normally the rest of the filesystem is also the same filesystem type, but if it isn’t, and if the driver for that filesystem type is a module, then one would have to load the driver to read the filesystem needed to load the driver…a bit of a problem. The initrd acts as an adapter and contains all modules needed to read this other secondary filesystem type. In your case it is a driver for the PCI which is missing since the filesystem goes through PCI. Thus the two options:

  • Easy: Add it to the kernel and not as a module.
  • Hard: Customize the initrd to have the required module.

You performed the relatively easy method, but it didn’t work. It leads me to believe that either (A) the kernel you think is loading is not really loading, or else (B) there is yet another driver involved beyond the mentioned CONFIG_SATA_AHCI and CONFIG_SATA_AHCI_PLATFORM. It is easy to check (A) if the boot messages mention the “uname” output and if this differs from what it was before.

51

Hi WayneWWW,

I exactly modified the tegra_defconfig then used ./nvbuild.sh -o $TEGRA_KERNEL_OUT

But the .config under $TEGRA_KERNEL_OUT showed “=m” for those two drivers

As you mentioned, the ahci driver is still loaded up from kernel modules

Are there any other ways to build the tegra_defconfig?

52

I would say you may need to dig into the driver by yourself and see which config is needed for it to be built inside kernel.

54

You might find this of use as background, although it covers a lot you might not be interested in (this is about manual configuration and build, but if you read the nvbuild.sh script, you could probably apply this):

55

Thanks your help very much, we solved the issue by building those two drivers successfully

1 Like
57

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.