sudo commands not working after TX1 compiling sources

Robotics & Edge Computing Jetson & Embedded Systems Jetson TX1
1

Hello,
I’m trying to output full-RGB trough the HDMI (which is only support limited RGB).
Therefore, I need to change the default_limited_cmu lut for TEGRA_DC_OUT_HDMI. This code is located in /kernel/drivers/video/tegra/dc/dc.c

I’m trying to compile the kernel sources, flowing the guide: http://developer.ridgerun.com/wiki/index.php?title=Compiling_Tegra_X1_source_code
I executed all the commands step by step, and before “make tegra21_defconfig” I edited the file dc.c which I mentioned above.

Before applybinaries (step 14), I copied the image and zImage into the rootfs/boot directory:

sudo cp $DEVDIR/images/zImage $DEVDIR/images/Image $DEVDIR/64_TX1/Linux_for_Tegra_64_tx1/rootfs/boot/

and then:

cd $DEVDIR/64_TX1/Linux_for_Tegra_64_tx1/
sudo ./apply_binaries.sh
sudo ./flash.sh jetson-tx1 mmcblk0p1

After the flash was “successfully” finished, the target was boot into login screen.
Then I was stuck in a login-loop.
I turned into console-terminal by pressing Ctrl+Alt+F2 for checking .Xauthority mode:

Ubuntu@tegra-ubuntu:~$ ls –la

-rw------- 1 root root 57 Mar 19 13:19 .Xauthority

Then tried to:

Ubuntu@tegra-ubuntu:~$ sudo chown ubuntu:ubuntu .Xauthority

And I got the error:
sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set
And I get it for every “sudo” command !!!
I tried to:

Ubuntu@tegra-ubuntu:~$ pkexec chown ubuntu:ubuntu .Xauthority

And I got the error:
pkexec must be setuid root

I also tried to flash with the Jetpack and got the same problem…

Any suggestions?
I probably missed something but I tried to repeat these steps for many times without any success.

2

sudo failures usually mean the file system the flash image was generated on was not a native Linux file system type, or that sudo was not used during critical steps of flashing. If you go to your “Linux_for_Tegra” directory and run “df -H -T .”, what type shows up? Is it something like ext3 or ext4 (it should be…VFAT or NTFS are incapable of success)?

Next, if you flashed on command line, did you unpack the sample rootfs using sudo? And did you run apply_binaries.sh with sudo?

3

Hi @linuxdev, thanks for your answer.
I’m using a native Linux FS, and I used sudo during apply_binaries and flash.sh. During the compilation I used sudo in some steps, soon I’ll post the exacts commands order I used.

The output of “df -H -T”:

ubuntu@ubuntu-ThinkCentre-M93p:~/JetpackL4T_2_3_1/64_TX1/Linux_for_Tegra_64_tx1$ df -H -T
Filesystem     Type      Size  Used Avail Use% Mounted on
udev           devtmpfs  4.2G  4.1k  4.2G   1% /dev
tmpfs          tmpfs     830M  1.5M  828M   1% /run
/dev/sda1      ext4      484G  119G  341G  26% /
none           tmpfs     4.1k     0  4.1k   0% /sys/fs/cgroup
none           tmpfs     5.3M     0  5.3M   0% /run/lock
none           tmpfs     4.2G  517k  4.2G   1% /run/shm
none           tmpfs     105M   54k  105M   1% /run/user

I have to say that I’m using this rootfs to reflash clean BSP & image (which were not compiled manually), and this process works perfect

** EDITED**
few more things I need to mention:

  1. I’m using Jetpack L4T 2.3.1 (BSP 24.2.1 tag-name) :
