The test is on our custom board
The test is on our custom board
Is it possible to test this on NX devkit or AGX Xavier devkit?
NX devkit and AGX Xavier devkit has no SATA port
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.
No, that is impracticable
I will check again the circuit and compare to nvme, because boot from nvme is work now
Below is my summary of this issue so far. Could you confirm?
Jetpack4.6.x can flash this SATA without problem.
In jetpack5.0.2, when booting to emmc, you can see your SATA driver under /dev/
In jetpack5.0.2, when you tried initrd flash to flash this SATA, it failed because initrd cannot enumerate SATA drive.
Yes, they are
Could you boot into emmc case first and check/share below?
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.
I check the command you offered
The config of ahci driver is built as ko file exactly and is binded at 0004:01 where is the sata drive located
I have modified the ahci dirver to be build in
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?
What is your method to update your kernel image after you build it out?
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
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.
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:
initrdto 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_PLATFORM. It is easy to check (A) if the boot messages mention the “
uname” output and if this differs from what it was before.
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?
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.
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):
Thanks your help very much, we solved the issue by building those two drivers successfully
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.