Quantcast
Channel: Boundary Devices

A DIYer’s Dream: MNT’s Pocket Reform Packs Modular Computing into a Tiny Footprint


Yocto Mickledore Release for i.MX 8 Platforms

0
0

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!

As usual, you’ll need to register on our site and agree to the EULA because it contains NXP content.

How to Burn

You can program the SW to eMMC using the instructions below:

programming-emmc-on-i-mx-platforms

You can also program the SW to SD Card or USB Stick via zcat and dd under Linux:

~$ zcat *boundary-image*.wic.gz | sudo dd of=/dev/sdX bs=1M

In addition, you can use the balenaEtcher utility to flash the eMMC, SD Card or USB stick via Windows or Linux:

balenaEtcher

Lastly, if using the fastboot image, you can program the eMMC via the following:

~$ fastboot flash emmc *boundary-image*.wic.sparse

Build procedure

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.

~$ mkdir ~/mickledore && cd mickledore
~/mickledore$ repo init -u https://github.com/boundarydevices/boundary-bsp-platform -b boundary-imx-6.1.22-2.0.0
~/mickledore$ repo sync

Next, setup the environment for building. For this image we will be building the fsl-imx-xwayland-boundary distro for the target machine

~/mickledore$ MACHINE=<MACHINE> DISTRO=fsl-imx-xwayland-boundary . imx-setup-release.sh -b build

Now bitbake boundary-image-multimedia-full which is equivalent to fsl-image-multimedia-full with Boundary-specific packages added such as BD-SDMAC support.

~/mickledore/build$ bitbake boundary-image-multimedia-full

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:

This version of U-Boot supports the display configuration, allowing to use any of the following displays:

Note that we’ve noticed that the NXP HDMI driver is picky when it comes to custom display timings (sometimes refuses to set the clock).

So if you are experiencing any issue with HDMI, please try entering the following commands in U-Boot in order to force the use of standard timings:

=> setenv cmd_custom 'setenv bootargs $bootargs drm_kms_helper.edid_firmware=HDMI-A-1:edid/1280x720.bin'
=> saveenv

GPU acceleration

As usual, in order to test the GPU you can use the example apps provided by Vivante:

root@<MACHINE>:~# /opt/imx-gpu-sdk/GLES2/Blur/GLES2.Blur_Wayland_XDG -d

Camera input

You can test Camera MIPI-CSI input using our OV5640 MIPI with GStreamer:

root@<MACHINE>:~# gst-launch-1.0 v4l2src device=/dev/video0 ! \
    video/x-raw,width=1280,height=720 ! waylandsink

Basler camera input

This build fully supports the Basler daA3840 8MP camera from Basler when using our Nitrogen 8M Plus which is part of our Evaluation Kit:

The isp-vvcam driver and imx8-isp service are loaded automatically when the camera is detected.

From there a simple GStreamer pipeline will allow you to see the stream:

root@nitrogen8mp:~# gst-launch-1.0 -v v4l2src device=/dev/video3 ! waylandsink
...
[  352.348796] wdr3 res: 1920 1080 
[  352.352471] enter isp_mi_start
[  357.581179] ###### 62.42 fps ######
[  362.771924] ###### 62.42 fps ######

IMX219 camera input

We now have support for the IMX219 camera using our Nitrogen8M Plus SMARC. We tested using the Arducam imx219:

It can be tested with gstreamer:

root@nitrogen8mp:~# gst-launch-1.0 -v v4l2src device=/dev/video3 ! waylandsink

Ethernet

Once the eth0 interface is up, you can use iperf3 to check Ethernet performances:

root@<MACHINE>:~# iperf3 -c 192.168.1.60                                                                                                                         
Connecting to host 192.168.1.60, port 5201
[  5] local 192.168.1.13 port 32880 connected to 192.168.1.60 port 5201
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  1.09 GBytes   938 Mbits/sec    0             sender
[  5]   0.00-10.04  sec  1.09 GBytes   932 Mbits/sec                  receiver

Wi-Fi

We now have support for the LWB5+ Wifi+Bluetooth module! You can test Wi-Fi with nmcli as shown below:

root@<MACHINE>:~# nmcli d wifi connect <network_name> password <password>
root@<MACHINE>:~# iw wlan0 link
Connected to a4:3e:51:08:54:f6 (on wlan0)
        SSID: Jabu_5GHz
        freq: 5240
        RX: 3243 bytes (31 packets)
        TX: 9117 bytes (48 packets)
        signal: -79 dBm
        tx bitrate: 15.0 MBit/s MCS 0 40MHz short GI
