Salyut-EL24D1: debug board on the Russian processor 1892BM14Ya for harsh operating conditions

A new Russian experiment board appeared in our engineering laboratory - the Salyut-EL24D1 debugging module on a multi-core system on a 1892BM14I chip for the Arctic and space. Let's see what she is capable of.

The Salyut-EL24D1 module, like all debug boards, is designed for exploring the capabilities of the processor, developing and debugging software. Its developer, NPC ELVIS, began deliveries of Salyut at the end of 2015.

One of the main areas of application for the 1892BM14I processor is machine vision systems, video and audio processing, designed for harsh environments, production or space. So the processor is focused on industrial rather than civilian use - the operating temperature range is from –60 ° C to + 85 ° C.

Chip 1892VM14Ya developed by the system-on-chip (SoC) technology and includes two ARM Cortex-A9 cores, a Mali-300 GPU unit, two Elcore-03M DSP cores, a VELcore-01 hardware video processing unit and various I / O ports.
')

Contents of delivery

In addition to the Salyut-EL24D1 debugging card itself, the box contains a 12V power supply, a CSI-camera with a cable, a 32 GB micro-SD memory card, a USB → UART adapter, a battery for the RTC, a WiFi module antenna, and a radiator for the processor, without which it is weakly heated.

The debug board comes pre-installed with the Arch Linux distribution. Buildroot sources are available, from which you can build the necessary packages yourself or the entire system.

The most delicious thing about Arch Linux is the demo utilities for capturing video stream from a CSI camera, utilities for working with the H264 video codec and Gstreamer with installed RTSP plug-ins.

Board interfaces

The board has USB, Ethernet, Wifi ports and connectors for connecting ZigBee / GPS antennas.

Video / audio interfaces include HDMI video output, DSI video output, CSI connector for camera, standard audio input / output 3.5 mm.



Also available are RS-232, RS-485, CAN bus, UART, I2C, I2S, SPI.

At the top of the board, debug ports and a RaspberryPI-compatible PLS-pins block with GPIO and corresponding interfaces are displayed.

Video processing on the processor

The main area in which we experimented with the 1892BM14Y processor is video signal processing - one of its main features.

To begin with, we conducted trial tests of H264 software coding using GStreamer. With a video resolution of 1280x720px, H264 software coding with the libx264 plugin in GStreamer yields only 2–3 fps. Decoding works a little faster - about 8 fps. The speed is quite low, which is not surprising, since The processor is not designed to perform complex computational tasks.

The target application area of ​​1892BM14Y is video / audio processing, IP cameras, etc. Therefore, we were most interested in the VELcore-01 video processing unit with the possibility of H264 encoding / decoding hardware.

Hardware codec H264

The main characteristics of the video processing core VELcore-01:

1. The maximum size of processed images is 4096 x 4096 pixels.
2. The minimum size of processed images is 16 x 16 pixels.
3. The image format is YCbCr (4: 2: 0).
4. Presentation accuracy is 8 bits per pixel.
5. The number of simultaneously processed video data streams is up to two compression streams and up to two decompression streams.
6. Maximum performance - up to two streams of compression and up to two streams of video decompression in Full HD format (1920 x 1080 pixels) with a frequency of 60 frames per second according to any of these standards.

One of the features of the H264 hardware coding block is that it uses the non-standard M420 pixel format for the input video. M420 is a YUV (4: 2: 0) format with a recording density of 12 bits per pixel. The Y-component is recorded for each pixel (1 byte per pixel), and the CbCr-components - by one pair of values ​​per block of 4 pixels (2 bytes by 4 pixels). This format is similar to NV12, with the difference that the CbCr data block does not come at the end, but is "mixed" line by line with the Y block: 2 Y lines - one CbCr line, etc.

The structure of the M420 format looks like this, judging by the description on linuxtv.org:

start + 0: Y'00 Y'01 Y'02 Y'03 start + 4: Y'10 Y'11 Y'12 Y'13 start + 8: Cb00 Cr00 Cb01 Cr01 start + 16: Y'20 Y'21 Y'22 Y'23 start + 20: Y'30 Y'31 Y'32 Y'33 start + 24: Cb10 Cr10 Cb11 Cr11 

Video stream from the bundled camera

The CSI camcorder driver also provides video in M420 format, so you can use it with the H264 hardware codec driver directly.

Run the command ...

 cap-enc -s 1920x1072 -r30 -f1 /dev/v4l/by-name/vinc0 /dev/v4l/by-name/avico0 | gst-rtsp-launch 'fdsrc ! h264parse ! rtph264pay name=pay0' 

... and we get a working out-of-the-box RTSP stream with H264 video compression from a connected camera.

Video stream from file

With the compression of the video from the file, not everything was so simple. In the utility designed for this purpose, it is possible to convert video to M420 format on the fly. But this operation heavily loads the processor, as a result, the software part does not have time to issue the driver frames for compression, which leads to a noticeable decrease in fps. To solve this problem, I had to write a script that converts the video file to the M420 format in advance.

The second problem is that the video processing core is able to compress only frames whose size is a multiple of 16 pixels. With a resolution of 1280 x 720, everything converges - both sides of the frame are multiples of 16, but in Full HD (1920 x 1080) the height is not divided by 16. Thus, for video compression of 1920 x 1080, before transferring a frame, the driver needs to draw a strip of 8 pixels in order to get a height multiple of 16. The M420 format in this regard turned out to be very convenient due to the fact that the Y and Cb / Cr channels are in it together, and not one by one - just insert 1920 * 8 * 1.5 empty bytes into the end of the buffer.

As a result, H264 coding was achieved with a resolution of 1280 x 720 and with a resolution of 1920 x 1080, but with a “crutch” in the form of a strip of additional pixels. Both permissions consistently give a frame rate of 30 fps.

The video processing core VELcore-01 also supports H264 decoding at the hardware level, but at the driver level support for this function has not yet been implemented, so the experiment could not be carried out in this direction.


In general, the acquaintance turned out to be positive: 1892BM14Ya proved to be an excellent processor for industry and specials. applications where HDMI, graphics and multimedia are required. I liked responsive technical support.