Kernel susceptible to erratum , when building real time kernel ( Kernel version 5.10.120.rt70-tegra )

I am getting one error/warning "arch/arm64/Makefile:25: ld does not support --fix-cortex-a53-843419; kernel may be susceptible to erratum ", when trying to build real time kernel as per the steps provided in this link.

Kindly let us know how it can be fixed.
see the build log as shown below:

root@trident-B660M-AORUS-PRO-AX-DDR4:/home/trident/Downloads/r35_4_1/Linux_for_Tegra/source/public/kernel/kernel-5.10# make ARCH=arm64 O=$TEGRA_KERNEL_OUT modules_install INSTALL_MOD_PATH=/home/trident/Downloads/r35_4_1/Jetson_Linux_R35.4.1_aarch64/Linux_for_Tegra/rootfs
make[1]: Entering directory ‘/home/trident/Downloads/r35_4_1/Linux_for_Tegra/source/public/build_20Dec’
arch/arm64/Makefile:25: ld does not support --fix-cortex-a53-843419; kernel may be susceptible to erratum
INSTALL arch/arm64/crypto/aes-arm64.ko
INSTALL arch/arm64/crypto/aes-ce-blk.ko
INSTALL arch/arm64/crypto/aes-ce-ccm.ko
INSTALL arch/arm64/crypto/aes-ce-cipher.ko
INSTALL arch/arm64/crypto/aes-neon-blk.ko
INSTALL arch/arm64/crypto/ghash-ce.ko
INSTALL arch/arm64/crypto/sha1-ce.ko
INSTALL arch/arm64/crypto/sha2-ce.ko
INSTALL arch/arm64/crypto/sha256-arm64.ko

I feel like it’s because you are not using the right version of cross-compilation toolchain.
It’s Bootlin GCC 9.3:

Thanks. Please point me the steps where I can install these bootlin GC on my host PC and can rebuild the real time kernel successfully.

Download and extract the archive, and set the environment variable CROSS_COMPILE_AARCH64.
You can place it wherever you like.
I think it’s stated very clearly in the guide.

1 Like


On similar lines I have one more query regarding the optional step [archive the installed kernel modules in the below link ]

Kernel Customization — Jetson Linux Developer Guide documentation (

I want to archive this kernel supplements.tbz2 and place it on my target as I need to do third party driver kernel module build on my target and this is required. Here can I know what does the ‘modules_install_path’ in the below command ‘‘cd <modules_install_path>’’ mean. which is the folder they are speaking here?

Also want to know if the tar command in this step will archive even the folders pointed by the softlinks also, as I will get broken links on my target after flashing for the folders: /lib/modules/<kernel_version>/ build and /lib/modules/<kernel_version>/ source .

Please clarify.

That means your Linux_for_Tegra/rootfs.

You are right; the soft link will be broken, so if you need to do driver development, it’s recommended to build the kernel on the device itself.

ok. Thanks for the info.

You mean we need to download the source from Nvidia website on the target directly and do the complete build process steps on the target itself?

If that is the case, how do flash command that we were executing from the host pc work?

how to use the flash command on the target itself?

I thought this tar command and taking kernel supplements zip file was used to solve this broken link issue on the target PC. I also read that if we use -h option for the tar command then this zip all the files for the symbolic linked ones also so that we can extract these on the target so that broken links are resolved and we dont have any build issue of third party drivers on the target.
Pls clarify. Thanks.


You already have a running Jetson system, so there is no need to flash it again.
You just boot it from the new kernel as I said here:

Could you please let us know your thoughts on using this tar command to compress the /lib/modules/ files and copy them to target and fix the broken links, so that we can build the third party drivers ( example, my frame grabber camlink driver source ) with out any issues.

WIll this work out for us.

Please just build kernel on the Jetson device itself to avoid broken links.

1 Like

I will try to flash generic kernel version( with out RT ) on my target first, as this one does not have broken link issues as per my current study and understanding.
If I can successfully build my camlink driver on the target with generic kernel version, then there is no need for me to build kernel on my target.

If non RT kernel version also fails to build my third part driver file, then will try RT kernel build on target and try my luck! THanks.

what should be the environment variable TEGRA_KERNEL_OUT should be pointing to in the below command;

Should we use export command each time we execute this command? pls let us know.

Install the kernel modules:

$ cd <path_to_kernel_source>
$ sudo make ARCH=arm64 O=$TEGRA_KERNEL_OUT modules_install INSTALL_MOD_PATH=/Linux_for_Tegra/rootfs/

It’s the kernel_out folder mentioned in Step 3.

You can also hard-code the folder path.

Where to hardcode this path?

As I.will be creating my own new kernel out directory for each new build, the folder name will be changing…

Then just export the folder name each time…

1 Like

I have few questions regarding building kernel on the Jetson device itself:

  1. I have my other interface like CAN, GPIO, Audio etc changes done through device configuration, pin muxing etc on host PC. If I flash these changes on to my target then the kernel build done for CAMLink third part driver compilation will get erased.

How to resolve this conflict?

  1. If I can do kernel build on my target itself all the time, then I can do the changes for enabling my other interfaces like CAN, Audio etc on the target itself. What is the need of Host PC then?

  2. After every thing is working, i need to flash the working image/modules etc on many boards. How to go about this ?

Please let me know. Thanks.

In case my build folder is same all the time, then in which file should we hardcode the path?

  1. I don’t know what you mean with conflict.
  2. No one says it’s needed…
  3. You need massflash.
  4. I don’t know what you are talking about. I’m just saying you can directly write out the path to where stuff gets built, instead of specifying the TEGRA_KERNEL_OUT variable.

I meant some changes I have done on my host PC like modifying device tree files. pin muxing etc and later flashing to the target. But some third party drivers build I need to do it on the target always, as CROSS COMPILATION might not work, it may throw errors. In that case, the image on the target will be erased during flashing and my third driver compilation data on target will be lost.
Any work around for this?

If I do everything on my target, then how to flash the final working image/dtb etc from my target board to other new boards?

Ok fine. So I need to replace the built DTB/ image file with the image and DTB file under /boot/ directory and reboot the target right?

Please point me to the documentation where we can do this. My module is Jetson AGX Xavier Industrial.

ok fine. Got it.

Gonna answer it in the third question.

YES. Maybe also kernel modules if you are working with external drivers.

Refer to the README file in /Linux_for_Tegra/tools/backup-restore/.

1 Like