root@<MACHINE>:~# ping google.com -Iwlan0                                                                                                                       
PING google.com (216.58.198.206): 56 data bytes
64 bytes from 216.58.198.206: seq=0 ttl=55 time=3.470 ms
...

Bluetooth

For products with a Silex bluetooth module, you’ll be able to connect using our handy silex-uart script with the following commands:

root@<MACHINE>:~# hciconfig hci0 up
root@<MACHINE>:~# hcitool scan
Scanning ...

VPU decoding

If your platform supports VPU decoding, here is an example on how to test it using the gplay tool:

root@<MACHINE>:~# wget http://linode.boundarydevices.com/videos/Hobbit-1080p.mov
root@<MACHINE>:~# gplay-1.0 /home/root/Hobbit-1080p.mov

VPU encoding

Here is a simple example that shows how to encode a video stream from the camera into H.264 using the VPU encoder:

root@<MACHINE>:~# gst-launch-1.0 -v -e v4l2src device=/dev/video0 ! 'video/x-raw,width=1920,height=1080' \
                    ! vpuenc_h264 ! filesink location=test.h264
^C
root@<MACHINE>:~# gst-launch-1.0 filesrc location=test.h264 typefind=true ! 'video/x-h264' ! \
                    h264parse ! vpudec ! waylandsink

CAN

For platforms with CAN, you’ll be able to bring up the interface(s) using this following command:

root@<MACHINE>:~# ip link set can0 up type can bitrate 500000

From this point, you can use commands such as cansend and candump to send or display messages on the bus respectively.

NPU support

NPU support is fully integrated into this build when using our Nitrogen 8M Plus with TensorFlowLite and ARMNN support of the NPU.

You can find various example demos here:

IMX-MACHINE-LEARNING-UG.pdf

 

If you have any issues, please email support@boundarydevices.com

The post Yocto Mickledore Release for i.MX 8 Platforms appeared first on Boundary Devices.

Coming Soon: Tungsten700 SMARC with Wi-Fi 6 + Bluetooth 5.3

Understanding the SMARC Standard and What It Can Do For Your Design

Buildroot 2023.08 release for i.MX platforms

0
0

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!Buildroot

For the impatient

You can download pre-built Buildroot 2023.08 images from here:

In order to flash those images you can follow our video on this topic:

Or for those fluent in command lines, you can simply use zcat:

~$ zcat 2023*br2023.08-nitrogen*.img.gz | sudo dd of=/dev/sdX bs=1M

What’s new?

Buildroot 2023.08 release

It would be too long of a list to enumerate all the changes Buildroot went through since the last release.

For recent changes, we invite you to check the last release announcement:

We’ll focus on the i.MX changes for this release in the next sections.

Boundary Devices layer

As usual, we provide our own Boundary Devices external layer:

This includes the following custom configurations

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:

Otherwise you can follow Buildroot documentation to know the host requirements:

Once your development environment is setup properly, you can

  1.  Download the source code. To ease the repo cloning process, we decided to create a manifest to match what is done for Yocto/Android:
~$ sudo apt-get install repo
~$ mkdir ~/br2023.08 && cd br2023.08
~/br2023.08$ repo init -u https://github.com/boundarydevices/buildroot-manifest -b 2023.08.x
~/br2023.08$ repo sync
  1. Create an output folder for your configuration:
~/br2023.08$ make BR2_EXTERNAL=$PWD/buildroot-external-boundary/ 
  -C $PWD/buildroot/ O=$PWD/output nitrogen8mm_qt5_gst1_defconfig
~/br2023.08$ cd output
  1. Build the image
~/br2023.08/output$ make
  1. 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
# wget http://linode.boundarydevices.com/videos/trailer_1080p_h264_mp3.avi -P /root/
# gst-launch-1.0 filesrc location=/root/trailer_1080p_h264_mp3.avi ! 
  decodebin ! waylandsink

  • If you have our OV5640 5MP MIPI camera, you can check the GStreamer video capture
# gst-launch-1.0 v4l2src device=/dev/video0 ! video/x-raw,width=1280,height=720 ! 
  waylandsink

  • This build fully supports the Basler daA3840 8MP camera from Basler when using our Nitrogen 8M Plus
# gst-launch-1.0 -v v4l2src device=/dev/video2 ! waylandsink
...
[ 352.348796] wdr3 res: 1920 1080
[ 352.352471] enter isp_mi_start
[ 357.581179] ###### 62.42 fps ######
[ 362.771924] ###### 62.42 fps ######

 

# gst-launch-1.0 -v v4l2src device=/dev/video2 ! waylandsink

  • This build also includes qt5 and examples can be run from “/usr/lib/qt/examples”
