Building the Linux Image (BSP) for NavQ SOM (HoverGames)

cancel
Showing results for 
Search instead for 
Did you mean: 

Building the Linux Image (BSP) for NavQ SOM (HoverGames)

522 Views
dirksavage88
Contributor I

Hello,

I noticed the instructions in the NavQ developer guide pointed to a git repo > GitHub - NXPmicro/meta-nxp-hovergames 

Which does go over steps to build the image, however at the every end of the readme in the repo, it talks about a minimal and regular image?

What is meant by weston desktop in the regular image? Is that similar to a "server with gui" in linux environments?

I am trying to decide which one to build, and since I really only need a linux command line, I am leaning towards the minimal, but I do not know all the differences between the two.

Any help would be appreciated.

#NXPHoverGames

Tags (1)
0 Kudos
4 Replies

427 Views
dirksavage88
Contributor I

Thanks guys! I am in the process of building the source in the master branch (the regular image and not the minimal).

Right now it's humming along executing tasks. I might have to leave it running overnight.

Some follow on questions:

The gitbook talks about the demo image including the apt package manager and the regular image not really having this built in. Looking at the master branch, I see an apt bitbake under recipes-devtools. Was the gitbook correct or is it just not updated to the latest github remote branch updates?

I also see Qt5, python 2, etc. So i'm assuming I will have some built-in development tools once the image is created?

Just out of curiosity: What beastly machines do you guys use to build the images on your end?

0 Kudos

456 Views
iaingalloway
NXP Employee
NXP Employee

I would like to clarify.
NOTE that in https://github.com/NXPmicro/meta-nxp-hovergames there are two branches.

MASTER and DEMO

In the MASTER branch you can build two images. The minimal doesn't include the on board build tools and graphical components. Just to save time when building and testing adding new packages, layers and recipes into the whole yocto build system - particularly while iterating many times. Normally you will want the full build on the NavQ, unless you specifically know you don't need these extra on board build tools/GUI.

$ bitbake imx-image-hovergames
$ bitbake imx-image-hovergames-minimal


In the DEMO (Ubuntu)branch you can only build one image

$ bitbake imx-image-hovergames-demo

 

0 Kudos

467 Views
iaingalloway
NXP Employee
NXP Employee

So the git repo states
"There is a regular image and a minimal image. The minimal image excludes build-on-target support and the weston desktop."
Weston is a reference implementation of a compositor built on top of Wayland 
In simple terms - Weston/Wayland lets you have graphical programs displaying on a desktop.

The other big difference is the built on target tools. This means you can compile c programs and have libraries available to you to build. If you want to do any of this, then the regular image is what you want.

The real reason behind both image, is that in the process of testing adding new packages to the Yocto BSP (recipies and layers), it just takes a longer to compile the regular image vs the minimal image. When you are doing this over and over again for testing things - it matters. 

Both images are still relatively small. I recommend the regular image unless you have a specific need to be extra small or faster to compile.

467 Views
landonh12
NXP Employee
NXP Employee

Hey Andrew,

If you want to build the HoverGames-Demo image that is based on Ubuntu 20.04, you'll want to switch to the "demo" branch in the git repo. The demo image has a different set of instructions to build than the Yocto-based image (which is in the master branch).

The Demo image uses an Ubuntu 20.04 root filesystem and has support for the apt package manger. The Yocto-based image is meant for creating a lightweight embedded distribution that has the software you need pre-installed. I suggest you use the Demo image!

The NavQ also ships with the Demo image pre-installed to the included SD card.