Qt5.x on Jetson tk1: is there a tutorial somewhere?

Re: Qt5.x on Jetson TK1 ?

Dear all,
Is there a way to install the subject ^^?
Is there a step-by step tutorial somewhere?

I have found an example:

http://code.qt.io/cgit/qt/qtbase.git/tree/mkspecs/devices/linux-jetson-tk1-pro-g++/qmake.conf

But there seems neither vibrante

-device-option VIBRANTE_SDK_TOPDIR=/opt/nvidia/vibrante-vcm30t124-linux

nor cortex_a15

-device-option CROSS_COMPILE=/opt/nvidia/toolchains/tegra-4.8.1-nv/usr/bin/arm-cortex_a15-linux-gnueabi/arm-cortex_a15-linux-gnueabi- \

at the PC I’m trying to compile on.

I’m just wondering if there is a need of install of the following packages:

https://launchpad.net/gcc-arm-embedded/5.0/5-2016-q1-update/+download/gcc-arm-none-eabi-5_3-2016q1-20160330-linux.tar.bz2

presuming that there is already arm-linux-gnueabihf .

Anyone knows what keys to pass to qt /configure if using opensource 5.6, 5.7 version?

Thank you,
Regards.

The gcc used with L4T R21.x is a Linaro 4.8 version (though 4.9 should work)…the 5.3 version would be for the 64-bit JTX1 (including for 32-bit user space on ARMv8 and ARMv8a), and may have problems. Additionally, the “arm-none” part of the naming suggests a bare metal environment…I use the arm-linux for kernels, though technically that and the boot loader should be ok with arm-none. For user space applications you’ll want “arm-linux”. So something like “gcc-arm-linux-eabi-4_8…”.

If you do your testing via compiling natively on the JTK1 you won’t need a cross-compiler. Once your compile works natively it becomes more straight-forward to set up cross-compile.

thx linuxdev.

It seems that the JTK1 has arm-linux-gnueabihf-g+±4.8, but I’m compiling naively on the JTK1.

I do not need to add to ./ configure a key gcc-arm-linux-eabi-4_8 somehow? Do I?

simple ./configure without specific keys won’t work. Will it?

Thank you for the explanation.
Now I understand that it is gcc 4.8 used there :
/usr/include/arm-linux-gnueabihf/c++/4.8
and there
/usr/bin/arm-linux-gnueabihf-g+±4.8

Thank you
Regards,

./configure -prefix $PWD/qtbase -nomake tests
will be changed to
./configure -prefix $PWD/qtbase -opensource -nomake tests
no more changes needed?

than just

make -j 4

correct?

I mention version 4.8 because of one of the URLs you mentioned:
https://launchpad.net/gcc-arm-embedded/5.0/5-2016-q1-update/+download/gcc-arm-none-eabi-5_3-2016q1-20160330-linux.tar.bz2
…that URL is for the wrong compiler for a JTK1, and if used, would very likely cause compile failure.

You also do not need any cross compiler to do a native build, and in fact native build is by far the easiest way to go if you don’t have to cross compile. No special configure argument should be required for a native build involving things which would be detected anyway. CPU architecture is one of those things the compiler and scripts should take care of for you.

That said, there are other things any cross-platform tool kit might need configuring for, but I do not know in this case what is required. The “prefix” is typical of needing manual adjust, and is something I usually set to “/usr/local”, but “prefix” would not break a compile.

The best thing to do is to post the last paragraph or so of the compile where it shows why compile failed.

Qt5 is available in this manner:

sudo apt-get install build-essential qt5-default qtcreator -y

This will also install Qt Creator if you’re using it for development purposes. It you’re trying to compile it from source it can be a little challenging and requires various changes here and there. I would only recommend compiling from source for someone who has some experience with such things.

Does it clarify something?

