MNT Research based in Berlin, Germany, wanted the perfect in-between device with a modular, open-source framework for professionals on the go and enthusiasts alike.
We are pleased to announce a new Yocto release Mickledore for our Nitrogen8’s family of SBCs and SOMs based on i.MX 8 processors. This release is based upon NXP 6.1.22_2.0.0 release and includes our latest 6.1 kernel, as well as support for our new Nitrogen8M Plus SMARC platform. Below you will find download links for the images as well as detailed instructions for building including a features set.
For the Impatient
You can download the Yocto images from here:
Note that we now have support for sparse Fastboot Images!
This image uses the boundary-imx-6.1.22-2.0.0 (mickledore)branch of our boundary-bsp-platform repository.
To build the image, we recommend using a Docker Container so that you can build with a reproducible and stable build environment. Otherwise, you’ll need these packages installed as well as this repo tool that can be installed like this:
~$ sudo apt-get install repo
Then create your build directory and initialize everything.
Now bitbake boundary-image-multimedia-full which is equivalent to fsl-image-multimedia-full with Boundary-specific packages added such as BD-SDMAC support.
After some time this should build the same image as above, with the layers being at commits as per the time when repo sync was executed. If you are interested in each project revision at the time of the build, you can find a frozen manifest for those images here.
The image file will deploy to tmp/deploy/images/{MACHINE}/boundary-image-multimedia-full-{MACHINE}.wic.gz.
Features list
The image built above contains the following components:
Linux kernel 6.1
U-Boot 2022.04
Weston 11.0.1 for i.MX
GStreamer 1.22.0 for i.MX
GPU Vivante libraries 6.4.11.p1.2
VPU Hantro libraries v1.29.0
ISP VVCAM v4.2.2.22.0
qcacld-lea-3.1 Wi-Fi driver for BD-SDMAC
BlueZ 5.66 with support for BD-SDMAC
The next sub-sections will describe how to test most features.
Display support
Please make sure your platform includes the latest U-Boot:
In this first of a series of blog posts, we discuss various aspects of the SMARC standard, a critical component of our SOM portfolio, and what it means for our customers.
Buildroot 2023.08 has been published and we’re excited to share new images! This release includes our latest 6.1 kernel, as well as support for our new Nitrogen8M Plus SMARC platform!
For the impatient
You can download pre-built Buildroot 2023.08 images from here:
Same set of packages as nitrogen6x_qt5_gst1_defconfig
Mainline kernel
New features
Buildroot 2022.08 includes the following versions of packages:
BlueZ5 5.68
GStreamer 1.22.2
GStreamer-imx v0.13.1 for i.MX6
GStreamer-imx v2.2.0 for i.MX8M
imx-codec 4.3.5
imx-gpu-viv 6.4.11.p1.2
imx-vpu-hantro 1.29.0 for i.MX8M
imx-vpu-hantro-vc 1.9.0 for i.MX8MP
imx-vpu 5.4.39.3 for i.MX6
Linux kernel 6.1.y
qcacld-2.0 LEA-3.1 Wi-Fi driver
Qt5 5.15.10
Support for Nitrogen8MP SMARC added
Wayland 1.22.0
Weston 12.0.1
There are a few differences between Yocto and Buildroot releases at this stage:
Buildroot images use standard packages without NXP modifications
This applies to GStreamer, Weston, libdrm, wayland etc…
The main drawback is that Weston can’t be used with G2D
The (big) advantage is that it makes the codebase much easier to maintain, being able to use all the latest packages without having to be stuck at an earlier version chosen by NXP
Open-source gstreamer-imx plugin is used instead of NXP forks
This allows us to have imx-related changes for GStreamer in 1 package only
Build procedure
Just like our Yocto image, we now use a Docker file to build our images on our Jenkins server so that everyone can use the exact same environment. This ensures reproducible builds without having to think about missing dependencies.
If interested in using this approach, we invite you to read the following blog post using the following docker file:
~/br2023.08$ make BR2_EXTERNAL=$PWD/buildroot-external-boundary/
-C $PWD/buildroot/ O=$PWD/output nitrogen8mm_qt5_gst1_defconfig
~/br2023.08$ cd output
Build the image
~/br2023.08/output$ make
Your image is now ready!
~/br2023.08/output$ ls -l images/sdcard.img
~/br2023.08/output$ sudo dd if=images/sdcard.img of=/dev/sdX bs=1M
Testing the image
As usual, the login for this image is root with no password.
The external repository README details many commands that can be tested on the image.
Once booted up, the Weston desktop should appear automatically, from there you can start a 3D test to ensure GPU acceleration
# cd /usr/share/examples/viv_samples/vdk/
# ./tutorial7 -h 720
You can also check the GStreamer VPU acceleration by decoding the well known Big Buck Bunny video
Now more than ever, as developers around the world race to bring their legacy solutions to the Internet of Things – as well as develop new, connectivity native solutions – the tools and practices used in this transformation can be the difference between success and failure.
In this post we will provide instructions on how to create and use the Yocto SDK.
The Yocto SDK is extremely useful as it allows for quick application development without having to build and maintain massive yocto builds. It provides a cross-development toolchain and also libraries that are specific to a particular yocto image i.e. a specific hardware architecture.
First, follow the instructions in the “Build Procedure” section of our latest Yocto Mickledore release, but stop after setting up the build environment and before the bitbake of the boundary-image-multimedia-full image.
Instead, we need to bitbake so that the SDK can be built, which can be done via:
We now need to run the generated SDK Installer, which is an executable shell (.sh) script. It can found in the current working build directory -> “build/tmp/deploy/sdk”
Using the yocto mickledore image as an example, the sdk installer will be called “fsl-imx-xwayland-boundary-glibc-x86_64-boundary-image-multimedia-full-armv8a-nitrogen8mp-toolchain-6.1-mickledore.sh”, but of course depending on the distro, machine, host machine, target arch and image name, this will vary.
Note: The script will prompt you to select a target directory of your choosing .
~$ cd build/tmp/deploy/sdk
~/build/tmp/deploy/sdk$ ./fsl-imx-xwayland-boundary-glibc-x86_64-boundary-image-multimedia-full-armv8a-nitrogen8mp-toolchain-6.1-mickledore.sh
NXP i.MX Release Distro SDK installer version 6.1-mickledore
============================================================
Enter target directory for SDK (default: /opt/fsl-imx-xwayland-boundary/6.1-mickledore): /home/Yocto_SDK
You are about to install the SDK to "/home/Yocto_SDK". Proceed [Y/n]? y
Extracting SDK.....................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................done
Setting it up...done
SDK has been successfully set up and is ready to be used.
Each time you wish to use the SDK in a new shell session, you need to source the environment setup script e.g.
$ . /home/Yocto_SDK/environment-setup-armv8a-poky-linux
3- Using the SDK
We can now use the SDK to develop applications. Below we will show how to use the SDK with Makefile, CMake, and Autotools based applications
3.1- Run the SDK environment setup script
Create a working directory for an example app to use with the SDK. Then in a shell/terminal navigate to that directory and source the environment script using the target directory from the SDK install:
The script essentially sets up environment variables in the current shell that are used for cross compilation application development. You can see all variables set by the installer with the “printenv” command.
3.2- Create Sample Hello World application
Create a hello world application to use as an example for each three build systems. Create the file “helloworld.c” with the following lines:
#include <stdio.h>
int main(void)
{
printf("Hello, World!\n");
return 0;
}
Now we are ready to use the SDK to build the hello world app.
3.3- Makefile based applications using the SDK
First, create the Makefile with the following lines:
You will notice from the make command that cross compilation is occurring because the CC compiler and arch is set for aarch64. This is because the SDK environment script sets the CC environemnt variable.
Finally, we can see it cross compiled for the correct architecture with file command:
~$ file helloworld
helloworld: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=135e97d99cfa7f122a30a1ef7aad4035da1a7852, for GNU/Linux 3.14.0, with debug_info, not stripped
3.4- CMake based applications using the SDK
First, create the CMakeLists.txt file with the following lines:
You will notice that we are setting the toolchain file for cmake to be the environment variable OE_CMAKE_TOOLCHAIN_FILE, which is set by the yocto SDK environment setup script.
~$ cmake .
-- Toolchain file defaulted to '/home/Yocto_SDK/sysroots/x86_64-pokysdk-linux/usr/share/cmake/OEToolchainConfig.cmake'
-- The C compiler identification is GNU 12.2.0
-- The CXX compiler identification is GNU 12.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /home/Yocto_SDK/sysroots/x86_64-pokysdk-linux/usr/bin/aarch64-poky-linux/aarch64-poky-linux-gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /home/Yocto_SDK/sysroots/x86_64-pokysdk-linux/usr/bin/aarch64-poky-linux/aarch64-poky-linux-g++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: '/home/yocto/'
Then, we can make our helloworld app:
~$ make
[ 50%] Building C object CMakeFiles/helloworld.dir/helloworld.c.o
[100%] Linking C executable helloworld
[100%] Built target helloworld
Finally, we can see it cross compiled for the correct architecture with file command:
~$ file helloworld
helloworld: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=63a68c6fad3a0c27be411a08ce131429c199d71a, for GNU/Linux 3.14.0, with debug_info, not stripped
3.5- Autotools based applications using the SDK
Using the same helloworld.c file, we need need to create the remaining files required for autotools which are configure.ac and Makefile.am.
Create a “configure.ac” file with the following lines:
Then create the “Makefile.am” file with the following lines:
bin_PROGRAMS = hello
hello_SOURCES = helloworld.c
Run “autoreconf” with the “-i” option to copy missing auxiliary files:
~$ autoreconf -i
Now we can cross compile helloworld using the “CONFIGURE_FLAGS” environment variable provided by the SDK environment script:
./configure ${CONFIGURE_FLAGS}
Finally, run make to generate the hello binary:
~$ make
and then see it is meant for the correct architecture with file command:
$ file hello
hello: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=b43562f742cfb06bf16269364ff766aa43b8a5c1, for GNU/Linux 3.14.0, with debug_info, not stripped
There you have it! You now know how to create and use the Yocto SDK in your application development!
Boundary Devices is proud to release our new Debian Bookworm image for all our Nitrogen8 boards!
This image uses Weston which is the reference Wayland compositor.
This image boots up the Weston compositor at start. This can be changed by disabling the service autostart, as described later in this post.
This system contains NXP licensed content, so you will need to register on our website and log in before you can accept the license agreement and download the Debian Bookworm images for Nitrogen8 from here:
This is a unified image for the aforementioned boards, there is no need for board specific images anymore. At the first start it will detect the board type run a configuration script. Finally, it will set all board specific parameters and apt repositories.
Important!
Before installing this image please check your U-Boot version, as it requires U-Boot version 2022.04 to be used.
Make sure to visit our wiki if you need to upgrade:
You can find the bootscript in the /boot sub-directory now, its named boot.scr. The partition labels are set if you use dd or Balena Etcher to flash the image.
If you use your own method please check the boot partition labels because the fstab boots by label (LABEL=sys-1Eh for example) now. You can use e2label to modify partition label.
Programming the image
As usual, we recommend using the Balena Etcher tool to flash your SD Card / eMMC:
The uncompressed image size is slightly bigger than 5GB, you’ll need at least 8GB eMMC storage to install it.
Please watch this video for the detailed instructions:
Usernames and passwords
We predefined two users for use on the system: debian and root. The password for each is Boundary (capital B). The user debian has administrator rights, but you don’t need to enter password at sudo command.
We wanted to make your life easier at the cost of some security, but if you want to change that please type:
debian@bookworm-dev64:~$ sudo visudo
Then comment out or delete the last line with “debian” and “NOPASSWD:”
An ssh server is running on the system, though it does not allow password-based authentication for user root.
User debian has sudo privileges, so you can place your ssh public key (normally $HOME/.ssh/id_rsa.pub) to the system like so:
All kind of storage devices , eMMC, SATA hdd (via USB3-SATA adapter), USB3.0/2.0 pen drives, mini PCIe devices, cell modems
All of our supported touch panels
The packaging (including kernel) is done in the normal debian way, so apt-get update/dist-upgrade will keep your image up and running as the latest as patches come out.
What’s new in this release?
The Linux kernel was upgraded to 6.1.x branch ( meta-package name: linux-boundary-21b ).
GPU driver was upgraded to Vivante 6.4.11p1.2 ( meta-package name: imx-gpu-viv-b23-… ).
The built-in galcore module has been removed (CONFIG_MXC_GPU_VIV) and we use an external galcore kernel module. This change makes the graphics system modular and more upgradeable, at the price of longer kernel upgrading time. Upgrading kernel takes about 3-4 minutes now, instead of 30 seconds, because every kernel upgrade rebuilds the galcore driver from sources, as it’s a DKMS module.
The NXP/Vivante GPU SDK was upgraded to imx-gpu-sdk 6.1.1 . You can get the source with the usual apt-get source command. The SDK has many new demos, for example OpenCL, OpenVG, and for OpenVX and Vulkan.
The distribution is Debian GNU/Linux 12 Bookworm. Here are some main component versions of these Debian Bookworm images for Nitrogen8:
Xorg server 21.1.7-3
gstreamer1.0 1.22.0-3+deb12u1
bluez 5.66-1
Qt 5.15.8+dfsg-11.1
apt 2.6.1
dpkg 1.21.22-1
gcc/g++ 12.2.0-14
libwayland 1.21.0-1.1
weston 10.0.1-1.7
the image supports the Silex WiFi / Bluetooth module and the Laird Connect LWB5+ Bluetooth 5.2 module
CPU-specific package selection
This is a unified image for the entire i.MX 8M family of processors. Since each CPU has its own specific features the OS must adapt to each platform.
That is why, during the first boot, a new selecthw service has been created to take care of selecting the proper packages needed for your platform.
For instance, for the Nitrogen8MP platform, the OS makes sure VPU encode/decode is enabled, NPU packages are added as well as the ISP service to manage the Basler daA3840 camera and/or the Sony imx219 camera.
After that setup, the platform will need to reboot for those changes to be taken into account.
Thankfully, you can see the progress of that process on the display as shown below:
Network Manager
This Debian Bookworm image comes with Network Manager by default in order to ease the Wi-Fi setup.
You can find the weston.ini file in the /etc/xdg/weston directory. Please type:
debian@bookworm-dev64:~$ man weston.ini
Check the options and feel free to modify it to suit your needs.
Weston keyboard bindings
The Weston desktop shell has a number of keyboard shortcuts. They are listed here.
Almost all keyboard shortcuts for Weston include a specified modifier mod key which is determined in the file weston.ini (5):
[shell]
binding-modifier={none | ctrl | alt | super}
The mod key is the same as the super key by default.
Thesuper key is in between <Left Ctrl> and <Left Alt>, usually a <Windows> key.
mod + Shift + F
Make active window fullscreen
mod + K
Kill active window
mod + Shift + M
Maximize active window
mod + PageUp, mod + PageDown
Zoom desktop in (or out)
mod + Tab
Switch active window
mod + Up, mod + Down
Increment/decrement active workspace number, if there are multiple
mod + Shift + Up, mod + Shift + Down
Move active window to the succeeding/preceding workspace, if possible
mod + F1/F2/F3/F4/F5/F6
Jump to the numbered workspace, if it exists
Ctrl + Alt + Backspace
If supported, terminate Weston. (Note this combination often is used to hard restart Xorg.)
Ctrl + Alt + F
Toggle if Weston is fullscreen; only works when nested under a Wayland compositor
Ctrl + Alt + S
Share output screen, if possible
Ctrl + Alt + F1/F2/F3/F4/F5/F6/F7/F8
Switch virtual terminal, if possible
super + S
Make a screenshot of the desktop
super + R
Start or stop recording video of the desktop
Weston touch / mouse bindings
There are also a number of bindings involving a mouse:
We are pleased to announce a Yocto Release for our new Tungsten700 SMARC! This release is based upon the Mediatek iot-yocto-v23.1 (Kirkstone) release and includes our 5.15 kernel. Below you will find a download link for the image as well as detailed instructions for building including a features set.
This image uses the kirkstone-mtk-v23.1branch of our yocto-manfiest repository.
To build the image, we recommend using a Docker Container so that you can build with a reproducible and stable build environment. Otherwise, you’ll need these packages installed as well as this repo tool that can be installed like this:
After some time this should build the same image as above, with the layers being at commits as per the time when repo sync was executed. If you are interested in each project revision at the time of the build, you can find a frozen manifest for those images here.
The image file will deploy to tmp/deploy/images/tungsten-700-smarc/rity-demo-image-tungsten-700-smarc.wic.img
Features list
The image built above contains the following components:
In this post, we will show how to recover a Tungsten700 SMARC System-On-Module so that the device can get up in running in fastboot mode and be flashed with software OS images.
The Tungsten700 has a DIP switch (SW1) which allows for overriding the normal boot flow and force a boot to the USB recovery mode (OTG/TypeC port). Modify its setting to match the picture below:
Procedure
After putting the SW1 Dip Switch to the ON position and powering on the board, you should see a “Mediatek” device show up in “lsusb”
~$ lsusb
...
Bus 001 Device 059: ID 0e8d:0003 MediaTek Inc. MT6227 phone
...
Now that the PC sees the USB device, download the “bootrom-tool”, which is used to load a LittleKernel binary and put the device into fastboot mode:
~$ ./bootrom-tool
Looking for MediaTek SoC matching USB device 0e8d:0003
Opening /dev/ttyACM0 using baudrate=115200
Connected to MediaTek SoC: hw_code[0x8188]
Sending bootstrap to address: 0x201000
Jumping to bootstrap at address 0x201000 in AArch64 mode
Note: For Windows users, the same procedure applies with the bootrom-tool.exe binary instead.
After running the tool, you should now see the device show up under “lsusb” as “MediaTek Inc. Fastboot”:
~$ lsusb
...
Bus 001 Device 076: ID 0e8d:201c MediaTek Inc. Fastboot
...
You should also see the device come up under “fastboot devices”:
~$ fastboot devices 0123456789ABCDEF fastboot
At this stage, you know how to recover a Tungsten700 SMARC module.
Now, you can program any software OS image of your choice. For example, Yocto can be programmed: