L4T 24.1 and ROS

Big problem trying to get ROS running on 24.1. A lot of the packages required don’t have arm64 builds on the 14.04 trusty version of Ubuntu. They start at Wily and that is a 4.2 kernel. I tried a source install as well but the same problem occurs with all the depends it tries to download. 24.1 being a 64 32 bit userspace should be able to run the armhf version of ROS. So I added that arch and tried to install that way. No luck either. Now I set up my intel linux machine which is on Wily with arm64 multiarch. Mounting the rootfs directory in the Linux for Tegra package and I’m going to try to use apt-get install package:arm64 to put those packages on the rootfs prior to flashing to the TX1. Going to try to install the cuda and zed 32 bit libs along with ROS. Not too worried if the cuda or zed stuff doesn’t work that will be fixed soon enough but not so sure about ROS. Hope it works otherwise ROS users are going to be stuck on 23.2. Not sure if there is any plans to backport those packages or not. When the final version of 24.2 comes out is it going to be a 3.10 kernel? Does anyone know if they usually backport packages to older distros? Any idea of the timeframe? Is there a mechanism to request backports?

Dan

several things did not work for me on 24.1 so i returned to 23.2. i was not aware of it till today but 24.1 has been available since feb via an early access beta so i could have learned about these issues then. it will take some time for stuff to catch up to 24.1. you need to be a trailblazer to work with 24.1 right now. :) .

Actually its not that bad and from what I can see stable right now. I’ve made lots of progress getting ROS built. Into cmake stuff now. Similar to the errors I saw getting the Zed stuff to work on the TX1. I have it on a SD card so its easy enough to go back to 23.2. Just mount the internal emmc and change the value in extlinux.conf so it boots where you want. No boot on the sd leave it on the emmc. Much easier that way. There is a post on here on how to do that. Basically you mount the SD card to the rootfs directory in the Jetpack directory. Then untar the sample file system tbz2 to that. Remount on the TX1 and change up the extlinux to point to the SD. I had a SD with 14.04 and 15.05 64 bit fs. Picked the wrong one and was trying to use 3.10 kernel with 15.05 filesystem. That was causing all the misses on depend files. I only had to compile a couple of things after I fixed that to get all the depends loaded up. Still need CUDA libs and Zed SDK recompiled for 64 bit userspace so I’ve put it down for now. Working on getting a SPI to CAN bus adapter working now.

ok, this is one issue that i have not looked into and it might be time to do it. i have a ssd via the sata connector on the tx1. it would be useful to put 24.1 on that drive. it is /dev/sda1 on system, mounted at /media/ubuntu/L4T (L4T being volume name) so i make a copy of the data in extlinux.conf stating with LABEL and change primary to sda1 in order to make it a different entry in the menu and then change root=/dev/mmcblk0p1 to root=/dev/sda1 so that is new device. now, to set up root file system on the sda would it be ok to untar in root folder then apply binaries? also, i need to go to extlinux.conf and change the kernel info by changing FTD entry to 24.1 kernel ?
i found a post from search in forum that discusses this but it is from the tk1 device but i was thinking it was similar to tx1. so i think the tx1 boots and then waits for a menu selection. in extlinux it has a TIMEOUT value of 30 with a DEFAULT value of primary. then a MENU TITLE value of p2371-2180 emmc boot options the first and currently only being LABEL primary. so i copy from that point and paste underneath , change LABEL value to 24, the MENU LABEL value to 24 kernel, the FTD value would be the first .dtb listed in /boot/ on 24 file system? then APPEND value being copy except for root=/dev/sda1 ? so if anyone can give guide help, i’d appreciate it to have 24.1 setup so i could chose at boot time. thanks

JTK1 and JTX1 are very close to exact matches in terms of how u-boot is used. I assume your “/dev/sda1” is a GPT partition connected directly to the SATA controller, and not USB.

Something which can confuse people is the concept that u-boot and the Linux kernel may use files from a different partition or device. When you flash a Jetson, you tell u-boot where to look for configuration, e.g., normally you want to point to “mmcblk0p1” and place configuration on eMMC. At the moment u-boot hands off to the kernel, this is where the APPEND can change kernel to point somewhere else for root partition (the “root=” APPEND parameter).

I always suggest flashing to eMMC via mmcblk0p1…after that change your APPEND to whatever device you want. I strongly suggest the “/boot” directory of both u-boot config device and kernel rootfs device be copies of each other…that way you don’t need to think about what file is accessed from which device.