col -lQt5Qml -lQt5Network -lQt5Core -lpthread
mv -f libqmldbg_debugger.so /home/andre/Desktop/qt-everywhere-opensource-src-5.7.0-beta/qtbase/plugins/qmltooling/
make[5]: Leaving directory /home/andre/Desktop/qt-everywhere-opensource-src-5.7.0-beta/qtdeclarative/src/plugins/qmltooling/qmldbg_debugger' make[4]: Leaving directory /home/andre/Desktop/qt-everywhere-opensource-src-5.7.0-beta/qtdeclarative/src/plugins/qmltooling’
make[3]: *** [sub-qmltooling-make_first] Error 2
make[3]: Leaving directory /home/andre/Desktop/qt-everywhere-opensource-src-5.7.0-beta/qtdeclarative/src/plugins' make[2]: *** [sub-plugins-make_first-ordered] Error 2 make[2]: Leaving directory /home/andre/Desktop/qt-everywhere-opensource-src-5.7.0-beta/qtdeclarative/src’
make[1]: *** [sub-src-make_first] Error 2
make[1]: Leaving directory `/home/andre/Desktop/qt-everywhere-opensource-src-5.7.0-beta/qtdeclarative’
make: *** [module-qtdeclarative-make_first] Error 2

Thank you linuxdev, thank you Kangalov :qtcreator does install but with qt5.7 or 5.6 or 5.5 does not as it seems to me

Regards,
Andrey

It seems like the log you posted is just the exit information of a recursive build. The actual error is probably further back, while the posted portion is just that the build is exiting. Do you have logs going further back?

Thank you for your response.
It turned out that 7.2 GB was not enough for qt.5.7 compilation.
The error was :
{standard input}: Fatal error: can’t close .obj/moc_camerabinsession.o: No space left on device
make[5]: *** [.obj/moc_camerabinsession.o] Error 1
{standard input}: Assembler messages:
{standard input}: Fatal error: can’t write .obj/moc_camerabincontrol.o: No space left on device
{standard input}: Fatal error: can’t close .obj/moc_camerabincontrol.o: No space left on device

Regards,
Andrey

Is there a way to reinstall tegra-linux via vnc remotely with kind of flashing[emptying] ssd hdd for free space get purpose with help of the file JetPack-L4T-2.1-linux-x64.run, but not using graphical UI within the installation process?

It seems rather impossible, but may be there are some ways of reinstalling of tegra-linux with compact in terms of sdd space use installation?
Now I’m speculating about mounting a nfs drive as an alternative solution, but it seems to me that tegra-linux installation somehow can be done in the alike manner: http://www.tecmint.com/installation-of-centos-remotely-using-vnc-mode/

Is there vnc mode somewhere? Are there any instructions on the issue?

Regards,
Andrey

I’m not sure I completely understand the question, but here goes…

Flash never requires JetPack. The actual flash is from the driver package plus sample rootfs (the apply_binaries.sh step overlays nVidia-specific files onto the sample rootfs). The flash will create a loopback mountable ext4 partition file on the host, and then send a “sparse” image version of this to the Jetson (sparse is just a compressed version). Aside from some boot files the image is an exact copy of the sample rootfs; thus edits to this end up in the flashed Jetson. This image can be reused if desired (which saves edits which directly modified the loopback image).

The use of VNC for remote install requires a desktop boot loader and motherboard support (BIOS/UEFI which is not present on any embedded system), so this is not available under Jetson.

For more disk space you could mount a partition on a regular hard drive or SD card which is connected via SATA port or SD slot. This can be mounted anywhere, Jetson itself will not be relevant (it’s simply a Linux capability). You could for example mount a partition on a SATA drive to “/usr/local”, or with some extra steps, replace the root partition with a larger SATA drive partition.

A more complicated option is to enable iSCSI support and remote mount a network disk just like a physically present disk (this gets much more complicated). NFS works too, but has its own set of difficulties and weaknesses (NFS is a file server which can be accessed by multiple guests, whereas iSCSI can be mounted and used by exactly one remote system and is seen as a physically present disk partition). iSCSI tends to be higher performance and more secure than NFS…in my opinion NFS shouldn’t be used unless you need a file server. I have not PXE booted nor mounted NFS for a root partition in a long long time.

An alternative is to do the source compilation on an external drive, like an SSD. That way all of the object files will be stored on the external drive, and you won’t have to worry about running out of room.

Thank you linuxdev, Thank you Kangalow.

Finally I got managed to solve the space issue.

However iSCSI feature seems intrinsic and worth a separate investigation.

I’ve tried JetPack run, but it complains:

“Jtpack must be run on x86_64 Host platform. Detected armv7l platform”

It seems that available ubuntu JetPack doesnt work natively on the armvl.

I’ve done qt compilation with help of the instruction :
1)git clone git://code.qt.io/qt/qt5.git
2)cd qt5
3)git checkout 5.7
4)perl init-repository
5)./configure -developer-build -opensource -nomake examples -nomake tests
6) make -j 4 [is there a space between j and a number required?]

It seems that there were no errors. How could I verify that installation was successful?

When I do run qtconfig it refers to some absent qt4. Is that a matter of manual path editing?

qtconfig --version
qtconfig: could not exec ‘/usr/lib/arm-linux-gnueabihf/qt4/bin/qtconfig’: No such file or directory

I’m considering doing configure and make again [I’m not sure but I might have interrupted the make procedure somehow ]

Thank you for the info in regards to the driver package plus sample rootfs. Is it available for download somewhere? I have no physical to the embedded platform though.

Regards,
Andrey

JetPack and the driver package are never run from a Jetson…they require being run on a desktop x86_64 Linux host (in the case of jetPack this Linux host also has to be Ubuntu 14.04). Attempting to download or run from a Jetson would be a good reason to run out of disk space…not only will you have the uncompressed complete copy of the Jetson’s file system, you’ll have the programming for installing it as well (even a desktop host will require a lot of available disk space to use the flash software). The basic work flow is the Jetson is put in recovery mode and becomes a custom USB device detected by the flash software which runs on the desktop host (the custom USB device is not running anything other software would know how to work with).

After that you can consider Qt build natively on the Jetson. Cross compile is possible, but complicates life (for kernel cross compile it isn’t too bad, but for user space apps cross compile gets complicated fast).

It seems to be rather straightforward to put Jetson into recovery mode which turns the Jetson into usb device which can be flashed from host.

Unfortunately I have no physical access to the Jetson. Possibly I will be able to ask someone to do the recovery process. I’ve found the recovery process description at

http://elinux.org/Tegra/Boards/NVIDIA_Jetson_TK1 and https://demotomohiro.github.io/hardware/jetson_tk1/setup/recovery_mode.html and
https://developer.nvidia.com/sites/default/files/akamai/mobile/docs/l4t_quick_start_guide.txt

and I’ve found the button picture :http://rabbit-note.com/wp-content/uploads/2014/08/JetsonTK11.jpg

Does the mentioned above git-6-steps-install way seems rather correct for build Qt natively ,remotely though? It seems that there is no need to run make install. How do I verify if qt functions properly after “make -j 4” step?

Sincerely yours,
Andrey

Usually pre-compiled packages are the best way to go for something like Qt. Kangalow mentioned how to use existing packages, but it sounds like you want a specific version…can you clarify your requirements around Qt and versions?

In general, without being specific to Qt, most software out there these days has some sort of configuration step. At least part of that configuration defaults by detecting the system it is being built on, unless an option specifically says to override that (example is that CPU architecture does not need to be specified on a native compile, but a custom install point would be named if this install point is not the default). The “make -j4” step is intended to create installable files, but does not actually put things in place. There may be a “make test” type target to see if the software build succeeded, but this is custom to the software package. Most source software would have something such as “make install” to actually put the files in place. In the case of library files, it may be necessary to update a linker config file before the libraries will be automatically visible. Much of this will be specific to the Qt software…clarification of what your requirements are for Qt would help.

NOTE: Remote compile will not change compile results. Remote display is a different topic and would change any graphical display component.

From the above I conclude that specifying at the bottom line following the argument -device tegra-tk1 \ doesnt make sense?
/configure -developer-build -opensource -nomake examples -nomake tests

Actually my task is to configure one program that is for i386 and which uses qt.5.5 on jtk1 hardware.
But for now it seems to me that the fastest possible way is to use qemu for that purpose.

Which method to use for i386 program run at jetson tegra armv7l?