Unable to build the kernel on Tx1

I do own a Jetson-TX1 dev kit.
I have added a SD card to be able to do some development on the board, and data disks.
I wanted to add swap to compile some software like tensorflow.
I did copy the preinstalled Emmc to the SD card as specified in Jetsonhack web site (https://www.jetsonhacks.com/2017/01/26/run-jetson-tx1-sd-card/).
This leads to a functional boot on the SD card, and mount of the data.

I did tried to compile the kernel by different variants from (https://www.jetsonhacks.com/2018/04/21/build-kernel-and-modules-nvidia-jetson-tx1/), to compiling the kernel with a manually loaded kernel L4T-TX1-28.2.
But no success in passing the kernel boot and having a shell…

I was really disappointed after downloading the sources from https://developer.nvidia.com/embedded/downloads#?tx=$product,jetson_tx1 as the source included some trivial errors surely due to a quick deliver/merge without test.
file include/linux/irqchip/arm-gic.h is incorrect and needs to be modified in order to void including some C in an ASM compile.

I tried the “make defconfig”, the “cat /proc/config > .config”, to plenty of variants.
I had diverse reaction from not loading at all to having a kernel oops.

Is there currently a source reference that enable a proper kernel compilation ?
Thanks for any help.

Regards.

Yes, the steps are just inside L4T document on download center.
Please do check those documents on download center first. We don’t officially maintain jetsonhacks website.

Thanks for your answer.

Are you speaking of files in public_release/kernel/kernel-4.4/Documentation of tx1_sources.tbz2 ?

Is there more than :
cd public_release/kernel/kernel-4.4
make defconfig
or make tegra21_defconfig
make install
?

Note: I do have this at the end :
arch/arm64/boot/Image System.map “/boot”
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 4.4.38 /boot/vmlinuz-4.4.38
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 4.4.38 /boot/vmlinuz-4.4.38
update-initramfs: Generating /boot/initrd.img-4.4.38
cryptsetup: WARNING: failed to detect canonical device of /dev/root
cryptsetup: WARNING: could not determine root device from /etc/fstab
Warning: /sbin/fsck.rootfs doesn’t exist, can’t install to initramfs, ignoring.
run-parts: executing /etc/kernel/postinst.d/pm-utils 4.4.38 /boot/vmlinuz-4.4.38
run-parts: executing /etc/kernel/postinst.d/unattended-upgrades 4.4.38 /boot/vmlinuz-4.4.38
run-parts: executing /etc/kernel/postinst.d/update-notifier 4.4.38 /boot/vmlinuz-4.4.38

The boot with make tegra21_defconfig ends with:

[ 7.377823] tegra-i2c 7000c000.i2c: unexpected rx data request
[ 7.579012] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 7.613694] tegra-pcie 1003000.pcie-controller: link 0 down, retrying
[ 7.698906] Bad mode in Synchronous Abort handler detected, code 0x86000005 – IABT (current EL)
[ 7.708958] Internal error: Oops - bad mode: 0 [#1] PREEMPT SMP
[ 7.715557] Modules linked in:
[ 7.719289] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.4.38 #1
[ 7.725899] Hardware name: jetson_tx1 (DT)
[ 7.730689] task: ffffffc0fb33a580 ti: ffffffc0fb348000 task.ti: ffffffc0fb348000
[ 7.739629] PC is at 0x0
[ 7.742918] LR is at 0x0
[ 7.746198] pc : [<0000000000000000>] lr : [<0000000000000000>] pstate: 600000c5
[ 7.755215] sp : ffffffc0fb34bea0
[ 7.759390] x29: ffffffc00140e640 x28: 0000000000000006
[ 7.765624] x27: ffffffc07d847a00 x26: 00000001c4c460f2
[ 7.771870] x25: 0000000000000000 x24: 0000000000000000
[ 7.778107] x23: 0000000000000000 x22: ffffffc00140e640
[ 7.784327] x21: ffffffc0012b9b40 x20: 00000001bf14ada5
[ 7.790535] x19: ffffffc0014a9508 x18: 0000000000000000
[ 7.796723] x17: 0000000000000000 x16: 0000000000000000
[ 7.802909] x15: 0000000000000000 [ 7.802928] swapper/1[0]: undefined instruction: pc=ffffffc0ffe57680
[ 7.802931] Code: 00000000 00000000 00000000 00000000 (19291929)

[ 7.821156] x14: 0000000000000000
[ 7.826409] x13: 0000000034d5d91d x12: 0000000001000000
[ 7.832558] x11: 0000000000000000 x10: 0000000000001000
[ 7.838679] x9 : ffffffc000083000 x8 : 00000034b5193519
[ 7.844783] x7 : 0000000000000019 x6 : 0000000000300000
[ 7.850873] x5 : 0000bbff440c0400 x4 : 0000000000000000
[ 7.856935] x3 : ffffffc000091fd0 x2 : 0000000000000000
[ 7.862972] x1 : ffffffc000090bac x0 : 0000000000000000
[ 7.868970]
[ 7.871109] Process swapper/3 (pid: 0, stack limit = 0xffffffc0fb348020)
[ 7.878525] Call trace:
[ 7.881664] [< (null)>] (null)
[ 7.887040] Internal error: Oops - undefined instruction: 0 [#2] PREEMPT SMP
[ 7.887276] —[ end trace 400803b82fcb6cb2 ]—
[ 7.888406] Kernel panic - not syncing: Fatal exception in interrupt
[ 7.888415] CPU0: stopping
[ 7.888420] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G D 4.4.38 #1
[ 7.888421] Hardware name: jetson_tx1 (DT)
[ 7.888422] Call trace:
[ 7.888429] [] dump_backtrace+0x0/0xe8
[ 7.888432] [] show_stack+0x14/0x20
[ 7.888437] [] dump_stack+0xb4/0xec
[ 7.888440] [] handle_IPI+0x170/0x330
[ 7.888442] [] gic_handle_irq+0x98/0xc8
[ 7.888444] [] el1_irq+0x84/0x100
[ 7.888449] [] cpuidle_enter+0x18/0x20
[ 7.888452] [] call_cpuidle+0x4c/0x58
[ 7.888454] [] cpu_startup_entry+0x2c8/0x388
[ 7.888459] [] rest_init+0x88/0x98
[ 7.888464] [] start_kernel+0x39c/0x3b0
[ 7.888466] [<0000000080b6c000>] 0x80b6c000
[ 7.888468] CPU2: stopping
[ 7.888471] CPU: 2 PID: 0 Comm: swapper/2 Tainted: G D 4.4.38 #1
[ 7.888472] Hardware name: jetson_tx1 (DT)
[ 7.888473] Call trace:
[ 7.888478] [] dump_backtrace+0x0/0xe8
[ 7.888481] [] show_stack+0x14/0x20
[ 7.888483] [] dump_stack+0xb4/0xec
[ 7.888486] [] handle_IPI+0x170/0x330
[ 7.888488] [] gic_handle_irq+0x98/0xc8
[ 7.888490] [] el1_irq+0x84/0x100
[ 7.888492] [] cpuidle_enter+0x18/0x20
[ 7.888495] [] call_cpuidle+0x4c/0x58
[ 7.888497] [] cpu_startup_entry+0x2c8/0x388
[ 7.888499] [] secondary_start_kernel+0x15c/0x168
[ 7.888501] [<000000008008125c>] 0x8008125c
[ 8.080694] Modules linked in:
[ 8.084362] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G D 4.4.38 #1
[ 8.092141] Hardware name: jetson_tx1 (DT)
[ 8.096881] task: ffffffc0fb338c80 ti: ffffffc0fb340000 task.ti: ffffffc0fb340000
[ 8.105727] PC is at 0xffffffc0ffe57680
[ 8.110265] LR is at 0xffffffc0ffe57680
[ 8.114785] pc : [] lr : [] pstate: 600000c5
[ 8.123609] sp : ffffffc0fb343ea0
[ 8.127648] x29: 0000000000000000 x28: ffffffc0fb338c80
[ 8.133712] x27: ffffffc0ffe57680 x26: ffffffc000b76850
[ 8.139761] x25: ffffffc000b76000 x24: ffffffc000b67160
[ 8.145801] x23: ffffffc0fb343ee0 x22: ffffffc00140e640
[ 8.151828] x21: 0000000000000001 x20: ffffffc0fb3391f0
[ 8.157857] x19: ffffffc000b67588 x18: 0000000000000000
[ 8.163902] x17: 0000000000000000 x16: 0000000000000000
[ 8.169944] x15: 0000000000000000 x14: 0000000000000000
[ 8.175970] x13: 0000000034d5d91d x12: 0000000001000000
[ 8.181987] x11: 0000000000000000 x10: 0000000000001000
[ 8.187997] x9 : ffffffc000083000 x8 : 00000034b5193519
[ 8.194006] x7 : 0000000000000019 x6 : 0000000000300000
[ 8.200015] x5 : 0000bbff440c0400 x4 : 0000000000000000
[ 8.206012] x3 : ffffffc000091fd0 x2 : 0000000000000000
[ 8.211992] x1 : ffffffc000090bac x0 : 0000000000000000
[ 8.217952]
[ 8.220043] Process swapper/1 (pid: 0, stack limit = 0xffffffc0fb340020)
[ 8.227379] Call trace:
[ 8.230431] [] 0xffffffc0ffe57680
[ 8.235955] —[ end trace 400803b82fcb6cb3 ]—
[ 8.939938] SMP: failed to stop secondary CPUs
[ 8.950520] Rebooting in 30 seconds…

Some of the kernel and device tree install steps differ in R28.2 versus earlier releases. Be sure the install steps themselves don’t cause problems. Check the docs closely on install because extlinux.conf and file locations are no longer what they used to be.

Because you flashed R28.2 your host would have the “Linux_for_Tegra/” directory, and within that “source_sync.sh”. I suggest getting the R28.2 kernel source via:

./source_sync.sh -k tegra-l4t-r28.2

I also suggest not using the defconfig, but instead on an unmodified running system save a copy of “/proc/config.gz” somewhere safe, and then a copy of that renamed as “.config” in the top level kernel build directory as a starting point. Add swap via something like “make nconfig” (which might require “sudo apt-get install ncurses5-dev”). Don’t forget to update CONFIG_LOCALVERSION (you will want something new and to rebuild all modules since swap is an invasive integrated feature).

You said :
“Some of the kernel and device tree install steps differ in R28.2 versus earlier releases. Be sure the install steps themselves don’t cause problems. Check the docs closely on install because extlinux.conf and file locations are no longer what they used to be.”

Could you be more precise. There is plenty of documentation, but I did not find something like documentation on “extlinux.conf and file locations”…

You said :
“Because you flashed R28.2 your host would have the “Linux_for_Tegra/” directory,”

My “host” is also my target. I did unpack some of the R28.2 tbz2, but I did not find any “source_sync.sh” files.
Are you sure that the script is in the R28.2 delivery?

You said :
“I also suggest not using the defconfig” …

Yes, I did that too using make menuconfig instead of nconfig, but I get an inspirational kernel too…

For info: I am used to build kernel, for other systems.

Note: The only thing I did not do in all the process is to “Flashing the Boot Loader and Kernel” as the boot loader is already flashed, and I already boot on the SD card.
Does the boot loader depends on the kernel used ? Is there a dependency here ?

The documentation I read is the “L4T Documentation 24.1 (2016/05/16)” (Is it consistent with the L4T TX1 Sources 28.2?)

Note: Manipulating the https://developer.nvidia.com/embedded/downloads, I suddenly realized that 28.2 Kernel source is not proposed for TX1 board.

Is it an IHM error, or did I miss download the kernel ?

I actually use R28.2 on a TX1 (which isn’t supported). However, if you mix the kernel from a different version with that of which is actually installed, then this would probably cause problems. I haven’t looked at that TX1 in quite some time though, so I can’t tell you what issues I might have run into (the compiler might be wrong for an R28.2 kernel on an R28.1 system). I never built a kernel on the R28.2 version, so there may be issues.

However, if you go here (you probably have to log in and then hit the link a second time…URL redirect won’t work correctly), then you will find R28.1 is that last officially supported release on a TX1:
https://developer.nvidia.com/embedded/linux-tegra-archive

FYI, updating the kernel and device tree in R28.1 was a simple file copy and edit of the extlinux.conf config. Any update in R28.2+ requires using flash software (R28.2+ directions are drastically different). This is for two reasons: First, the content has been moved to a partition since early boot stages need this, and those stages cannot read an ext4 file system; second, because a signing mechanism has been put in place and improperly signed content is rejected. None of this has any effect on kernel build, but if you tried a kernel and it failed and you did not know about the newer install directions, then it is guaranteed to fail.

The reason for mentioning host is that the software to flash from host has “source_sync.sh” available to download the kernel. This script can be copied to the Jetson and it will work fine. If you want the R28.1 kernel instead:

./source_sync.sh -k tegra-l4t-r28.1

Because of the newer instructions I strongly suggest before you flash kernel or device tree that you clone. This is also something which changed drastically at R28.2, so you would have to clone using the right release driver package (which reads the Jetson in recovery mode for a clone, versus writing for a flash). Normally the “-r” option to flash.sh says to “reuse” the rootfs, and in some cases this means the rootfs is not rebuilt, but is still flashed…in other cases it means the rootfs is not even flashed. It is the latter to hope for, but clone in case of the rootfs being replaced…if the clone is in place, then any flash just puts the original content back in and it is the same as nothing happening to rootfs.

I will try R28.1. Thanks.

You said that the script flash.sh does change root fs and partition for R28.2.
I currently don’t want to touch the EMMC, and I have a SD card in the TX1.
If I do use the flash.sh, will it write onto the Emmc, or the SD card ? Will I have the choice ?

Note: This is one of the reason why I did not use this tool…

Sorry, what gets touched is complicated, so my answer is long. :( The short answer is everything gets touched unless you specifically replace only some small subset of the device…and it is risky to make a guarantee if you have not tested the specific change once. An embedded system does not have a BIOS like a PC does, and thus with no standard motherboard interface it is up to software in several partitions to make up for this.

There are many partitions on eMMC. Except for rootfs, all of those other eMMC partitions are used during the boot process (this is true whether or not the rootfs is on SD card or eMMC…these other partitions never live outside of the eMMC and never matter except during boot). Typically content of those other partitions must be compatible with the rootfs version (the rootfs has certain expectations for hardware setup on start and those other partitions create that state). There are some exceptions (not many) where the rootfs will work fine if the “./apply_binaries.sh” step from the mismatched driver package release version is applied to an untested “mostly compatible” rootfs. The rootfs and driver package are usually paired with matching release versions. You can think of “other partitions” as driver package, and “rootfs” as usual root partition and o/s.

If you flash R28.2 (the driver package), even with a mismatched R28.1 version rootfs, then the eMMC will get the R28.2 partitions (other than rootfs). If you flash R28.1 (the driver package), even with a mismatched R28.2 version rootfs, then the other partitions will be R28.1. Other partitions follow the driver package release, rootfs follows the sample rootfs release (with the driver package apply_binaries.sh overlaid on top). If the two are truly compatible, then you get boot.

In case this is confusing (and probably the way I worded it makes it more confusing), consider that a sample rootfs is pure Ubuntu. JetPack just runs the driver package (flash.sh) with the sample rootfs being nothing but binary data so far as the driver package is concerned. As apply_binaries.sh runs (before flash.sh) the NVIDIA-specific direct hardware access libraries get copied over to the purely Ubuntu rootfs (apply_binaries.sh adds content to what the driver package thinks of as binary data prior to copying the data to the rootfs partition of the eMMC). When Ubuntu gets these NVIDIA-specific hardware drivers on top of it, then Ubuntu can be referred to as “L4T” (“Linux for Tegra”) instead of just “Ubuntu”. It is still Ubuntu other than drivers for talking to the specific hardware. This is what the rootfs “image” is. The rootfs image is only used after U-Boot and earlier boot stages have dealt with all of those other partitions. Regardless of whether rootfs is on one device or another those other partitions will always be on eMMC.