Check out the new article published about Boundary Devices’ Nitrogen Access Control Suite Scanners.
Kansas City Chiefs issue NFC tickets to premium suite guests
The post Kansas City Chiefs Issue NFC Tickets to Premium Suite Guests appeared first on Boundary Devices.
We are pleased to announce a Yocto release for our Nitrogen8M Nano SBC based on the i.MX8M NANO processor. Below you will find the download link for the image as well as detailed instructions for the build including a features set.
You can download the Yocto image from here:
As usual, you’ll need to register on our site and agree to the EULA because it contains NXP content.
The image is a SD card image that can be restored using zcat and dd under Linux.
~$ zcat *boundary-image*.wic.gz | sudo dd of=/dev/sdX bs=1M
In addition, you can use the etcher utility to flash the SD Card or USB stick via Windows or Linux:
This image uses the zeus branch of our boundary-bsp-platform repository.
To build the image, 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 ~/yocto-imx8m-nano && cd yocto-imx8m-nano ~/yocto-imx8m-nano$ repo init -u http://github.com/boundarydevices/boundary-bsp-platform -b zeus ~/yocto-imx8m-nano$ repo sync
Setup the environment for building, in this example we will be building our boundary-wayland distro for nitrogen8mm
~/yocto-imx8m-nano$ MACHINE=nitrogen8_2eth DISTRO=boundary-wayland . setup-environment build
Now bitbake boundary-image-multimedia-full which is equivalent to fsl-image-multimedia-full with Boundary-specific packages such as BD-SDMAC support
~/yocto-imx8m-nano/build$ bitbake boundary-image-multimedia-full
After some time this should build the same image as above.
The image file will deploy to tmp/deploy/images/{MACHINE}/boundary-image-multimedia-full-{MACHINE}.wic.gz.
The image built above contains the following components:
The next sub-sections will describe how to test most features.
Please make sure your platform includes the latest U-Boot for i.MX8M MINI:
This version of U-Boot supports the display configuration, allowing to use any of the following displays:
In order to test the GPU, you can either use the standard Weston EGL programs or the ones provided by Vivante.
Here are a few examples:
root@nitrogen8mm:~# weston-simple-egl & root@nitrogen8mm:~# cd /opt/viv_samples/vdk/ root@nitrogen8mm:/opt/viv_samples/vdk# ./tutorial7
Camera MIPI-CSI input can be checked using our OV5640 MIPI with GStreamer:
root@nitrogen8mm:~# gst-launch-1.0 v4l2src device=/dev/video0 ! \
video/x-raw,width=1280,height=720 ! glimagesink
Once the eth0 interface is up, you can use ping to check internet connectivity:
root@nitrogen82eth:~# ping google.com -I eth0 PING google.com (172.217.14.78): 56 data bytes 64 bytes from 172.217.14.78: seq=0 ttl=56 time=12.117 ms 64 bytes from 172.217.14.78: seq=1 ttl=56 time=16.837 ms 64 bytes from 172.217.14.78: seq=2 ttl=56 time=21.280 ms ^C --- google.com ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 12.117/16.744/21.280 ms
Once the eth1 interface is up, you can use ping to check internet connectivity:
root@nitrogen82eth:~# ping google.com -I eth1 PING google.com (172.217.14.78): 56 data bytes 64 bytes from 172.217.14.78: seq=0 ttl=56 time=14.271 ms 64 bytes from 172.217.14.78: seq=1 ttl=56 time=12.400 ms 64 bytes from 172.217.14.78: seq=2 ttl=56 time=18.015 ms ^C --- google.com ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 12.400/14.895/18.015 ms root@nitrogen82eth:~#
Same goes for the Wi-Fi that can be tested just as easily:
root@nitrogen8mm:~# nmcli d wifi connect <network_name> password <password>
root@nitrogen8mm:~# 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@nitrogen8mm:~# 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
...
You’ll be able to connect using these commands:
root@nitrogen8mm:~# hciconfig hci0 up root@nitrogen8mm:~# hcitool scan Scanning ... 11:22:DE:AD:BE:EF Some Device
You’ll be able to bring up the interface using these commands:
root@nitrogen8mm:~# ip link set can0 up type can bitrate 500000 root@nitrogen8mm:~# ifconfig can0 up
From this point, you can use commands such as candsend and candump to send or display messages on the bus.
As usual, feel free to leave a comment below to share your experience.
The post Yocto release for i.MX8M NANO appeared first on Boundary Devices.
Download the new article from Timesys by clicking the download link below.
Timesys-solution-to-manage-vulnerabilities.pdfThe post Timesys’ Vigiles Solution for Monitoring and Managing Security Vulnerabilities in Embedded System Devices appeared first on Boundary Devices.
We are pleased to announce a new Yocto release Zeus for our Nitrogen8M Mini SBC based on the i.MX8M MINI processor. Below you will find the download link for the image as well as detailed instructions for the build including a features set.
You can download the Yocto image from here:
As usual, you’ll need to register on our site and agree to the EULA because it contains NXP content.
The image is a SD card image that can be restored using zcat and dd under Linux.
~$ zcat *boundary-image*.wic.gz | sudo dd of=/dev/sdX bs=1M
In addition, you can use the etcher utility to flash the SD Card or USB stick via Windows or Linux:
This image uses the zeus branch of our boundary-bsp-platform repository.
To build the image, 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 ~/yocto-imx8m && cd yocto-imx8mm ~/yocto-imx8mm$ repo init -u http://github.com/boundarydevices/boundary-bsp-platform -b zeus ~/yocto-imx8mm$ repo sync
Setup the environment for building, in this example we will be building our boundary-wayland distro for nitrogen8mm.
~/yocto-imx8mm$ MACHINE=nitrogen8mm DISTRO=boundary-wayland . setup-environment build
Now bitbake boundary-image-multimedia-full which is equivalent to fsl-image-multimedia-full with Boundary-specific packages such as BD-SDMAC support
~/yocto-imx8mm/build$ bitbake boundary-image-multimedia-full
After some time this should build the same image as above.
The image file will deploy to tmp/deploy/images/{MACHINE}/boundary-image-multimedia-full-{MACHINE}.wic.gz.
The image built above contains the following components:
The next sub-sections will describe how to test most features.
Please make sure your platform includes the latest U-Boot for i.MX8M MINI:
This version of U-Boot supports the display configuration, allowing to use any of the following displays:
In order to test the GPU, you can either use the standard Weston EGL programs or the ones provided by Vivante.
Here are a few examples:
root@nitrogen8mm:~# weston-simple-egl & root@nitrogen8mm:~# cd /opt/viv_samples/vdk/ root@nitrogen8mm:/opt/viv_samples/vdk# ./tutorial7
The i.MX8MM processor can decode videos with a resolution up to 1080p so here is an example using GPlay tool:
root@nitrogen8mm:~# wget http://linode.boundarydevices.com/videos/Hobbit-1080p.mov root@nitrogen8mm:~# gplay-1.0 --video-sink=glimagesink Hobbit-1080p.mov
Camera MIPI-CSI input can be checked using our OV5640 MIPI with GStreamer:
root@nitrogen8mm:~# gst-launch-1.0 v4l2src device=/dev/video0 ! \
video/x-raw,width=1280,height=720 ! glimagesink
Once the eth0 interface is up, you can use iperf3 to check Ethernet performances:
root@nitrogen8mm:~# 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
Same goes for the Wi-Fi that can be tested just as easily:
root@nitrogen8mm:~# nmcli d wifi connect <network_name> password <password>
root@nitrogen8mm:~# 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@nitrogen8mm:~# 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
...
For products with Bluetooth, you’ll be able to connect using these commands:
root@localhost:~# echo 0 > /sys/class/rfkill/rfkill0/state root@localhost:~# echo 1 > /sys/class/rfkill/rfkill0/state root@localhost:~# hciattach /dev/ttymxc0 qca 3000000 -t30 flow Current Product ID : 0x00000008 Current Patch Version : 0x0111 Current ROM Build Version : 0x0302 Current SOC Version : 0x00000023 qca_soc_init: Rome Version (0x03020023) ==================================================== TLV Type : 0x1 Length : 33060 bytes Total Length : 32804 bytes Patch Data Length : 32780 bytes Signing Format Version : 0x1 Signature Algorithm : 0x2 Event Handling : 0x3 Reserved : 0x0 Product ID : 0x0008 Rom Build Version : 0x0302 Patch Version : 0x0114 Reserved : 0x8000 Patch Entry Address : 0x19b08 ==================================================== ==================================================== TLV Type : 0x2 Length : 1992 bytes Failed to open /etc/bluetooth/firmware.conf Ignoring invalid deep sleep config value Failed to open /etc/bluetooth/firmware.conf ==================================================== Device setup complete root@localhost:~# echo 1 > /sys/class/rfkill/rfkill2/state root@localhost:~# hciconfig hci0 up root@localhost:~# hcitool scan Scanning ... 11:22:DE:AD:BE:EF Some Device
For CAN, you’ll be able to bring up the interface using these commands:
root@nitrogen8mm:~# ip link set can0 up type can bitrate 500000 root@nitrogen8mm:~# ifconfig can0 up
From this point, you can use commands such as cansend and candump to send or display messages on the bus.
As usual, feel free to leave a comment below to share your experience.
The post Zeus Yocto release for i.MX8M MINI appeared first on Boundary Devices.
We are pleased to announce a new Yocto release Zeus for our Nitrogen8M SBC. Below you will find the download link for the image as well as detailed instructions for the build including a features set.
You can download the Yocto image from here:
As usual, you’ll need to register on our site and agree to the EULA because it contains NXP content.
Since the Nitrogen8M board has no SD card slot, you need to program this image via fastboot or
using U-Boot USB Mass Storage Gadget. Instructions on programming the SW can be found below:
However, you can still flash the image onto an SD card and use an SD Card to USB adapter or flash to a 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 etcher utility to flash the SD Card or USB stick via Windows or Linux:
This image uses the zeus branch of our boundary-bsp-platform repository.
To build the image, 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 ~/yocto-imx8m && cd yocto-imx8m ~/yocto-imx8m$ repo init -u http://github.com/boundarydevices/boundary-bsp-platform -b zeus ~/yocto-imx8m$ repo sync
Setup the environment for building, in this example we will be building our boundary-wayland distro for nitrogen8m.
~/yocto-imx8m$ MACHINE=nitrogen8m DISTRO=boundary-wayland . setup-environment build
Now bitbake boundary-image-multimedia-full which is equivalent to fsl-image-multimedia-full with Boundary-specific packages such as BD-SDMAC support
~/yocto-imx8m/build$ bitbake boundary-image-multimedia-full
After some time this should build the same image as above.
The image file will deploy to tmp/deploy/images/{MACHINE}/boundary-image-multimedia-full-{MACHINE}.wic.gz.
The image built above contains the following components:
The next sub-sections will describe how to test most features.
Please make sure your platform includes the latest U-Boot for i.MX8M:
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
In order to test the GPU, you can either use the standard Weston EGL programs or the ones provided by Vivante.
Here are a few examples:
root@nitrogen8m:~# weston-simple-egl & root@nitrogen8m:~# cd /opt/viv_samples/vdk/ root@nitrogen8m:/opt/viv_samples/vdk# ./tutorial7
The i.MX8MQ processor can decode videos with a resolution up to 4K so here is an example using GPlay tool:
root@nitrogen8m:~# wget http://linode.boundarydevices.com/videos/SKYFALL-4K.mp4 root@nitrogen8m:~# gplay-1.0 --video-sink=glimagesink SKYFALL-4K.mp4
Camera MIPI-CSI input can be checked using our OV5640 MIPI with GStreamer:
Camera inputroot@nitrogen8m:~# gst-launch-1.0 v4l2src device=/dev/video0 ! \
video/x-raw,width=1280,height=720 ! glimagesink
Once the eth0 interface is up, you can use iperf3 to check Ethernet performances:
root@nitrogen8m:~# 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
Same goes for the Wi-Fi that can be tested just as easily:
root@nitrogen8m:~# nmcli d wifi connect <network_name> password <password>
root@nitrogen8m:~# 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@nitrogen8m:~# 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
...
For products with Bluetooth, you’ll be able to connect using these commands:
root@localhost:~# echo 0 > /sys/class/rfkill/rfkill0/state root@localhost:~# echo 1 > /sys/class/rfkill/rfkill0/state root@localhost:~# hciattach /dev/ttymxc2 qca 3000000 -t30 flow Current Product ID : 0x00000008 Current Patch Version : 0x0111 Current ROM Build Version : 0x0302 Current SOC Version : 0x00000023 qca_soc_init: Rome Version (0x03020023) ==================================================== TLV Type : 0x1 Length : 33060 bytes Total Length : 32804 bytes Patch Data Length : 32780 bytes Signing Format Version : 0x1 Signature Algorithm : 0x2 Event Handling : 0x3 Reserved : 0x0 Product ID : 0x0008 Rom Build Version : 0x0302 Patch Version : 0x0114 Reserved : 0x8000 Patch Entry Address : 0x19b08 ==================================================== ==================================================== TLV Type : 0x2 Length : 1992 bytes Failed to open /etc/bluetooth/firmware.conf Ignoring invalid deep sleep config value Failed to open /etc/bluetooth/firmware.conf ==================================================== Device setup complete root@localhost:~# echo 1 > /sys/class/rfkill/rfkill2/state root@localhost:~# hciconfig hci0 up root@localhost:~# hcitool scan Scanning ... 11:22:DE:AD:BE:EF Some Device
As usual, feel free to leave a comment below to share your experience.
The post Zeus Yocto release for i.MX8MQ appeared first on Boundary Devices.
This blog post will introduce the Universal Update Utility (UUU) from NXP.
For many years, Freescale provided MFGTools / sb_loader binaries in order to flash empty devices leveraging the USB recovery feature of the i.MX family.
However these tools were only meant for Windows Host. Therefore Boundary Devices decided, back in 2010, to develop its own Linux-based tool called imx-usb-loader.
This latter has been used by many for years, maintained by us with the help of the community.
But in 2018, NXP decided to unify their tools, creating a new one from scratch called UUU.
Let’s see the benefits of using that new tool and how it compares to ours.
First of all, UUU provides the same features as imx-usb-loader:
But it also includes some new features:
Note that this blog post will focus on the recovery process part, flashing will be covered in another blog post.
We also see the following advantages in using it:
As of this writing, Boundary Devices will no longer actively maintain imx-usb-loader.
We will now be focusing on using and contributing to UUU.
That being said, if the community still sees a need for imx-usb-loader, we will still accept pull-requests.
If you are reading this, it most likely means that your platform is not booting any longer.
This procedure will help you recover it by using the NXP USB recovery SDP protocol:
All our platforms have a DIP switch which allows to override the normal boot flow and force a boot to the USB recovery mode (OTG port).
You can either read the manual of your device or look at our previous post on the subject to locate the switch:
Unbricking your Boundary Devices platform
For i.MX6/7 devices it should look like:
$ lsusb | grep -E 'Freescale|NXP' Bus 001 Device 079: ID 15a2:0061 Freescale Semiconductor, Inc. i.MX 6Solo/6DualLite SystemOnChip in RecoveryMode
For i.MX8 devices, it should look like:
$ lsusb | grep -E 'Freescale|NXP' Bus 001 Device 080: ID 1fc9:012b NXP Semiconductors i.MX 8M Dual/8M QuadLite/8M Quad Serial Downloader
Pre-built binaries for both Windows and Linux are available on the Github project page:
https://github.com/NXPmicro/mfgtools/releases
As of this writing, latest release is v1.3.154 so the binaries are:
https://github.com/NXPmicro/mfgtools/releases/download/uuu_1.3.154/uuu for Linux
https://github.com/NXPmicro/mfgtools/releases/download/uuu_1.3.154/uuu.exe for Windows
~/Downloads$ chmod +x uuu
~/Downloads$ ./uuu -udev
SUBSYSTEM=="usb", ATTRS{idVendor}=="1fc9", ATTRS{idProduct}=="012f", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="1fc9", ATTRS{idProduct}=="0129", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="1fc9", ATTRS{idProduct}=="0147", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="15a2", ATTRS{idProduct}=="004f", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="1fc9", ATTRS{idProduct}=="013e", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="1fc9", ATTRS{idProduct}=="0146", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="15a2", ATTRS{idProduct}=="0076", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="15a2", ATTRS{idProduct}=="0054", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="15a2", ATTRS{idProduct}=="0061", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="15a2", ATTRS{idProduct}=="0063", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="15a2", ATTRS{idProduct}=="0071", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="15a2", ATTRS{idProduct}=="007d", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="15a2", ATTRS{idProduct}=="0080", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="1fc9", ATTRS{idProduct}=="0128", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="1fc9", ATTRS{idProduct}=="0126", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="1fc9", ATTRS{idProduct}=="0135", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="1fc9", ATTRS{idProduct}=="0134", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="1fc9", ATTRS{idProduct}=="012b", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="0525", ATTRS{idProduct}=="b4a4", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="0525", ATTRS{idProduct}=="b4a4", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="0525", ATTRS{idProduct}=="b4a4", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="3016", ATTRS{idProduct}=="1001", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="3016", ATTRS{idProduct}=="1001", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="066f", ATTRS{idProduct}=="9afe", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="066f", ATTRS{idProduct}=="9bff", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="0525", ATTRS{idProduct}=="a4a5", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="18d1", ATTRS{idProduct}=="0d02", MODE="0666"
1: put above udev run into /etc/udev/rules.d/99-uuu.rules
sudo sh -c "uuu -udev >> /etc/udev/rules.d/99-uuu.rules"
2: update udev rule
sudo udevadm control --reload-rules
Our build server automatically builds latest U-Boot version and shares every binary at this address:
http://linode.boundarydevices.com/u-boot-images/
The naming should be explicit enough, for instance the Nitrogen8M board needs the u-boot.nitrogen8m binary.
If unsure, please contact us, we will be happy to tell you which binary to use.
You can simply run the tool with the binary as its only argument in order to send the bootloader to the device.
Here is an example for Nitrogen6x:
~/Downloads$ ./uuu u-boot.nitrogen6q uuu (Universal Update Utility) for nxp imx chips -- libuuu_1.3.154-0-g47ddef5 Success 1 Failure 0 1:13 2/ 2 [Done ] SDP: done
For i.MX8MQ/M/N, the tool first loads the SPL bootloader, then this latter re-enumerates itself with different USB identifiers.
So you can either run the same command twice, or use the tool as a daemon which will automatically detect what to do depending on the USB IDs.
Here is an example for Nitrogen8M:
~/Downloads$ ./uuu -d u-boot.nitrogen8m uuu (Universal Update Utility) for nxp imx chips -- libuuu_1.3.154-0-g47ddef5 Success 2 Failure 0 1:13 3/ 3 [Done ] SDPV: done
Now that your board is booting U-Boot properly, you can then follow this blog post to flash U-Boot into NOR/eMMC:
As always, let us know your experiences either by e-mail to support@boundarydevices.com or on NXP Community Forum.
The post Recovering i.MX platforms using UUU appeared first on Boundary Devices.
We are pleased to announce a partnership with Balena and provide support for balenaOS on Nitrogen8M Mini. Use this guide to provision balenaOS on the Nitrogen8M Mini successfully. You can also try one of balena’s starter projects via balenaLabs on GitHub to test your newly provisioned board. Get more information on their website.
Please follow the steps below in order to get up and running with a balenaOS on Nitrogen8M Mini
Follow the URL:
https://dashboard.balena-cloud.com/signup
Either signup with Google Single Sign-on, Github, or provide an email address to sign up.
After signing up, you will be redirected to complete your account creation process.
Once signup is complete, you will be taken to a page where you can create your first application as shown below
After signup up, “Create application” and select Nitrogen8M Mini SBC as the Default Device Type. The balena team recommends users select Starter as Application Type, as it is fully-featured and the first ten devices are free of charge.
After signing up, add a device by clicking “Add device.”
A window will appear with default selections. We recommend using a Development image so that the serial console will be enabled (Production image has the console disabled).
Click “Download balenaOS” at the bottom of previous screenshot. As a result, the Nitrogen8M Mini Balena BSP will be downloaded:
balena-cloud-<app_name>-nitrogen8mm-2.47.1+rev3-dev-v10.6.27.img.zip
Extract the .zip image to generate the .img file and flash to SD Card using balenaEtcher:
Make sure you have a CAT-5 cable connected to the Ethernet port to access the internet.
After powering on device, it should connect to the to internet. After a few moments, you should see your device in the balenaCloud Dashboard via the following link:
https://dashboard.balena-cloud.com/apps
Click on your app (Test_App) under Applications. After powering on the OS will enter “Post Provisioning” state which means it will flash the internal eMMC with the OS. Once complete, you will see Post Provisioning status:
Note: The name “cool-sea” is an arbitrary name given to the device and can be modified.
Now you may power off board, remove the SD card and reapply power. If flashing was successful, after a moment you should see the device online:
Finally, you can now click on the device (cool-sea link under Name field) and remotely reboot, open a console etc:
So there you have it! You are now up and running with a balenaOS on Nitrogen8M Mini.
Now that you’ve successfully loaded balenaOS onto the Nitrogen8M Mini and have created an application on balenaCloud, put the board to the test!
To get more information about balena and its products, you can check out their website.
If you have any issues, please email support@boundarydevices.com
The post Using balenaOS with Nitrogen8M Mini appeared first on Boundary Devices.
We are pleased to announce release an Boot2Qt embedded qt5 image and toolchain using Yocto 2.7, Warrior.
Below you will find the download link for the image as well as detailed instructions for the build.
You can download the Boot2Qt Yocto images from here:
You can download the Boot2Qt Linux Toolchains from here (refer below for instructions on building the Windows toolchain):
As usual, you’ll need to register on our site and agree to the EULA because it contains NXP content.
You can to program this image either using U-Boot USB Mass Storage Gadget or program the image onto an SD Card.
Instructions on programming the SW can be found below:
U-Boot USB Mass Storage Gadget
For i-mx6 and i-mx7:
For i-mx8
SD Card, USB Stick
You can flash the image onto an SD card or USB Stick using dd under Linux:
~$ sudo dd if=*boundary-image*.wic of=/dev/sdX bs=1M && sync
In addition, you can use the etcher utility to flash the SD Card or USB stick via Windows or Linux:
This image uses the warrior branch of the meta-boot2qt repo, which uses Qt version 5.14.0.
To build the image, 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 clone the meta-boot2qt repo
~$ mkdir ~/b2qt && cd b2qt ~/b2qt$ git clone git://code.qt.io/yocto/meta-boot2qt.git -b warrior
Next, run the b2qt-init-build-env script for your device. In this case we will use nitrogen8m
~/b2qt$ ./meta-boot2qt/b2qt-init-build-env init --device nitrogen8m
Then, export that device to the MACHINE variable
~/b2qt$ export MACHINE=nitrogen8m
Source the setup-environment script.
~/b2qt$ . ./setup-environment.sh
Finally, build the Boot2Qt Embedded Qt5 Image and Linux Toolchain (“boundary-b2qt-embedded-qt5-image” and “boundary-meta-toolchain-b2qt-embedded-qt5-sdk”)
~/b2qt$ bitbake boundary-meta-b2qt-embedded-qbsp
Note: You can just build the Qt5 image by running “bitbake boundary-b2qt-embedded-qt5-image”
To build a toolchain for Windows platforms add the following line to local.conf:
SDKMACHINE = “i686-mingw32”
After some time this should build the same image as above.
The image file will deploy to tmp/deploy/images/{MACHINE}/b2qt-embedded-qt5-image-{MACHINE}.wic.
The Linux toolchain will deploy to tmp/deploy/qbsp/meta-b2qt-embedded-qbsp-x86_64-{MACHINE}-5.14.0.qbsp.
The Windows toolchain will deploy to tmp/deploy/sdk/b2qt-i686-mingw32-meta-toolchain-b2qt-embedded-qt5-sdk-{MACHINE}.7z.
Please make sure your platform includes the latest U-Boot for i.MX8M:
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
The post Boot2Qt Embedded Qt5 Image and Toolchain Warrior Release appeared first on Boundary Devices.
In this post, we want to go over some basics of using Docker Containers for Reproducible Yocto builds. This will allow for a consistent and stable build environment for building images. No matter the linux distro you are using (Ubuntu, Debian, Fedora etc.), it will produce the same result. There are many resources online for describing what Docker is and what a container is, so we will skip over that, but here are a few helpful links:
https://docs.docker.com/get-started/overview/
https://docker-curriculum.com/
This blog post will focus on reproducible Yocto builds specifically.
In this example, we will be creating an Ubuntu Bionic 18.04 build environment and installing all dependencies needed for our Yocto builds (both Boundary evaluation images and boot2qt images).
Again, we won’t cover Docker requirements and installation in this post, but here is a helpful link to get Docker setup:
https://docs.docker.com/engine/install/
Assuming you have Docker and its dependencies already installed, find below our process for creating a Reproducible Yocto build:
The template file can be found here:
Lets breakdown and explain the file a bit to give you a better understanding of the setup for the build environment.
# # Docker Bionic image to build Yocto 3.0 # FROM ubuntu:18.04
This setups a baseline image to run on the container. In this case, we start with Ubuntu Bionic 18.04
# Keep the dependency list as short as reasonable RUN apt-get update && \ apt-get install -y bc bison bsdmainutils build-essential curl locales \ flex g++-multilib gcc-multilib git gnupg gperf lib32ncurses5-dev \ lib32z1-dev libncurses5-dev git-lfs \ libsdl1.2-dev libxml2-utils lzop \ openjdk-8-jdk lzop wget git-core unzip \ genisoimage sudo socat xterm gawk cpio texinfo \ gettext vim diffstat chrpath libsdl1.2-dev \ python-mako libusb-1.0-0-dev exuberant-ctags \ pngcrush schedtool xsltproc zip zlib1g-dev libswitch-perl && \ apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
This will install all needed dependencies to build Boundary Yocto evaluation images and b2qt images.
ADD https://commondatastorage.googleapis.com/git-repo-downloads/repo /usr/local/bin/ RUN chmod 755 /usr/local/bin/*
The repo command is needed to fetch sources for your yocto builds.
# ===== create user/setup environment =====
# Replace 1000 with your user/group id
RUN export uid=1000 gid=1000 user=jenkins && \
mkdir -p /home/${user} && \
echo "${user}:x:${uid}:${gid}:${user},,,:/home/${user}:/bin/bash" >> /etc/passwd && \
echo "${user}:x:${uid}:" >> /etc/group && \
echo "${user} ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/${user} && \
chmod 0440 /etc/sudoers.d/${user} && \
chown ${uid}:${gid} -R /home/${user}
When creating a container, there will not be any users setup. We use “jenkins” user on our build server, but you should change to whatever your $USER is.
# Improve rebuild performance by enabling compiler cache ENV USE_CCACHE 1 ENV CCACHE_DIR /home/jenkins/.ccache
This avoids unnecessarily recompiling some elements of the build and adding build time.
# Set the locale RUN locale-gen en_US.UTF-8 ENV LANG en_US.UTF-8
Specify locale for your language and country.
ENV HOME /home/jenkins ENV USER jenkins USER jenkins
Specify the logged in user in the container and also specify its home directory.
That is it! As you can see, its very simple to setup a basic build environment using docker. Now lets build and run it.
Execute the following to build the docker image:
wget http://linode.boundarydevices.com/docker/dockerfile_bionic sed -i "s/jenkins/$USER/" dockerfile_bionic docker build --file dockerfile_bionic --tag ubuntu_bionic .
We first grab the dockerfile, then we modify it for your $USER. Then in the build command, we are instructing docker to use the dockerfile we created. We also provide a tag name called “ubuntu_bionic” as an alias for the image.
Run your container interactively (which will directly log you in to the container) by providing the tag name specified above.
docker run -it ubuntu_bionic
Or you can detach and run the container as a daemon
docker run -d ubuntu_bionic
You can also mount a volume which sets up a mount that links the <container_directory> directory from inside the container to the <host_directory> directory on the host machine.
docker run -v <host directory>:<container directory> -it ubuntu_bionic
There you have it! You can now start building images within your handy docker container.
If you have any issues, please email support@boundarydevices.com
The post Using Docker Containers for Reproducible Yocto Builds appeared first on Boundary Devices.
We are pleased to announce a new Yocto release Zeus for our Nitrogen8 family of SBC and SOMS based on i.MX8 processors. Below you will find download links for the images as well as detailed instructions for building including a features set.
You can download the Yocto images from here:
As usual, you’ll need to register on our site and agree to the EULA because it contains NXP content.
You can program the SW to eMMC using the instructions below:
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:
This image uses the zeus 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 ~/yocto-zeus && cd yocto-zeus ~/yocto-zeus$ repo init -u http://github.com/boundarydevices/boundary-bsp-platform -b zeus ~/yocto-zeus$ repo sync
Next, setup the environment for building. For this image we will be building our boundary-wayland distro for the target machine
~/yocto-zeus$ MACHINE=<MACHINE> DISTRO=boundary-wayland . setup-environment 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.
~/yocto-zeus/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.
The image built above contains the following components:
The next sub-sections will describe how to test most features.
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:
In order to test the GPU, you can either use the standard Weston EGL programs or the ones provided by Vivante.
Here are a few examples:
root@<MACHINE>:~# weston-simple-egl & root@<MACHINE>:~# cd /opt/viv_samples/vdk/ root@<MACHINE>:/opt/viv_samples/vdk# ./tutorial7
Camera MIPI-CSI input can be checked using our OV5640 MIPI with GStreamer:
root@<MACHINE>:~# gst-launch-1.0 v4l2src device=/dev/video0 ! \
video/x-raw,width=1280,height=720 ! glimagesink
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
Same goes for the Wi-Fi that can be tested just as easily:
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
...
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>:~# /usr/share/silex-uart/silex-uart.sh start Starting silex-uart rfkill on/off cycle. silex found root@<MACHINE>:~# hciconfig hci0 up root@<MACHINE>:~# hcitool scan Scanning ... 11:22:DE:AD:BE:EF Some Device
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 --video-sink=glimagesink Hobbit-1080p.mov
If your platform supports VPU encoding, here is an example on how to test it using gstreamer:
root@<MACHINE>:~# gst-launch-1.0 -v -e v4l2src device=/dev/video0 ! 'video/x-raw,format=(string)YUY2, width=1920, height=1080, framerate=30/1' ! vpuenc_h264 ! filesin
k location=test.h264
Setting pipeline to PAUSED ...
====== VPUENC: 4.4.5 build on Apr[ 39.759990] check_voltage: voltage=855000 900000 950000 freq=650000000 VPUMIX_PD
1 2020 21:23:34. ======
wrapper: 3.0.0 (VPUWRAPPER_ARM64_LINUX Build on Mar 28 2020 08:53:37)
vpulib: 1.1.1
firmware: 1.1[ 39.777613] imx_gpc_pd_power_off: voltage=850000 VPUMIX_PD
.1.43690
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
/GstPipeline:pipeline0/GstV4l2Src:v4l2src0.GstPad:src: caps = video/x-raw, format=(string)YUY2, width=(int)1920, height=(int)1080, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)1/1, colorimetry=(string)bt709, interlace-mode=(string)progressive
/GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:src: caps = video/x-raw, format=(string)YUY2, width=(int)1920, height=(int)1080, framerate=(fraction)30/1, [ 40.518172] ov5640_mipisubdev 5-003c: s_stream: 1
pixel-aspect-ratio=(fraction)1/1, colorimetry=(string)bt709, interlace-mode=(string)progressive
/GstPipeline:pipeline0/vpuenc_h264:vpuenc_h264-0.GstPad:sink: caps = video/x-raw, format=(string)YUY2, width=(int)1920, height=(int)1080, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)1/1, colorimetry=(string)bt709, interlace-mode=(string)progressive
/GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:sink: caps = video/x-raw, format=(string)YUY2, width=(int)1920, height=(int)1080, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)1/1, colorimetry=(string)bt709, interlace-mode=(string)progressive
[ 40.620867] check_voltage: voltage=855000 900000 950000 freq=650000000 VPUMIX_PD
[ 40.629361] imx_gpc_pd_power_off: voltage=850000 VPUMIX_PD
[ 40.635818] check_voltage: voltage=855000 900000 950000 freq=650000000 VPUMIX_PD
[ 40.643804] imx_gpc_pd_power_off: voltage=850000 VPUMIX_PD
[ 40.649791] check_voltage: voltage=855000 900000 950000 freq=650000000 VPUMIX_PD
[ 40.657768] imx_gpc_pd_power_off: voltage=850000 VPUMIX_PD
[ 40.663741] check_voltage: voltage=855000 900000 950000 freq=650000000 VPUMIX_PD
/GstPipeline:pipeline0/vpuenc_h264:vpuenc_h264-0.GstPad:src: caps = video/x-h264, stream-format=(string)byte-stream, alignment=(string)au, width=(int)1920, height=(int)1080, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, colorimetry=(string)bt709
/GstPipeline:pipeline0/GstFileSink:filesink0.GstPad:sink: caps = video/x-h264, stream-format=(string)byte-stream, alignment=(string)au, width=(int)1920, height=(int)1080, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, colorimetry=(string)bt709
^Chandling interrupt.
Interrupt: Stopping pipeline ...
EOS on shutdown enabled -- Forcing EOS on the pipeline
Waiting [ 69.642199] imx_gpc_pd_power_off: voltage=850000 VPUMIX_PD
for EOS...
Got EOS from element [ 69.650922] check_voltage: voltage=855000 900000 950000 freq=650000000 VPUMIX_PD
"pipeline0".
EOS received - stop[ 69.662880] imx_gpc_pd_power_off: voltage=850000 VPUMIX_PD
ping pipeline...
Execution ended[ 69.669822] ov5640_mipisubdev 5-003c: s_stream: 0
after 0:00:29.580964436
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...
root@<MACHINE>:~# ls -alh
drwx------ 3 root root 4.0K Apr 1 22:59 .
drwxr-xr-x 3 root root 4.0K Apr 1 21:25 ..
-rw------- 1 root root 4.9K Apr 1 23:00 .ash_history
drwxr-xr-x 3 root root 4.0K Apr 1 22:08 .cache
-rw-r--r-- 1 root root 34.6M Apr 1 22:59 test.h264
root@<MACHINE>:~# gst-launch-1.0 filesrc location=test.h264 typefind=true ! 'video/x-h264' ! h264parse ! vpudec ! glimagesink sync=true
Setting pipeline to PAUSED ...
====== VPUDEC: 4.4.5 build on Apr[ 79.404937] check_voltage: voltage=855000 900000 950000 freq=650000000 VPUMIX_PD
1 2020 21:23:34. ======
wrapper: 3.0.0 (VPUWRAPPER_ARM64_LINUX Build on Mar 28 2020 08:53:37)
vpulib: 1.1.1
firmware: 1.1[ 79.424233] imx_gpc_pd_power_off: voltage=850000 VPUMIX_PD
.1.0
Pipeline is PREROLLING ...
Got context from element 'sink': gst.gl.GLDisplay=context, gst.gl.GLDisplay=(GstGLDisplay)"\(G[ 79.443039] check_voltage: voltage=855000 900000 950000 freq=650000000 VPUMIX_PD
stGLDisplayWayland\)\ gldisplaywayland0";
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 0:00:29.[ 108.609182] imx_gpc_pd_power_off: voltage=850000 VPUMIX_PD
034084646
Setting pipeline to PA[ 108.617333] check_voltage: voltage=855000 900000 950000 freq=650000000 VPUMIX_PD
USED ...
Setting pipeline to REA[ 108.629178] imx_gpc_pd_power_off: voltage=850000 VPUMIX_PD
DY ...
Setting pipeline to NULL ...
Total showed frames (857), playing for (0:00:29.034898533), fps (29.516).
Freeing pipeline ...
root@<MACHINE>:~#
CAN is supported when using our DB_8MM_CSI_EXP . You’ll be able to bring up the interface using these commands:
root@<MACHINE>:~# ip link set can0 up type can bitrate 500000 root@<MACHINE>:~# ifconfig can0 up
From this point, you can use commands such as cansend and candump to send or display messages on the bus respectively.
If you have any issues, please email support@boundarydevices.com
The post Yocto Zeus Release for i.MX8 Platforms appeared first on Boundary Devices.
We are pleased to announce a new Yocto release Zeus for our Nitrogen6/7 family of SBC and SOMS based on i.MX6/7 processors. Below you will find the download link for the images as well as detailed instructions for the build including a features set.
You can download the Yocto images from here:
We also provide a Nitrogen6x X11 image to see if there’s still traction for it. Let us know if you need it for another platform.
As usual, you’ll need to register on our site and agree to the EULA because it contains NXP content.
You can program the SW to eMMC using the instructions below:
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:
This image uses the zeus 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 ~/yocto-zeus && cd yocto-zeus ~/yocto-zeus$ repo init -u http://github.com/boundarydevices/boundary-bsp-platform -b zeus ~/yocto-zeus$ repo sync
Next, setup the environment for building. In this image, we will be building our boundary-wayland distro for the target machine
~/yocto-zeus$ MACHINE=<MACHINE> DISTRO=boundary-wayland . setup-environment build
Now bitbake boundary-image-multimedia-full which is equivalent to fsl-image-multimedia-full with Boundary-specific packages such as BD-SDMAC support.
~/yocto-zeus/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.
As mentioned, we also offer an X11 based build for Nitrogen6x. Simply follow the above procedure up until repo sync, but instead setup the build as follows:
The only difference is we now will be building boundary-eval-image for nitrogen6x with the fslc-x11 distro instead:
~/yocto-zeus$ MACHINE=nitrogen6x DISTRO=fslc-x11 . setup-environment boundary-eval-image
Now bitbake boundary-eval-image which is basically core-image-sato-dev with Boundary-specific packages added such as BD-SDMAC support.
~/yocto-zeus/boundary-eval-image$ bitbake boundary-image-multimedia-full
After some time this should build the same image as above.
The image file will deploy to tmp/deploy/images/{MACHINE}/boundary-eval-image-{MACHINE}.wic.gz.
The images built above contains the following components:
The next sub-sections will describe how to test most features.
In order to test the GPU, you can either use the standard Weston EGL programs or the ones provided by Vivante.
Here are a few examples:
root@<MACHINE>:~# weston-simple-egl & root@<MACHINE>:~# cd /opt/viv_samples/vdk/ root@<MACHINE>:/opt/viv_samples/vdk# ./tutorial7
Camera MIPI-CSI input can be checked using our Nit6X_5MP_MIPI with GStreamer:
root@<MACHINE>:~# gst-launch-1.0 imxv4l2videosrc device=/dev/video1 ! autovideosink;
Here is an example using GPlay tool:
root@<MACHINE>:~# wget http://linode.boundarydevices.com/videos/Hobbit-1080p.mov root@<MACHINE>:~# gst-launch-1.0 playbin uri=file:///home/root/Hobbit-1080p.mov video-sink=imxipuvideosink
Here is an example using gstreamer:
root@<MACHINE>:~# gst-launch-1.0 imxv4l2videosrc device=/dev/video1 ! imxvpuenc_h264 bitrate=10000 ! filesink location=test.mp4
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
Same goes for the Wi-Fi that can be tested just as easily:
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@nitrogen8mm:~# 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
...
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>:~# /usr/share/silex-uart/silex-uart.sh start Starting silex-uart rfkill on/off cycle. silex found root@<MACHINE>:~# hciconfig hci0 up root@<MACHINE>:~# hcitool scan Scanning ... 11:22:DE:AD:BE:EF Some Device
CAN is supported on Nitrogen6 MAX. You’ll be able to bring up the interface using these commands:
root@<MACHINE>:~# ip link set can0 up type can bitrate 500000 root@<MACHINE>:~# ifconfig can0 up
From this point, you can use commands such as cansend and candump to send or display messages on the bus respectively.
Chromium-x11 version chromium-x11_80.0.3987.132:
If you have any issues, please email support@boundarydevices.com
The post Yocto Zeus Release for i.MX6/i.MX7 Platforms appeared first on Boundary Devices.
We are pleased to announce a new Yocto release Zeus for our Nitrogen8M Mini SBC based on the i.MX8M MINI processor. Below you will find the download link for the image as well as detailed instructions for the build including a features set.
You can download the Yocto image from here:
As usual, you’ll need to register on our site and agree to the EULA because it contains NXP content.
The image is a SD card image that can be restored using zcat and dd under Linux.
~$ zcat *boundary-image*.wic.gz | sudo dd of=/dev/sdX bs=1M
In addition, you can use the etcher utility to flash the SD Card or USB stick via Windows or Linux:
This image uses the zeus branch of our boundary-bsp-platform repository.
To build the image, we recommend using a Docker Container so that you can build with a repeatable 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 ~/yocto-imx8m && cd yocto-imx6x ~/yocto-imx6x$ repo init -u http://github.com/boundarydevices/boundary-bsp-platform -b zeus ~/yocto-imx6x$ repo sync
Setup the environment for building, in this example we will be building our boundary-wayland distro for nitrogen6x.
~/yocto-imx6x$ MACHINE=nitrogen6x DISTRO=boundary-wayland . setup-environment build
Now bitbake boundary-image-multimedia-full which is equivalent to fsl-image-multimedia-full with Boundary-specific packages such as BD-SDMAC support
~/yocto-imx6x/build$ bitbake boundary-image-multimedia-full
After some time this should build the same image as above.
The image file will deploy to tmp/deploy/images/{MACHINE}/boundary-image-multimedia-full-{MACHINE}.wic.gz.
The image built above contains the following components:
The next sub-sections will describe how to test most features.
Please make sure your platform includes the latest U-Boot for i.MX8M MINI:
This version of U-Boot supports the display configuration, allowing to use any of the following displays:
In order to test the GPU, you can either use the standard Weston EGL programs or the ones provided by Vivante.
Here are a few examples:
root@nitrogen6x:~# weston-simple-egl & root@nitrogen6x:~# cd /opt/viv_samples/vdk/ root@nitrogen6x:/opt/viv_samples/vdk# ./tutorial7
The i.MX6x processor can decode videos with a resolution up to 1080p. Here is an example using GPlay tool:
root@nitrogen6x:~# wget http://linode.boundarydevices.com/videos/Hobbit-1080p.mov root@nitrogen6x:~# gplay-1.0 --video-sink=glimagesink Hobbit-1080p.mov
The i.MX6x processor can encode videos with a resolution up to 1080p. Here is an example using gstreamer:
root@nitrogen6x:~# gst-launch-1.0 -v -e v4l2src device=/dev/video0 ! 'video/x-raw,format=(string)YUY2, width=1920, height=1080, framerate=30/1' ! vpuenc_h264 ! filesin
k location=test.h264
Setting pipeline to PAUSED ...
====== VPUENC: 4.4.5 build on Apr[ 39.759990] check_voltage: voltage=855000 900000 950000 freq=650000000 VPUMIX_PD
1 2020 21:23:34. ======
wrapper: 3.0.0 (VPUWRAPPER_ARM64_LINUX Build on Mar 28 2020 08:53:37)
vpulib: 1.1.1
firmware: 1.1[ 39.777613] imx_gpc_pd_power_off: voltage=850000 VPUMIX_PD
.1.43690
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
/GstPipeline:pipeline0/GstV4l2Src:v4l2src0.GstPad:src: caps = video/x-raw, format=(string)YUY2, width=(int)1920, height=(int)1080, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)1/1, colorimetry=(string)bt709, interlace-mode=(string)progressive
/GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:src: caps = video/x-raw, format=(string)YUY2, width=(int)1920, height=(int)1080, framerate=(fraction)30/1, [ 40.518172] ov5640_mipisubdev 5-003c: s_stream: 1
pixel-aspect-ratio=(fraction)1/1, colorimetry=(string)bt709, interlace-mode=(string)progressive
/GstPipeline:pipeline0/vpuenc_h264:vpuenc_h264-0.GstPad:sink: caps = video/x-raw, format=(string)YUY2, width=(int)1920, height=(int)1080, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)1/1, colorimetry=(string)bt709, interlace-mode=(string)progressive
/GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:sink: caps = video/x-raw, format=(string)YUY2, width=(int)1920, height=(int)1080, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)1/1, colorimetry=(string)bt709, interlace-mode=(string)progressive
[ 40.620867] check_voltage: voltage=855000 900000 950000 freq=650000000 VPUMIX_PD
[ 40.629361] imx_gpc_pd_power_off: voltage=850000 VPUMIX_PD
[ 40.635818] check_voltage: voltage=855000 900000 950000 freq=650000000 VPUMIX_PD
[ 40.643804] imx_gpc_pd_power_off: voltage=850000 VPUMIX_PD
[ 40.649791] check_voltage: voltage=855000 900000 950000 freq=650000000 VPUMIX_PD
[ 40.657768] imx_gpc_pd_power_off: voltage=850000 VPUMIX_PD
[ 40.663741] check_voltage: voltage=855000 900000 950000 freq=650000000 VPUMIX_PD
/GstPipeline:pipeline0/vpuenc_h264:vpuenc_h264-0.GstPad:src: caps = video/x-h264, stream-format=(string)byte-stream, alignment=(string)au, width=(int)1920, height=(int)1080, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, colorimetry=(string)bt709
/GstPipeline:pipeline0/GstFileSink:filesink0.GstPad:sink: caps = video/x-h264, stream-format=(string)byte-stream, alignment=(string)au, width=(int)1920, height=(int)1080, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, colorimetry=(string)bt709
^Chandling interrupt.
Interrupt: Stopping pipeline ...
EOS on shutdown enabled -- Forcing EOS on the pipeline
Waiting [ 69.642199] imx_gpc_pd_power_off: voltage=850000 VPUMIX_PD
for EOS...
Got EOS from element [ 69.650922] check_voltage: voltage=855000 900000 950000 freq=650000000 VPUMIX_PD
"pipeline0".
EOS received - stop[ 69.662880] imx_gpc_pd_power_off: voltage=850000 VPUMIX_PD
ping pipeline...
Execution ended[ 69.669822] ov5640_mipisubdev 5-003c: s_stream: 0
after 0:00:29.580964436
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...
root@nitrogen6x:~# ls -alh
drwx------ 3 root root 4.0K Apr 1 22:59 .
drwxr-xr-x 3 root root 4.0K Apr 1 21:25 ..
-rw------- 1 root root 4.9K Apr 1 23:00 .ash_history
drwxr-xr-x 3 root root 4.0K Apr 1 22:08 .cache
-rw-r--r-- 1 root root 34.6M Apr 1 22:59 test.h264
root@nitrogen6x:~# gst-launch-1.0 filesrc location=test.h264 typefind=true ! 'video/x-h264' ! h264parse ! vpudec ! glimagesink sync=true
Setting pipeline to PAUSED ...
====== VPUDEC: 4.4.5 build on Apr[ 79.404937] check_voltage: voltage=855000 900000 950000 freq=650000000 VPUMIX_PD
1 2020 21:23:34. ======
wrapper: 3.0.0 (VPUWRAPPER_ARM64_LINUX Build on Mar 28 2020 08:53:37)
vpulib: 1.1.1
firmware: 1.1[ 79.424233] imx_gpc_pd_power_off: voltage=850000 VPUMIX_PD
.1.0
Pipeline is PREROLLING ...
Got context from element 'sink': gst.gl.GLDisplay=context, gst.gl.GLDisplay=(GstGLDisplay)"\(G[ 79.443039] check_voltage: voltage=855000 900000 950000 freq=650000000 VPUMIX_PD
stGLDisplayWayland\)\ gldisplaywayland0";
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 0:00:29.[ 108.609182] imx_gpc_pd_power_off: voltage=850000 VPUMIX_PD
034084646
Setting pipeline to PA[ 108.617333] check_voltage: voltage=855000 900000 950000 freq=650000000 VPUMIX_PD
USED ...
Setting pipeline to REA[ 108.629178] imx_gpc_pd_power_off: voltage=850000 VPUMIX_PD
DY ...
Setting pipeline to NULL ...
Total showed frames (857), playing for (0:00:29.034898533), fps (29.516).
Freeing pipeline ...
root@nitrogen6x:~#
Camera MIPI-CSI input can be checked using our OV5640 MIPI with GStreamer:
root@nitrogen6x:~# gst-launch-1.0 v4l2src device=/dev/video0 ! \
video/x-raw,width=1280,height=720 ! glimagesink
Once the eth0 interface is up, you can use iperf3 to check Ethernet performances:
root@nitrogen6x:~# 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
Same goes for the Wi-Fi that can be tested just as easily:
root@nitrogen6x:~# nmcli d wifi connect <network_name> password <password>
root@nitrogen6x:~# 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@nitrogen6x:~# 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
...
For products with a Silex bluetooth module, you’ll be able to connect using our handy silex-uart script with the following commands:
root@nitrogen6x:~# /usr/share/silex-uart/silex-uart.sh start Starting silex-uart rfkill on/off cycle. silex found root@nitrogen6x:~# hciconfig hci0 up root@nitrogen6x:~# hcitool scan Scanning ... 11:22:DE:AD:BE:EF Some Device
CAN is supported on the Nitrogen8M Mini when using our DB_6x_CSI_EXP . You’ll be able to bring up the interface using these commands:
root@nitrogen6x:~# ip link set can0 up type can bitrate 500000 root@nitrogen6x:~# ifconfig can0 up
From this point, you can use commands such as cansend and candump to send or display messages on the bus respectively.
If you have any issues, please email support@boundarydevices.com
The post Zeus Yocto release for i.MX8M MINI appeared first on Boundary Devices.
This guide will provide the steps to use a Yocto generated b2qt embedded QBSP within Qt Creator to simplify application development with Qt. More information on QBSPs can be found here.
Qt defines a QBSP as follows: “A QBSP contains a cross-compilation toolchain that gets integrated into Qt Creator, and a device image that can be used to boot your device using Boot to Qt software stack.” So essentially, when developing an application with Qt Creator using a QBSP, you will be able to run your app on the target hardware, which has the required BSP components + Qt libraries to support the application. Lets dive in!
Please follow the steps below in order to get up and running using a b2qt embedded QBSP in Qt Creator for application development.
Follow the below URL to Try or Buy Qt. Qt offers a 10 day evaluation license to get you started.
https://www.qt.io/download
After filling out the form, you will be emailed credentials and instructions on setting up your account and activating your license.
The Qt online installer can be found via the downloads page in your account. The online installer provides everything you need to start Qt development:
Run the online installer. After running, you should see the following window.
Go through the steps until you are prompted to select the Installation Folder. The default on Linux distributions will be /home/<user>/Qt. You can make this path whatever you wish.
After specifying the path, you will be taken to a window where you can select the components to install. It is here where you will select the Qt version to install and provide a pre-generated QBSP file. In this example, we will be using Qt version 5.15 for i.MX8MM
Qt 5.15 is part of the preview release, so click the “Preview” Package Category and hit filter, then find Qt 5.15.0-beta3 under the Preview tab and select it
Note: You may notice this is the beta3 version of 5.15.0. The QBSP we will be using was built using 5.15.0, which has not been officially released. You can use whatever Qt version that matches the version used in your QBSP.
Now we will select a Linux System and Toolchain to install i.e. a QBSP. In this example we will use the latest 5.15.0 QBSP for Nitrogen8M Mini.
Click Browse QBSP files and select the QBSP. After selecting the QBSP file, a Boundary Devices i.MX8MM Linux System and Linux Toolchain will already be selected as components under “Qt for Device Creation”. Also make sure Qt 5.15.0-beta3 is still selected under the Preview tab.
Click Next
Agree to the License Agreement and Click Next again, then Click Install. The selected components will then install.
When installation is complete, Finish the Qt Wizard and launch Qt Creator.
Qt Creator will launch, but before we do anything here, we must flash the target hardware with a Boot to Qt image. The latest 5.15.0 b2qt image and flashing instructions can be found here:
https://boundarydevices.com/boot2qt-embedded-qt5-image-and-toolchain-zeus-release
Before we can start developing and deploying applications, we must configure a device kit so you can deploy the application on the target hardware via Qt Creator. We will be doing this via ssh, so it is required that you connect the device to the same network as the PC that is running Qt Creator and obtain its IP address.
After Qt Creator launches, navigate to Tools > Options > Kits.
Select the Auto-detected Boot2Qt 5.15.0 Boundary Devices Kit.
Click the Manage button next to Device. You will then be taken to the Devices tab.
Click Add and select Boot2Qt device and then click Start Wizard.
Provide a device name and IP address.
Click Finish. If Qt Creator successfully connected to and added the device, you should see the following.
Click Apply and OK and we are now ready to deploy our first demo application!
In this example, we are going to be using the Basic Layouts Example, so search Basic Layouts in search bar.
Select Basic Layouts example. You then will be prompted to select a Kit. Select the Boot2Qt 5.15.0 Boundary Devices i.MX8MM kit and click Configure Project.
You can now build and run example by clicking the green play button “run”
You should now see the Basic Layout Example come up on your display.
There you have it! You are now up and running for Qt development using a Boundary Devices QBSP in Qt Creator.
If you have any issues, please email support@boundarydevices.com
The post Using a b2qt embedded QBSP in Qt Creator appeared first on Boundary Devices.
This post intends to answer the question of programming the eMMC memory you can find on our devices.
Although there are many different approaches available based on Linux or the MFG Tools, this post will focus on two solutions provided under U-Boot.
Here is a quick summary:
minicom for Linux or TeraTerm for Windows=> fastboot 0
boundary@boundary:~/$ sudo fastboot flash gpt gpt_8G.img boundary@boundary:~/$ sudo fastboot flash rootfs rootfs_8G.simg
This feature is fully explained here:
Here is a quick summary:
minicom for Linux or TeraTerm for Windows=> ums mmc 0
~/$ zcat [your image name].img.gz | sudo dd of=/dev/sdX bs=1M
Here is a quick summary:
boundary@boundary:~/$ wget -r -np -nH -R "index.html*" \ linode.boundarydevices.com/autoprogram_emmc/ boundary@boundary:~/$ cd autoprogram_emmc/ && chmod +x *.sh
=> mmc list FSL_SDHC: 0 (eMMC) FSL_SDHC: 1 (SD)
~/autoprogram_emmc$ ./create_autoprogram_image.sh 0 ubuntu.img.gz out.img
~/autoprogram_emmc$ sudo dd if=out.img of=/dev/sdX bs=1M
This feature is fully explained here:
Here is a quick summary:
minicom for Linux or TeraTerm for Windows=> load mmc 0 10008000 my.img.gz
=> gzwrite mmc 1 10008000 0x$filesize 100000 0
The post Programming eMMC on i.MX platforms appeared first on Boundary Devices.
We are pleased to announce a new Boot2Qt Embedded Qt5 image and toolchain using Yocto 3.0, Zeus.
Below you will find the download links for the images as well as detailed instructions for the build. You can view a demo of the image running on our Nitrogen8M Mini SOM here.
You can download the Boot2Qt Yocto images from here:
You can download the Boot2Qt Linux Toolchains from here (refer below for instructions on building the Windows toolchain):
Instructions on how to use the QBSP Toolchain in your Qt application development can be found here.
As usual, you’ll need to register on our site and agree to the EULA because it contains NXP content.
You can program the SW to eMMC using the instructions below:
For i-mx6 and i-mx7:
For i-mx8
You can also program the SW to SD Card or USB Stick via zcat and dd under Linux:
~$ sudo dd if=*boundary-image*.wic of=/dev/sdX bs=1M && sync
In addition, you can use the balenaEtcher utility to flash the eMMC, SD Card or USB stick via Windows or Linux:
This image uses the zeus branch of the meta-boot2qt repo, which uses Qt version 5.15.0.
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 clone the meta-boot2qt repo
~$ mkdir ~/b2qt && cd b2qt ~/b2qt$ git clone git://code.qt.io/yocto/meta-boot2qt.git -b zeus
Next, run the b2qt-init-build-env script for your device. In this case we will use nitrogen8mm
~/b2qt$ ./meta-boot2qt/b2qt-init-build-env init --device nitrogen8mm
Then, export that device to the MACHINE variable
~/b2qt$ export MACHINE=nitrogen8mm
Source the setup-environment script.
~/b2qt$ . ./setup-environment.sh
Finally, build the Boundary Boot2Qt Embedded Qt5 Image and Linux Toolchain (“boundary-b2qt-embedded-qt5-image” and “boundary-meta-toolchain-b2qt-embedded-qt5-sdk”)
~/b2qt$ bitbake boundary-meta-b2qt-embedded-qbsp
Note: You can just build the Qt5 image by running “bitbake boundary-b2qt-embedded-qt5-image”
To build a toolchain for Windows platforms add the following line to local.conf:
SDKMACHINE = “i686-mingw32”
After some time this should build the same image as above.
The image file will deploy to tmp/deploy/images/{MACHINE}/b2qt-embedded-qt5-image-{MACHINE}.wic.
The Linux toolchain will deploy to tmp/deploy/qbsp/meta-b2qt-embedded-qbsp-x86_64-{MACHINE}-5.15.0.qbsp.
The Windows toolchain will deploy to tmp/deploy/sdk/b2qt-i686-mingw32-meta-toolchain-b2qt-embedded-qt5-sdk-{MACHINE}.7z.
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
If you have any issues, please email support@boundarydevices.com
The post Boot2Qt Embedded Qt5 Image and Toolchain Zeus Release appeared first on Boundary Devices.
We are pleased to announce support for the BD_HDMI_MIPI on our i.MX8 based Nitrogen boards.
Although the i.MX8M and i.MX8M Mini processors do not natively support HDMI input, the Toshiba TC358743XBG HDMI to MIPI-CSI bridge enables this feature.
You can find the specs on the daughter board for Nitrogen8M here and Nitrogen8M Mini here. This particular HDMI bridge only supports 1080p resolution, but stay tuned for an updated bridge chip that will support up to 4k.
Find below a video demo of the board in action. The specs of the setup in the video are as follows:
Nitrogen8M running Yocto 3.0 Zeus + 10″ Display
Kernel Revision: 4.14.x_2.0.0_ga
Nitrogen6x MAX running Ubuntu Bionic 18.04 xfce 1080p
Kernel Revision: 4.14.x_2.0.0_ga
The 1080p output of the Nitrogen6 MAX feeds into the BD_HDMI_MIPI_8M which then connects to the DB_CSI_8M that is connected to the Nitrogen8M.
Then, the HDMI video source shows up as an input video device on the Yocto OS GStreamer application:
The post HDMI Input for i.MX8 boards via MIPI-CSI appeared first on Boundary Devices.
We are pleased to announce the release of the DB_8MM_DSIHD, a daughter board that allows MIPI-DSI to HDMI conversion. Product details can be found here.
The product is mainly geared towards the Nitrogen8M Mini and Nitrogen8m Nano, as the i.MX8M Mini and i.MX8M Nano processors only support a single MIPI-DSI display output. Therefore, this daughter board is necessary to enable HDMI output. It can also be used with the Nitrogen8M, if a second HDMI output is desired.
Find below a video demo of the board in action. The specs of the setup in the video are as follows:
Nitrogen8M Mini running Yocto 3.0 Zeus + 1080p HDMI Display
Kernel Revision: 4.14.x_2.0.0_ga
The MIPI-DSI display output (1080p) of the Nitrogen8M Mini connects to the MIPI-DSI input on the DB_8MM_DSIHD and the HDMI is outputted from there to the 1080p Monitor.
The post MIPI-DSI to HDMI for i.MX8 boards with DB_8MM_DSIHD appeared first on Boundary Devices.
Nitrogen8M running Yocto 3.0 Zeus + 1080p eDP Display
Kernel Revision: 4.14.x_2.0.0_ga
The post eDP Display Support on Nitrogen8M appeared first on Boundary Devices.
We are pleased to announce the release of the DB_8MM_CSI_EXP, an expansion daughter board for the Nitrogen8M Mini.
This daughter board includes SPI to CAN Bus transceiver, UART, I2C, and other pins exposed. Product details can be found here.
Find below a video demo of the board in action. In this demo, we will connect our Nit8M_MINI_5MP_MIPI to the daughter board and show the camera feed.
The specs of the setup in the video are as follows:
Nitrogen8M Mini running Yocto 3.0 Zeus + 10″ Display
Kernel Revision: 4.14.x_2.0.0_ga
The post DB_8MM_CSI_EXP for Nitrogen8M Mini appeared first on Boundary Devices.
root@nitrogen8m:~# lspci 00:00.0 PCI bridge: Synopsys, Inc. DWC_usb3 (rev 01) 01:00.0 Non-Volatile memory controller: Kingston Technology Company, Inc. Device 5008 (rev 01)
root@nitrogen8m:~# fdisk -l Disk /dev/mmcblk0: 7296 MB, 7650410496 bytes, 14942208 sectors 233472 cylinders, 4 heads, 16 sectors/track Units: sectors of 1 * 512 = 512 bytes Device Boot StartCHS EndCHS StartLBA EndLBA Sectors Size Id Type /dev/mmcblk0p1 * 0,0,9 609,0,22 8 77973 77966 38.0M c Win95 FAT32 (LBA) /dev/mmcblk0p2 609,0,25 1023,3,32 77976 4839759 4761784 2325M 83 Linux Disk /dev/sda: 3796 MB, 3980394496 bytes, 7774208 sectors 1019 cylinders, 123 heads, 62 sectors/track Units: sectors of 1 * 512 = 512 bytes Device Boot StartCHS EndCHS StartLBA EndLBA Sectors Size Id Type /dev/sda1 * 0,0,9 640,0,10 8 81929 81922 40.0M c Win95 FAT32 (LBA) Partition 1 has different physical/logical end: phys=(640,0,10) logical=(10,91,28) /dev/sda2 640,0,17 1023,3,32 81936 1244617 1162682 567M 83 Linux Partition 2 has different physical/logical start (non-Linux?): phys=(640,0,17) logical=(10,91,35) Partition 2 has different physical/logical end: phys=(1023,3,32) logical=(163,25,30) Disk /dev/nvme0n1: 238 GB, 256060514304 bytes, 500118192 sectors 1420790 cylinders, 22 heads, 16 sectors/track Units: sectors of 1 * 512 = 512 bytes Device Boot StartCHS EndCHS StartLBA EndLBA Sectors Size Id Type /dev/nvme0n1p1 1,0,1 486,21,16 2048 500118191 500116144 238G 83 Linux
root@nitrogen8m:~# mkfs.ext4 /dev/nvme0n1 Discarding device blocks: done Creating filesystem with 62514774 4k blocks and 15630336 inodes Filesystem UUID: 4d1aecb1-1c1b-4ba9-b7e8-5092d1588b96 Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872 Allocating group tables: done Writing inode tables: done Creating journal (262144 blocks): done Writing superblocks and filesystem accounting information: done
root@nitrogen8m:~# mkdir /tmp/kingston_ssd root@nitrogen8m:~# mount /dev/nvme0n1 /tmp/kingston_ssd/ [ 296.092862] EXT4-fs (nvme0n1): mounted filesystem with ordered data mode. Opts: (null) root@nitrogen8m:~# cd /tmp/kingston_ssd/ root@nitrogen8m:/tmp/kingston_ssd# ls lost+found root@nitrogen8m:/tmp/kingston_ssd# echo This is a test! > test.txt root@nitrogen8m:/tmp/kingston_ssd# cd root@nitrogen8m:~# umount /tmp/kingston_ssd/
Now reboot and verify the file is in tact.
root@nitrogen8m:~# mkdir /tmp/kingston_ssd root@nitrogen8m:~# mount /dev/nvme0n1 /tmp/kingston_ssd/ [ 68.319706] EXT4-fs (nvme0n1): mounted filesystem with ordered data mode. Opts: (null) root@nitrogen8m:~# cd /tmp/kingston_ssd/ root@nitrogen8m:/tmp/kingston_ssd# cat test.txt This is a test!
The post Using an SSD via mPCIe on our i.MX8 Nitrogen boards appeared first on Boundary Devices.