Take your eMMC extlinux.conf, copy an entry, and then make your edits. For example, if this is the original extlinux.conf:

TIMEOUT 30
DEFAULT primary

MENU TITLE p2371-2180 eMMC boot options

LABEL primary
      MENU LABEL primary kernel
      LINUX /boot/Image
      FDT /boot/tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb
      APPEND fbcon=map:0 console=tty0 console=ttyS0,115200n8 androidboot.modem=none androidboot.serialno=P2180A00P00940c003fd androidboot.security=non-secure tegraid=21.1.2.0.0 ddr_die=2048M@2048M ddr_die=2048M@4096M section=256M memtype=0 vpr_resize usb_port_owner_info=0 lane_owner_info=0 emc_max_dvfs=0 touch_id=0@63 video=tegrafb no_console_suspend=1 debug_uartport=lsport,0 earlyprintk=uart8250-32bit,0x70006000 maxcpus=4 usbcore.old_scheme_first=1 lp0_vec=${lp0_vec} nvdumper_reserved=${nvdumper_reserved} core_edp_mv=1125 core_edp_ma=4000 gpt android.kerneltype=normal androidboot.touch_vendor_id=0 androidboot.touch_panel_id=63 androidboot.touch_feature=0 androidboot.bootreason=pmc:software_reset,pmic:0x0 root=/dev/mmcblk0p1 rw rootwait

…you could change to this, and pick entry 2 as an option via serial console during the u-boot kernel selection stage:

TIMEOUT 30
DEFAULT primary

MENU TITLE p2371-2180 eMMC boot options

LABEL primary
      MENU LABEL primary kernel
      LINUX /boot/Image
      FDT /boot/tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb
      APPEND fbcon=map:0 console=tty0 console=ttyS0,115200n8 androidboot.modem=none androidboot.serialno=P2180A00P00940c003fd androidboot.security=non-secure tegraid=21.1.2.0.0 ddr_die=2048M@2048M ddr_die=2048M@4096M section=256M memtype=0 vpr_resize usb_port_owner_info=0 lane_owner_info=0 emc_max_dvfs=0 touch_id=0@63 video=tegrafb no_console_suspend=1 debug_uartport=lsport,0 earlyprintk=uart8250-32bit,0x70006000 maxcpus=4 usbcore.old_scheme_first=1 lp0_vec=${lp0_vec} nvdumper_reserved=${nvdumper_reserved} core_edp_mv=1125 core_edp_ma=4000 gpt android.kerneltype=normal androidboot.touch_vendor_id=0 androidboot.touch_panel_id=63 androidboot.touch_feature=0 androidboot.bootreason=pmc:software_reset,pmic:0x0 root=/dev/mmcblk0p1 rw rootwait

LABEL <b>sda1</b>
      MENU LABEL <b>SATA device sda1</b>
      LINUX /boot/Image
      FDT /boot/tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb
      APPEND fbcon=map:0 console=tty0 console=ttyS0,115200n8 androidboot.modem=none androidboot.serialno=P2180A00P00940c003fd androidboot.security=non-secure tegraid=21.1.2.0.0 ddr_die=2048M@2048M ddr_die=2048M@4096M section=256M memtype=0 vpr_resize usb_port_owner_info=0 lane_owner_info=0 emc_max_dvfs=0 touch_id=0@63 video=tegrafb no_console_suspend=1 debug_uartport=lsport,0 earlyprintk=uart8250-32bit,0x70006000 maxcpus=4 usbcore.old_scheme_first=1 lp0_vec=${lp0_vec} nvdumper_reserved=${nvdumper_reserved} core_edp_mv=1125 core_edp_ma=4000 gpt android.kerneltype=normal androidboot.touch_vendor_id=0 androidboot.touch_panel_id=63 androidboot.touch_feature=0 androidboot.bootreason=pmc:software_reset,pmic:0x0 <b>root=/dev/sda1</b> rw rootwait

In the above sample edit, if you’ve tested and found sda1 is what you want, change “DEFAULT primary” to be “DEFAULT sda1”. Keep these files as duplicates between sda1 and eMMC and you have yourself a rescue system. This implies any file mentioned in extlinux.conf. In some cases the file will be accessed by u-boot from eMMC, and later by the kernel on sda1.

