search

OE4T / meta-tegra

BSP layer for NVIDIA Jetson platforms, based on L4T
MIT License
397 stars 220 forks source link

Possible to build on a non-ubuntu host #304

Closed bsmerbeck closed 4 years ago

bsmerbeck commented 4 years ago

Hello,

Was attempting to build the core-image-minimal on my existing bitbake server running CentOS 7.7. It's a server tied in with our Bitbucket/Bamboo instances, and we've begun working with the Jetson Nano Dev Kit. My intention was to build the minimal image (note: we don't need CUDA or any ML-related tools at the moment)

After initializing the init environment, I cloned the dunfell branch of meta-tegra to my main poky directory.

Appended the following text to build/conf/local.conf MACHINE = "jetson-nano-qspi-sd" LICENSE_FLAGS_WHITELIST = "commercial" IMAGE_CLASSES += "image_types_tegra" IMAGE_FSTYPES = "tegraflash" GCCVERSION = "7.%"

Added meta-tegra directory to build/conf/bblayers.conf

ran command bitbake core-image-minimal

Error was during do_compile() of linux-tegra_4.9.bb. More lines than I can count but all basically identical:

/yocto/build/tmp/work-shared/jetson-nano-qspi-sd/kernel-source/arch/arm64/boot/dts/Makefile:119: target 'arch/arm64/boot/_ddot_' given more than once in the same rule
p3448-0000-p3449-0000-a02.dtb'.  Stop.
| make[2]: *** [arch/arm64/Makefile:151: _ddot_/_ddot_/_ddot_/_ddot_/nvidia/platform/t210/porg/kernel-dts/tegra210-p3448-0000-p3449-0000-a02.dtb] Error 2
| make[1]: *** [Makefile:169: sub-make] Error 2
| make: *** [Makefile:24: __sub-make] Error 2
| WARNING: /yocto/build/tmp/work/jetson_nano_qspi_sd-poky-linux/linux-tegra/4.9+gitAUTOINC+47e7e1cb0b-r0/temp/run.do_compile.152303:1 exit 1 from 'exit 1'

Also curious how to go about building without being on an Ubuntu host for the NVIDIA SDK. I tried looking around but there aren't a lot of places to ask these kind of questions. If there's a community or message-board that would work better for asking these questions I'd be happy to move this request off of the repo itself.

lfdmn commented 4 years ago

Not sure if this answers your question, but what about running the builds from a docker container with an Ubuntu based image?

That's what we do with our build environment. Servers being contos too.

That was also the trick to be able to run TK1 builds on Ubuntu 18-04 due to host tools incompatibility issues.

Although builds are running within the container, I setup folder mappings (not volumes) for the yocto project between the host machine and the image.

This allows modifying the recipes like normally on the host computer and only run the builds from the container.

To get that to work, you need to make sure to create a user and a group inside the container matching the UUD and GID in the host machine to get write permission.

For building the production images and verification builds, Jenkins starts a job also running on a container from whichever build node is available at the time.

There I map only the sstate and download folders. The image goes down after each build,deleting all the intermediate files, which make me start from a fresh build each time.

For image release builds I keep only the download folder and redo the full build.

madisongh commented 4 years ago

This particular error looks like it may be something to do with the version of GNU make you have? I ran a couple of test builds of the Nano kernel on a VM running CentOS 7.7 - not dunfell, but zeus with L4T 32.3.1, which is the same kernel version - and my build worked OK. I thought maybe there were some GNU make 4.0-or-later constructs in the makefiles that wouldn't work properly with the 3.82 version in CentOS 7, but since I didn't get a failure I guess that wasn't it.

In theory, at least, builds on CentOS 7 should work, provided you follow the instructions in the Yocto Project docs on packages to install and use of their buildtools-tarball package. That said, I don't really have the resources to test regularly across multiple host distros, and there's no guarantee that NVIDIA-provided host tools will work on anything but the versions of Ubuntu that they support, so using the container approach that @lfdmn mentioned might be a good option.

bsmerbeck commented 4 years ago

Not sure if this answers your question, but what about running the builds from a docker container with an Ubuntu based image?

@lfdmn I suppose the only thing stopping me is my own naivety working with Docker?

@madisongh I'm going to resolve that issue with GNU make and ensure I'm using the buildtools provided and see if it gets farther. All else fails I'll crack into Docker to get some form of progress.

bsmerbeck commented 4 years ago

@madisongh GNU seemed to be the issue. Successfully built on my centos host, and I spun up an ubuntu VM to handle the flashing. Closing this