sudo ./source_sync.sh -k tegra-l4t-r24.2.1 -u tegra-l4t-r24.2.1
  1. In kernel configuration (executed by make menuconfig I set General setup → local version to: “-tegra”, and the created kernel version was set according to this setup: 3.10.96-tegra+, while the original kernel version is 3.10.96-tegra without the ‘+’. Is that OK?
    Should I configure something else in the menuconfige? (the local version was the only thing I set there)
  2. During the zImage compilation (make zImage) I got some warnings and notes like:
sound/soc/codecs/audience/es755.c: In function 'es755_hw_params':
sound/soc/codecs/audience/es755.c:1044:29: warning: passing argument 1 of 'escore_write_locked' from incompatible pointer type [-Wincompatible-pointer-types]
    rc = escore_write_locked(escore,
                             ^
In file included from sound/soc/codecs/audience/es755.h:16:0,
                 from sound/soc/codecs/audience/es755.c:13:
sound/soc/codecs/audience/escore.h:716:5: note: expected 'struct snd_soc_codec *' but argument is of type 'struct escore_priv *'
 int escore_write_locked(struct snd_soc_codec *codec, unsigned int reg,
     ^
sound/soc/codecs/audience/escore-cdev.c: In function 'datablock_ioctl':
sound/soc/codecs/audience/escore-cdev.c:1104:5: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
     (char *)datablock_copy.buf, buffer_size);
     ^
net/ipv6/ping.c: In function 'pingv6_init':
net/ipv6/ping.c:83:29: warning: assignment from incompatible pointer type [-Wincompatible-pointer-types]
  pingv6_ops.ipv6_recv_error = ipv6_recv_error;

Is that OK?

Am I need all of these steps (appear in the guide mentioned in my first message) just to change a single file (kernel/drivers/video/tegra/dc/dc.c)? Is there some steps I can skip?

4

Unfortunately I cannot use JetPack (I have a Fedora host) so information I have on JetPack usage is minimal.

In general the warnings you got from kernel build can be ignored unless there is a specific failure with the driver/code getting the warning (this is not the case for the warnings you posted, but watch for other warnings or failures).

Local version with “-tegra” should match the existing module location and should work if the kernel itself supports those modules (the starting configuration is always a question, but the local version was correct for most cases).

Note that flashing is completely unnecessary for changing the kernel. It’s ok to use JetPack as an aid to building, but beware JetPack does not even have to be involved. The final change is to copy the “Image” file to “/boot” of the Jetson (possibly with a name edit so it won’t overwrite the original…then an edit in “/boot/extlinux/extlinux.conf” to name the new kernel name).

All of my kernel builds are on command line using manually installed versions of Linaro tool chains. I do not know how JetPack gets a starting configuration, but whenever a Jetson arrives I archive a copy of “/proc/config.gz”. This is the best starting config. There are some default configs available as a target, but there is no guarantee this default config will actually work on your board. An example for the JTX1 is tegra21_defconfig. In the first releases this was an exact match for what appears in “/proc/config.gz”…but I think in R24.2.1 it differs and perhaps does not even boot correctly without minor changes. This could account for sudo not working.

Did you flash, or did you just change the kernel? What was your starting config on the kernel? Do you have the original Image file so you can see what “/proc/config.gz” it produces (files in “/proc” are not real files, they exist in RAM as a reflection of the current kernel)?

5

OK so I found the file tegra_t210ref_gnu_linux_defconfig and used it instead of tegra21_defconfig.
I had to change another source file - drivers/usb/phy/tegra-xotg.c in order to avoid error: logical not is only applied to the left hand side of comparison.
I flashed the board again, and now I see a black screen with mouse symbol, and even a “Network enabled” notification so a know something is going on. I turned into the console terminal by pressing Ctrl+Alt+F2, and saw NOTHING, but I pressed “ubuntu” “ubuntu” un order to login and then pressed “reboot”, and noticed that the board actually rebooted!!!
So i cannot see anything but something is working in the background.
Any suggestions??

This is the commands-order, step by step:

cd ~/JetpackL4T_2_3_1/64_TX1
export DEVDIR=~/JetpackL4T_2_3_1
sudo ./source_sync.sh -k tegra-l4t-r24.2.1 -u tegra-l4t-r24.2.1
mkdir -p $DEVDIR/images/modules 
mkdir -p $DEVDIR/images/packages 
mkdir -p $DEVDIR/images/build
export CROSS_COMPILE=/opt/linaro/gcc-linaro-5.3-2016.02-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-
export CROSS32CC=/opt/linaro/gcc-linaro-5.3-2016.02-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-gcc
export KERNEL_MODULES_OUT=$DEVDIR/images/modules
export TEGRA_KERNEL_OUT=$DEVDIR/images/build
export ARCH=arm64

cd $DEVDIR/64_TX1/Linux_for_Tegra_64_tx1/sources/kernel_source/
make O=$TEGRA_KERNEL_OUT mrproper
sudo gedit arch/arm64/kernel/vdso32/Makefile /* to avoid error: r7 cannot be used in asm here*/
sudo gedit drivers/platform/tegra/tegra21_clocks.c  /* to avoid error: logical not is only applied to the left hand side of comparison*/
sudo gedit drivers/usb/phy/tegra-xotg.c /* to avoid error: logical not is only applied to the left hand side of comparison */
sudo gedit drivers/video/tegra/dc/dc.c  /* to change the RGB format via HDMI*/

make O=$TEGRA_KERNEL_OUT tegra_t210ref_gnu_linux_defconfig
make O=$TEGRA_KERNEL_OUT menuconfig /* set local version to '-tegra' */
make O=$TEGRA_KERNEL_OUT zImage
make O=$TEGRA_KERNEL_OUT dtbs
make O=$TEGRA_KERNEL_OUT modules
make O=$TEGRA_KERNEL_OUT modules_install INSTALL_MOD_PATH=$KERNEL_MODULES_OUT
cp $TEGRA_KERNEL_OUT/arch/arm64/boot/Image $TEGRA_KERNEL_OUT/arch/arm64/boot/zImage $DEVDIR/images/
mkdir -p $DEVDIR/images/dtb
cp $TEGRA_KERNEL_OUT/arch/arm64/boot/dts/ *.dtb $DEVDIR/images/dtb/
cp $TEGRA_KERNEL_OUT/scripts/dtc/dtc $DEVDIR/images/dtc
mkdir -p $DEVDIR/images/packages-backup
cp -rf $DEVDIR/64_TX1/Linux_for_Tegra_64_tx1/kernel/ * $DEVDIR/images/packages-backup
cd $DEVDIR/images
sudo rm -rf $DEVDIR/64_TX1/Linux_for_Tegra_64_tx1/kernel/dtb
sudo cp -rf Image zImage dtb/ dtc $DEVDIR/64_TX1/Linux_for_Tegra_64_tx1/kernel/
sudo cp $DEVDIR/images/zImage $DEVDIR/images/Image $DEVDIR/64_TX1/Linux_for_Tegra_64_tx1/rootfs/boot/
cd $DEVDIR/64_TX1/Linux_for_Tegra_64_tx1/
sudo ./apply_binaries.sh 
-- recovery mode!! --
sudo ./flash.sh jetson-tx1 mmcblk0p1

** In lines 28 and 31 I replaced the ‘/*’ in the code snapshot by ‘/ *’ (with a space) in order to avoid the code to be seen like a comment

Am I missing something??

6

I’d say the system is working, but video was not configured (your kernel steps were likely correct). The monitor will remain black if the set video mode does not match something the monitor is capable of. The method by which auto configuration takes place is the DDC/EDID wire. Are you using HDMI cabling all the way through, or is an adapter involved? Older 15-pin D-sub adapters cut EDID wires and are not capable of auto configuration. What is the exact cable setup (including any adapters)?

You should find that ssh works now and that you can log in over the network. Can you test if this works? If so, then it is a lot easier to see what the exact issue is. If you can log in via ssh, then run this command and see what it says:

cat `find /sys -name 'edid'`
7

OK so I found out what the problem was - files PERMISSIONS!!
Before I started this process, first thing I did was to copy the original Linux_for_Tegra_64X folder as a backup and actually worked on this copy. This process changed the folder (and all sub-folders, including the kernel files!!) permissions and ownership
This was the cause for all the problems!
When I copied the folder with preserving all the relevant attributes- everything worked perfect!

8

In addition to making all backup copies as root with options to preserve permissions (such as cp -aPr) make sure the file system type on backups is a native Linux type (e.g., ext3, ext4, but NOT NTFS nor VFAT)…if the underlying file system does not understand the Linux permissions, then permissions will be modified and information lost.

9

Glad you solved it, I’ve run into that a few times myself when I wasn’t careful about how I updated the kernel. Usually I’d just delete it and re-download the rootfs. Always nice to go back to a clean slate sometimes.

You should accept your own answer :D

10

Thanks! :)