Expanding the topic, should you flash to SD card on mmcblk1p1, this implies the location of files for u-boot config changes from eMMC to SD card…without an SD card this would fail to boot. However, the SD card variant would still follow kernel handoff as per the “root=” parameter, and so config would be from “/boot” of SD, but kernel would use “/boot” of sda1. You almost never want to flash u-boot to point at a non-eMMC device…it’s best to leave it on eMMC, and then redirect only the kernel.

Note that u-boot must understand the partition and device of where it gets extlinux.conf, the kernel must understand the partition and device of the “APPEND” key/value pair. Sometimes u-boot can hand off the kernel to things u-boot does not understand and things will work well. I don’t know why someone would need it, but it is also possible to point the kernel to a device u-boot does not see or understand, and also have things work well. When there are two devices involved, the main danger is if you edit the wrong one and don’t realize the stage of boot is pointing to the other…it can make for some interesting frustration. This and the ability to rescue and restore is a big reason to keep exact copies of “/boot” on both devices even when not required.

linuxdev, thanks for this info. when i create the file system on the ssd can i just place the tarball in the root folder of the ssd then untar it and do the apply binaries? and when i do get the file system set up on the ssd , i need to be sure the /boot on ssd is a copy of /boot on eMMC? also, when the tx1 is operating on the ssd (24.1) and i restart will the system go to the /boot on the eMMC or the ssd? in other words would a restart give me the choice between eMMC/sda, or would it just reload the sda? thanks for the help.

I’ve unpacked the sample rootfs and used apply_binaries.sh on an SD card from my host (sda1 should be no different in that respect). Just be careful to preserve permissions (use sudo). I recommend “/boot” of SSD and eMMC be copies; some parts may only be needed where u-boot reads, but if something were to go wrong, then you already have backup files in place. Technically the zImage or Image, extlinux.conf, and the dtb files need to be where u-boot is pointed; “/lib/firmware” and “/lib/modules” need to be where the kernel is pointed.

If you flashed to mmcblk0p1, this is the extlinux.conf file. If you flashed to sda1, then the SSD would be the extlinux.conf file in question. If you have two entries in the extlinux.conf file which u-boot reads, then reboot will offer both choices at boot via a serial console.

One trick to understanding things is to put a slightly different “MENU LABEL” on the extlinux.conf of eMMC versus that of sda1, but having entries otherwise identical. E.g., “MENU LABEL sata device via eMMC” or “MENU LABEL sata device via sda1”…then your serial console will tell you which extlinux.conf is being used by its serial console label at boot.

@danpollock I would like to get ROS working on 24.1. I think now that it is an official release it should be time (has cuda, opencv…). Have you made any progress? I’ve had a few rough attempts at ROS Indigo or Jade (due to ubuntu 14.04 FS).

I’ll be trying again later this week, but was curious how you got on?

Cheers

I am currently trying to get ROS Indigo installed from source on 24.1 and so far it was going good, but recently TX1 started freezing the screen on me and pinging it shows it’s unresponsive. Can anyone relate? And if anyone managed to install ROS (preferably Indigo) on 24.1 could you post some details?

Cheers

I managed to install from source mainly following the guide with the minor exception of having to install sbcl alone and add the skip-keys for it later. I did the Bare-Bones and just now tested some basic functionality and everything seems to be working just fine. Hope that helps.

Cheers

Thanks mdziwuls for the update. I (as always) got distracted with other things that needed doing so have not yet carried on.

From you post I am assuming you’ve installed indigo? Also was it cumbersome? Other than the mentioned issues, anything of note?

And for me the question remains, I am still unsure on if 64b is worth the hassle…

As I wrote it mainly follows the official source install guide, but depending on the packages you might have to install some things separately. I tried to get a desktop-full install running today, but after a few hours of hassle I still have a few unresolved dependencies and installing them separately doesn’t seem to help here, so I am probably going to revert to 23.1.

It’s probably worth the hassle if you’re fine with just the core packages. After that it goes from few minutes to quite a few hours of work.

I’m try to do ROS on 24.1 as well. Just about finished flashing 24.1 to the developer board. Were there resolutions to these problems or should newbs like me really go back to 23.1?

Thanks

Since 64b user space wasn’t critical for me, I went back to 23.2 sorry.

ROS works completely in 24.2. Just follow the steps on: jade/Installation/UbuntuARM - ROS Wiki

Replace jade with kinetic and trusty with xenial