TX1 -- swapon failed: Function not implemented

please take this change locally. the same is already fixed in r28.2

diff --git a/arch/arm64/configs/tegra21_defconfig b/arch/arm64/configs/tegra21_defconfig
index 421aefe…d9dcae6 100644
— a/arch/arm64/configs/tegra21_defconfig
+++ b/arch/arm64/configs/tegra21_defconfig
@@ -1,6 +1,5 @@
CONFIG_ARCH_TEGRA_210_SOC=y

CONFIG_LOCALVERSION_AUTO is not set

-# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
CONFIG_FHANDLE=y
CONFIG_AUDIT=y

EDIT: OK, I see you have a new release candidate for JetPack 3.2 which apparently supports swap again.

Well at least 3.2 finally supports installing from Ubuntu 16.04, however it looks like the installer only supports the TX2?

Please repeat more clearly, I have no idea what you’re saying here.

I’m also wondering why this disappeared, in a prior release I enabled swap to (for example) just compile Dusty’s Jetson reinforcement example project. Without swap it won’t compile, and personally I’d rather not mess with compiling my own kernel since it should have been done already as it was before.

That is a “diff” to explain what has changed in kernel “arch/arm64/configs/tegra21_defconfig” in R28.1 versus R28.2 pre-release. It’s actually incomplete, but lines without a leading +/- are generally “context” lines to see what is around the patch, a “-” is a line removed, a “+” is a line added. You’ll see the comment on CONFIG_SWAP not being enabled is removed (the leading “-”)…it should then have this following it (which is missing from the diff):

+CONFIG_SWAP=y

It’s just a long way to say this has been added in the next release.

A kernel compile is mandatory to add the feature…there is no way around it (the feature is there, it’s just that it has to be enabled). This is admittedly a feature which is probably important to enough people to justify enabling it by default since it can’t be added from a simple module. This is no different than a Windows update which requires a reboot…it’s just that it is manual instead of automated over the internet.

The .config file used in a kernel compile (or reflected in a running system as “/proc/config.gz”) has many options which won’t be used in many circumstances. There is a set of basic requirements to boot a system, and then it is normally up to individuals to customize as desired for their circumstance. A desktop PC will often enable many options which will never be used, but the extra space on a desktop PC is not important compared to an embedded system…you will never see an embedded system with limited resources enabling everything…it is a reference configuration intended to be adjusted by end users (that’s the nature of Linux, it isn’t just for Jetsons).

This is only historic trivia, but all of this started in the world of 32-bit ARMv7 (or even before this). ARMv7 has a much more limited address range available in its direct branch assembler instruction (32MB), and modules and initrd content must remain within that distance in memory below the start of the kernel (it is a physical address requirement). If you were to add a combination of kernel modules and initrd in such a way that the size puts any upacked content more than 32MB below the kernel physical address on ARMv7 you would have an undetermined system failure when that module or initrd content tries to branch back to the kernel (a driver would result in unreachable code in kernel space…a very bad thing). It is quite easy to exceed this limit for 32-bit ARM, whereas the limit is extreme and trivial on an x86_64 PC.

Since 64-bit ARMv8-a derived from 32-bit ARM (this is what 64-bit ARM developers adapted/evolved code from) there is some inheritance of the caution about too much going into initrd and/or kernel modules. The limit has gone up (I think the ARMv8-a direct branch instruction can handle 128MB now), but you can still add too many modules in ARMv8-a…128MB is plausibly not easy to hit with total module size, but it also is not implausible this would happen if you just go around building everything as a module or adding a lot of features by module which are not needed. It is better to let the embedded system implementor decide what additions are needed.

Swap does also cause a larger kernel. Earlier less powerful ARM systems did not have much RAM…we might be talking in the neighborhood of 32MB or 128MB…not GB. Those systems which the Linux ARM config derived from would be harmed from enabling swap when it won’t be used anyway.

I agree swap is something which is worthy of having on by default since a Jetson can actually use this feature in common usage, but it is heritage and old baggage as to why it isn’t there.

Yes I know about diff’s :) just not whether he was expecting us to do the compile or what - anyhow caught it above but thanks for your writeup, interesting bit of the history I didn’t know about (Linux user since the first year of release).

The question then is when we can approximately expect the release (is RC2 the final?) and are they really obsoleting the TX1?

Great explanation linuxdev. I really appreciate you spending the time to share your knowledge and give background here.

Is checking “Support for paging of anonymous memory (swap)” the only changes we need in the configuration?
I am following the instructions in the repo: https://github.com/jetsonhacks/buildJetsonTX1Kernel

To add swap, yes…that’s the only change required. There are many additions other people might want, but to enable swap this is the only required change (just remember this changes the base Image file since it cannot be built as a module, and if “uname -r” changes…see CONFIG_LOCALVERSION…then you’ll also need to build modules to match the new Image).

Hello,

can someone provide please a comprehensive and simple instruction how to re-build the 28.1 kernel with the swap enabled? I have downloaded the sources of the latest stable kernel, but the Nvidia kernel rebuilding documentation is extremely confusing.

I would really appreciate it, thanks. Wondering WHY Nvidia has disabled the swapping…

To build natively on the TX1 (FYI, TX1 and TX2 both use R28.1…different starting configs though…extracting the current running system’s “/proc/config.gz” is the best start config):
[url]AWS Greengrass Core on Nvidia Jetson TX2 Requirements - Jetson TX2 - NVIDIA Developer Forums

Thanks, but I found meanwhile a much easier way - http://www.jetsonhacks.com/2017/08/07/build-kernel-ttyacm-module-nvidia-jetson-tx1/ . Jetsonhacks again provides service that is missing from Nvidia.

The NVIDIA-provided guide to building the L4T kernel is included in the L4T documentation:

[url]https://developer.nvidia.com/embedded/dlc/l4t-documentation-28-1[/url]

See the “Kernel Customization” section.

Thanks, but there is no such section. Only “Building the NVIDIA Kernel”, which is way too complicated for many users (including myself). Jetsonhacks provides a simple and clear instruction how to do it without cross compilation, directly on Jetson, with very little efforts. You should really ally with these guys to make your products and services better ;).

Building the NVIDIA Kernel is a subsection under Kernel Customization, which includes steps other than just building like obtaining the sources and toolchains, ect:

External Media

The L4T procedure includes cross-compiling, as this is typical for kernel developers to save time (also can be done from JetPack machine).
Nothing is preventing one from building it onboard the Jetson if they don’t mind the wait, as JetsonHacks and others have posted.
As noted previously in the thread, the swap config will also be enabled in the R28.2 TX1 release of the L4T kernel.

We’ve worked with JetsonHacks since TK1. Since Jetson is an embedded Linux platform, there’s some degree of general Linux background helpful. We work actively within the community to help promote hands-on guides, tutorials, and additional docs for users who may not have that experience yet. Jetson is atypical of high-end ARM SoCs in that it’s an open platform, including thousands of pages of official docs and kernel sources freely available. Having an active community helping with the forums, blogs, and wiki is a healthy part of that. NVIDIA has a dedicated team for support here too.

How to build the kernel correctly on TX1 ?
@alexander1jklh @Kangalow @jetboyYerong

I want to create the custom kernel must be used with swap enabled and
I follow the step from the vedio released from : Build Kernel and ttyACM Module - NVIDIA Jetson TX1 - JetsonHacks

but I always get the same kernel version (4.4.38-tegra) after I reboot the TX1 (type the "uname -r ")

My environment is
TX1
L4T 28.1.0
Board: t210ref
Ubuntu 16.04 LTS
Kernel Version: 4.4.38-tegra
( I haved Install SSD on it and followed by Install Samsung SSD on NVIDIA Jetson TX1 - JetsonHacks)

I has change the local version, choosed the Support for paging of anonymous memory (swap) and
saved it finally !
I also ran the makeKernel.sh (terminal got the DEPMOD 4.4.38-jetsonbot-v0.1) and copyImage.sh !
(I have found the free space change when I getkernelsource and remove files in /usr/src)
why I always get the same kernel version after reboot ?

can you show me the step or some suggestions?
Thanks for help !

Kernel version is determined by a few text strings concatenated together…if those don’t change, then the “uname -r” does not change.

The first component is the source code version of the kernel itself. Currently “4.4.38”. This is the prefix of “uname -r”.

The second component is the CONFIG_LOCALVERSION in the “.config” file used during kernel compile. If this is “-tegra”, then “uname -r” would become “4.4.38-tegra”.

Sometimes the source code will have something to append…a “+”. The source code from source_sync.sh will append this, other sources will not. If you used source code from source_sync.sh, then this would become “4.4.38-tegra+”.

Not having version change is correct if those settings all matched. This is often desired because it determines where kernel modules are searched for…if it changes, then you have to install all of the kernel modules. If this matches, then only the Image needs to change.

Sometimes kernels use a CONFIG_LOCALVERSION named after a git repository identifier. This is not the case for the default kernel under recent releases (thus “-tegra” instead).

The configuration at the time of build is reflected in file “/proc/config.gz”. To see if CONFIG_SWAP is enabled (and it might now be enabled even though version appears the same) run this command on the booted system:

zcat /proc/config.gz | grep CONFIG_SWAP

If you want to just explore configuration:

zcat /proc/config.gz | less

If the feature you expect to be added is not there then it may be the copy of Image did not occur…perhaps due to an error in the build the new Image isn’t there…so there could be no copy.

Do keep in mind that if you are experimenting with kernel compiles having a serial console cable is highly desired…then you can pick among multiple boot entries without removing or replacing a known good boot configuration. Replacing a kernel as the default without testing first can be risky since failure implies a complicated life getting the original system back without flashing. See:
http://www.jetsonhacks.com/2015/12/01/serial-console-nvidia-jetson-tx1/

@shuyu0815

From the article:

Note: The copyImage.sh script copies the Image file to the /boot directory of the current device. If you are using an external device such as a SSD as your root directory and still using the eMMC to boot from, you will need to copy the Image file to the /boot directory of the eMMC, and modify /boot/extlinux/extlinux.conf accordingly.

This means that the Image file was built on the SSD. The Jetson boots from the eMMC. You will need to copy the Image file to the /boot directory of the eMMC, and modify /boot/extlinux/extlinux.conf on the eMMC for the changes to take effect.