# cd /usr/lib/qt/examples/
# ls
README network qtestlib svg
bluetooth nfc quick virtualkeyboard
corelib opengl quickcontrols vulkan
dbus positioning quickcontrols2 wayland
examples.pro qml script widgets
gui qmltest sensors xml
location qpa serialbus
multimedia qt3d serialport
multimediawidgets qtconcurrent sql
  • As for Wi-Fi connectivity, the image embeds the minimum to get you started
# wpa_passphrase MYSSID MYPASSWORD >> /etc/wpa_supplicant.conf
# /etc/init.d/S50wpa-supplicant stop
# sleep 1
# /etc/init.d/S50wpa-supplicant start

# iw wlan0 link
Connected to a4:3e:51:08:54:f6 (on wlan0)
SSID: MYSSID
freq: 5660
RX: 47685 bytes (747 packets)
TX: 2054 bytes (0 packets)
signal: -58 dBm
tx bitrate: 150.0 MBit/s MCS 7 40MHz short GI
# udhcpc -i wlan0
udhcpc: started, v1.31.1
udhcpc: sending discover
udhcpc: sending select for 192.168.1.46
udhcpc: lease of 192.168.1.46 obtained, lease time 86400
deleting routers
adding dns 192.168.1.1
# ping google.com -I wlan0
PING google.com (216.58.198.206): 56 data bytes
64 bytes from 216.58.198.206: seq=0 ttl=116 time=6.971 ms
64 bytes from 216.58.198.206: seq=1 ttl=116 time=13.145 ms
...
  • Finally, if you want to use Bluetooth connectivity, the procedure goes as follows
# echo 1 > /sys/class/rfkill/rfkill0/state
# hcitool scan
Scanning ...
48:C1:AC:00:D7:DCVoyager PRO+

The post Buildroot 2023.08 release for i.MX platforms appeared first on Boundary Devices.

Finding Zen in Your Embedded Development: How Dojo Five & Laird Connectivity Speed You To Market

How to create and use the Yocto SDK

0
0

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.

1- Building the SDK Installer

In this example, we will use our boundary-image-multimedia-full image to base the SDK on.

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:

~$ bitbake boundary-image-multimedia-full -c populate_sdk

2- Run the SDK Installer

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:

~$ source /home/Yocto_SDK/environment-setup-armv8a-poky-linux

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:

all: helloworld

helloworld: helloworld.c
${CC} -o helloworld helloworld.c

clean:
rm helloworld

Next run “make” to compile our helloworld app:

~$ make
aarch64-poky-linux-gcc -march=armv8-a+crc+crypto -fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/home/chris/Work/Yocto_Mickledore_SDK/sysroots/armv8a-poky-linux -o helloworld helloworld.c

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.

~$ printenv CC
aarch64-poky-linux-gcc -march=armv8-a+crc+crypto -fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/home/chris/Work/Yocto_Mickledore_SDK/sysroots/armv8a-poky-linux

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:

project(helloworld)
add_executable(helloworld helloworld.c)
set(CMAKE_TOOLCHAIN_FILE $ENV{OE_CMAKE_TOOLCHAIN_FILE})

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.

~$ printenv | grep OE_CMAKE_TOOLCHAIN_FILE
OE_CMAKE_TOOLCHAIN_FILE=/home/Yocto_SDK/sysroots/x86_64-pokysdk-linux/usr/share/cmake/OEToolchainConfig.cmake

Next, we can run cmake to generate our makefile:

~$ 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:

AC_INIT(hello,0.1)
AM_INIT_AUTOMAKE([foreign])
AC_PROG_CC
AC_CONFIG_FILES(Makefile)
AC_OUTPUT

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!

The post How to create and use the Yocto SDK appeared first on Boundary Devices.

Debian 12 Bookworm unified image for Nitrogen8 boards

0
0

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:

For Nitrogen8M, Nitrogen8M SOM, Nitrogen8M Mini, Nitrogen8M Mini SOM, Nitrogen8M Nano SOM, Nitrogen8M Plus SOM, Nitrogen8MP SMARC:

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:

debian@bookworm-dev64:~$ sudo mkdir /root/.ssh
debian@bookworm-dev64:~$ sudo nano /root/.ssh/authorized_keys
... paste content of $HOME/.ssh/id_rsa.pub here
debian@bookworm-dev64:~$ sudo chmod 600 /root/.ssh/auth*
debian@bookworm-dev64:~$ sudo chmod 600 /root/.ssh/

What’s supported?

