Hello to everyone.
I would like to install the Tango binary translation system : https://www.amanieusystems.com/
on my jetson nano. I think that it will be a nice added value to this board to be able to run the unmodified arm32 applications. Since I’m an amateur on the linux management,I would like to have some explanations to understand if and how I can do that. They say that it works mainly for Android,but it should work also in Linux,but not specifically for the tegra kernel nor for the jetson nano,but for the Amazon aws cloud system. Anyway I think that it could work with some tweaking. I would like to understand well what’s the procedure to follow for integrating the tango kernel patches inside the kernel that I’m using right now,that’s the OE4T 4.9.201+. It seems that the closest kernel to mine that’s indicated and for which have been included the patches is the 4.9.206 :
I’m not sure if I can apply those patches to the sources of my kernel version or if I should grab the sources of the version 206,but in this case,where are located ? Where can I get the kernel 4.9.206 sources which works for the jetson nano ? or maybe another supported kernel included in the list ? I’ve tried to install the precompiled kernel for AWS and it seems that they have been installed. Only minor errors are occurred :
I can’t answer, but some information you may find useful follows.
So far as I know there are no kernel sources which work with a Jetson other than the kernel releases which actually ship on the Jetson. There may not be many “critical” differences between the 4.9.140 kernel and the 4.9.206 kernel, at least not with stock kernels, but the actual “4.9.140-tegra” kernel probably has some NVIDIA patches in it.
If I were to undertake this, and if 4.9.206 is the closest kernel which allows the patches you want, then I would suppose that back porting 4.9.206 features to 4.9.140-tegra would be most likely to succeed. The trick is that you don’t know which parts of 4.9.206 you need for that patch to succeed. If you were to patch every difference, then you are just porting the reverse of turning 4.9.140-tegra into 4.9.206-tegra, so it defeats the purpose to port every change.
Along those lines you probably would want to see what each and every patch changes in 4.9.206, and then look at the code blocks in the 4.9.140 kernel and see if that particular code has changed from 4.9.140 to 4.9.206 (restated, see if the block of code, when not modified, is the same between 4.9.140 and 4.9.206…if it is, then you just apply the patch to 4.9.140-tegra, otherwise you first back port from 4.9.206 to make patchable code in 4.9.140-tegra…the patch guides you as to which block to examine).
Note that in your “minor errors” it wasn’t so minor. The install is trying to use GRUB, and there is no such thing as GRUB in the ARM embedded world. All changes which are being attempted to the bootloader need to be hand edited and tested with U-Boot and device tree edits. I don’t even know where to start with that, other than finding out if the modifications have the purpose of changing arguments passed to the Linux kernel at boot…if that is the case, then it is simple to add those arguments to the Linux kernel without using GRUB. However, mention of GRUB is worrisome, and may be an indicator that this software is perhaps intended to run in a container or chroot environment on a PC rather than on an actual arm64 device…don’t know, never used or researched your software.
I’m using OE4T 4.9.201+,not 4.9.140-tegra. I said that the 4.9.206 is the closest kernel to mine,that’s 4.9.201+. The other kernels versions suggested inside the integration package are numerically further away from mine. To see the differences I need to look inside the kernel 4.9.206,but I don’t know where to get it. Yes,I understand. The errors that I have defined “minor” could be relevant.
That you are using a different kernel is the whole point. If you take the kernel version closest to the 4.9.140-tegra kernel (presumably 4.9.206), and look at the blocks of code which your patch would modify, then you know which blocks to examine (there might be related function calls, but those blocks of code are the starting point. If the blocks of code are the same between 4.9.140-tegra and 4.9.206, and if the patches work on 4.9.206, then it implies those parts of the patch can be applied directly to the 4.9.140-tegra kernel. If the blocks where patches apply to 4.9.206 differ from 4.9.140-tegra, then you need to back port that part of the kernel first before patching 4.9.140-tegra.
- Find the relevant block of code changing in
4.9.206.
- Compare the block of code in
4.9.206 with 4.9.140-tegra.
- If the same, then ignore; if different, then back port.
- Apply the patch to
4.9.140-tegra.
- Configure the new
4.9.140-tegra to match what your running system would have been without the patch.
- Configure only the parts which are new and required with your changes.
- Change the
.config file’s “CONFIG_LOCALVERSION” to something new; originally it was CONFIG_LOCALVERSION="-tegra", so now it would be something like CONFIG_LOCALVERSION="-tegra-test".
- Compile, install the new
Image.
- Install new modules at “
/lib/modules/4.9.140-tegra-test/” (because CONFIG_LOCALVERSION changed “uname -r” will also change, and modules are found at “/lib/modules/$(uname -r)/”.
You will have a lot of trial and error because:
- Sometimes a modified block of code will extend to functions called or being called.
- Perhaps the patch is applied to a feature which does not even exist in
4.9.140-tegra, and the entire feature will need porting (including Kconfig to name the feature).
Note: While testing I suggest leaving the original Image and modules in place, and adding the Image-4.9.140-tegra-test as a new file name with a new extlinux.conf entry added, with boot requiring selection of the new kernel via serial console. If it fails, then you just boot to the non-modified entry.
I’ve sent an email to the author of the Tango tool. He said that I can apply the patches without problems. BUT,he also said that the jetson nano already supports the 32 bits natively. Tango is useful for the cpus that don’t support arm32. He knows for sure that’s like this. BTW,I see that there are applications that don’t work at all with the 32 bits libraries of the jetsons. For example teamviewer and any desk. These applications have been written with the raspberry in mind. I think that the 32 bits of the raspberry is not the same as the 32 bits of the jetsons.
The above is true for the hardware. However, one would also need to install the linker and libraries for this to be true in user space. Not a problem for content within the kernel itself if the kernel code understands how to work with the switch between 32-bit mode and 64-bit mode. As you mentioned, Jetsons don’t work with the 32-bit libraries, and the reason is the lack of the 32-bit linker environment. One could either (A) install linker and libraries manually (a very big project which probably is more difficult than it sounds), or (B) go with some sort of VM or container setup (probably not simple, but likely simpler than adding a true 32-bit compatibility).
I don’t know where to say to go from there other than “a lot of trial and error”.
Would be useful to find an armhf 32 bit container which works on top of the jetsons nano. I’ve tried to give a look all around,but I found nothing.