Since the images above include our stable 5.15.x kernel, essentially everything is supported, including:

  • Vivante GPU accelerations for Wayland
  • The Hantro Video Processing Unit supports the following decoders:
    • video/x-h265
    • video/x-vp9
    • video/x-h264
    • video/x-vp8
    • video/mpeg
    • video/x-h263
    • video/x-raw
  • BD-SDMAC WiFi/BT modules support, Laird Sterling-LWB5+ support, AzureWave AW-XB468NF (MediaTek Model MT7921)
  • 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.

debian@bookworm-dev64mp:~$ nmcli radio wifi on
debian@bookworm-dev64mp:~$ nmcli d wifi list
IN-USE  BSSID              SSID             MODE   CHAN  RATE        SIGNAL  BA>
        A4:3E:51:08:54:F5  Jabu             Infra  1     130 Mbit/s  62      ▂▄>
        A4:3E:51:08:54:F6  Jabu_5GHz        Infra  36    405 Mbit/s  57      ▂▄>

debian@bookworm-dev64mp:~$ sudo nmcli d wifi connect Jabu_5GHz password XXXXXX
Device 'wlan0' successfully activated with '4ed596ea-9f8c-48ea-8e0e-5e190e2fecc9'.
debian@bookworm-dev64mp:~$ ifconfig wlan0
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.61  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::2ae4:f7d2:3cc1:486d  prefixlen 64  scopeid 0x20
        inet6 2a01:cb00:f55:7f00:3122:4891:67c4:faa7  prefixlen 64  scopeid 0x0
        inet6 2a01:cb00:f55:7f00:6c92:60ad:c2ad:68cc  prefixlen 64  scopeid 0x0
        ether 08:3a:88:20:78:cc  txqueuelen 3000  (Ethernet)
        RX packets 67  bytes 7854 (7.8 KB)
        RX errors 0  dropped 9  overruns 0  frame 0
        TX packets 69  bytes 7666 (7.6 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

This allows you to use Wi-Fi right out of the box without any extra setup required.

i.MX 8M Plus support

This is the first Debian Bookworm image to officially support the i.MX 8M Plus CPU and therefore our Nitrogen8MP SOM and the Nitrogen8M Plus SMARC SOM

The support includes:

  • VPU decode/encode
  • GPU 3D & 2D support
  • NPU integration (TFLite & ARMNN)
  • ISP + Basler daA3840 support and SONY imx219 sensor support
  • WiFi support Silex SX-SDPAC, Laird Sterling-LWB5+, AzureWave AW-XB468NF (MediaTek Model MT7921)
Nitrogen8M Plus SOM

 


GPU SDK Bloom demo

Vulkan Instanced Mesh Rendering

Hobbit Trailer video playing
Video streaming from youtube “Zaitochi vs. Predator” ( https://www.youtube.com/watch?v=NsbVTPftcgs )

As I mentioned before, the system boots to Weston compositor.

If you don’t want to start Weston at boot automatically, you have to disable the service, you have to type the following:

debian@bookworm-dev64:~$ sudo systemctl disable weston.service
debian@bookworm-dev64:~$ sudo systemctl mask weston.service

If you want to enable the autostart again you need to type:

debian@bookworm-dev64:~$ sudo systemctl unmask weston.service
debian@bookworm-dev64:~$ sudo systemctl enable weston.service

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.

The super 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:

<Touch>, <Left button>, <Right button>
Activate clicked window

super + Alt + <Vertical scroll>
Change the opacity of a window

mod + <Vertical scroll>
Zoom/magnify the visible desktop

mod + <Left button>
Click and drag to move a window

mod + Shift + <Left button>,  mod + <Right button>,  mod + <Touch>
Click and drag to resize a window

mod + <Middle button>
Rotate the window (if supported)


 

The post Debian 12 Bookworm unified image for Nitrogen8 boards appeared first on Boundary Devices.


Tungsten700 SMARC Yocto Kirkstone Release

0
0

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.

Prebuilt Image

You can download the Yocto image from here:

How to Burn

The .zip archive include all the files to be flashed using fastboot.

First you need to enter fastboot mode from U-Boot prompt:

=> fastboot 0

If you are unable to get into fastboot mode from U-Boot, you can follow the this blog to recover your Tungsten700.

Next, unzip image:

~$ unzip *-tungsten-700-smarc-yocto-kirkstone.zip -d Tungsten700-Yocto
~$ cd Tungsten700-Yocto

Finally, flash the image(s):

Flash bl2.img to mmc0boot0 partition:

~/Tungsten700-Yocto$ fastboot flash mmc0boot0 bl2.img

Flash wic.img to mmc0 partition:

~/Tungsten700-Yocto$ fastboot flash mmc0 rity-demo-image-tungsten-700-smarc.wic.img

Build procedure

This image uses the kirkstone-mtk-v23.1 branch 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:

~$ sudo apt-get install repo

Now we are ready to build the image.

First, download the BSP yocto layers:

~$ mkdir ~kirkstone-mtk && cd kirstone-mtk
~/kirkstone-mtk$ repo init -u https://github.com/boundarydevices/yocto-manifest.git -b kirkstone-mtk-v23.1 
~/kirkstone-mtk$ repo sync

Then, setup the environment for building.

~/kirkstone-mtk$ TEMPLATECONF=$PWD/src/meta-boundary/conf source src/poky/oe-init-build-env
~/kirkstone-mtk$ export BUILD_DIR=`pwd`

Finally, set the MACHINE to be tungsten-700-smarc and bitbake rity-demo-image

~/kirkstone-mtk/build$ MACHINE=tungsten-700-smarc bitbake rity-demo-image

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:

The next sub-sections will describe how to test most features.

GPU acceleration

To test GPU you can use glmark2:

root@tungsten-700-smarc:~# glmark2-es2-wayland --fullscreen


Ethernet

Once the eth0 interface is up, you can use iperf3 to check Ethernet performances:

root@tungsten-700-smarc:~# iperf3 -c 192.168.1.60                                                                                                                         
Connecting to host 192.168.1.60, port 5201
[  5] local 192.168.1.13 port 32880 connected to 192.168.1.60 port 5201
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  1.09 GBytes   938 Mbits/sec    0             sender
[  5]   0.00-10.04  sec  1.09 GBytes   932 Mbits/sec                  receiver

Wi-Fi

You can test Wi-Fi with nmcli as shown below:

root@tungsten-700-smarc:~# nmcli d wifi connect <network_name> password <password>
Device 'wlan0' successfully activated with '796c47ef-fb49-4b9b-9c7f-dc9d7250568f'.
root@tungsten-700-smarc:~# iw wlan0 link
Connected to 9a:dc:97:07:5b:5a (on wlan0)
        SSID: golfcourse
        freq: 5520
        RX: 30561 bytes (215 packets)
        TX: 7899 bytes (63 packets)
        signal: -59 dBm
        rx bitrate: 864.8 MBit/s 80MHz HE-MCS 8 HE-NSS 2 HE-GI 0 HE-DCM 0
        tx bitrate: 720.6 MBit/s 80MHz HE-MCS 7 HE-NSS 2 HE-GI 0 HE-DCM 0

        bss flags:      short-slot-time
        dtim period:    3
        beacon int:     100
root@tungsten-700-smarc:~# ping google.com -Iwlan0                                                                                                                       
PING google.com (216.58.198.206): 56 data bytes
64 bytes from 216.58.198.206: seq=0 ttl=55 time=3.470 ms
...

Bluetooth

You can test bluetooth with hciconfig:

root@tungsten-700-smarc:~# hciconfig hci0 up
root@tungsten-700-smarc:~# hcitool scan
Scanning ...
        4C:BA:D7:64:CB:CD       Iphone

VPU decoding

You can test VPU with gstreamer:

root@tungsten-700-smarc:~# wget http://linode.boundarydevices.com/videos/SKYFALL-4K.mp4
root@tungsten-700-smarc:~# gst-launch-1.0 -v filesrc location=/home/root/SKYFALL-4K.mp4 \
    ! parsebin ! v4l2h264dec ! queue \
    ! v4l2convert output-io-mode=dmabuf-import capture-io-mode=dmabuf ! queue \ 
    ! waylandsink fullscreen=true


If you have any issues, please email support@boundarydevices.com

The post Tungsten700 SMARC Yocto Kirkstone Release appeared first on Boundary Devices.

How to recover a Tungsten700 SMARC

0
0

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:

~$ wget http://linode.boundarydevices.com/mediatek/tungsten700-recovery.zip
~$ unzip tungsten700-recovery.zip 

Then, run the tool:

~$ ./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:

~$ fastboot flash mmc0boot0 bl2.img
~$ fastboot flash mmc0 rity-demo-image-tungsten-700-smarc.wic.img

Note: For Windows users, please follow the instructions below to install the Android tools (including fastboot):

For more OS options and flashing procedure, we recommend looking at our Wiki to see all the latest releases.

 

If you have any issues, please email support@boundarydevices.com.

The post How to recover a Tungsten700 SMARC appeared first on Boundary Devices.





Latest Images