Amiko Viper 4K V20 BETA

Amiko Viper 4K V20: technical description

Everything we learned about this receiver while building the HD Satelit image for it: the processor, the memory, the tuners, the video output, the software inside, how it starts and how to repair it. Each part starts with a plain explanation, followed by details for enthusiasts and developers.

In short

The Amiko Viper 4K V20 is a 4K satellite receiver with two tuners: one for satellite (DVB-S2X) and one combined tuner for cable and terrestrial aerial (DVB-C and DVB-T/T2). The same mainboard is also sold under other brands (see “Related receivers”). Inside is a HiSilicon Hi3798MV200 chip: a single chip that contains the processor, the graphics card, the video and audio decoders and the HDMI output.

The picture you see on the TV is produced by the chip's video blocks, not by the processor. That is why a 4K channel does not load the processor: while you watch TV, the processor stays at its lowest frequency almost all the time.

Below, each part starts with an explanation for anyone, followed by details for enthusiasts and developers. The figures were measured on a test Viper 4K V20 or come from the chip's public documentation.

Board and processor

The processor (CPU) runs the software: the menus, the programme guide, the channel scan, the web interface. Its frequency, in megahertz (MHz) or gigahertz (GHz), tells you how fast it works: higher means faster, but also hotter. The processor changes its frequency by itself according to how much work it has, so that it does not heat up for nothing.

The mainboard carries the marking VV98M E2 SI_VER05. It is made by Dinobot, which also uses the same board family (VV98M E2, in another revision) in the Dinobot 4K Twin receiver. The main chip, the HiSilicon Hi3798MV200, is a “system on chip” (SoC): the processor, the graphics card, the video decoders, the picture processor, the 2D engine, the HDMI output, the sound processor and the demultiplexer are all inside it.

The processor has 4 ARM Cortex-A53 cores (identifier 0xd03), with NEON and VFPv4 instructions for calculations and dedicated instructions for AES, SHA1, SHA2 and CRC32, which speed up encryption and checksums. The Cortex-A53 is a 64-bit core (ARMv8), but the system uses it in 32-bit mode (armv7l), and the software is compiled for cortexa15hf-neon-vfpv4.

In our tests while watching TV (SD, HD and 4K channels, changing channel every two minutes), the processor stayed at 400 MHz in 91% of the readings and only went higher when the channel changed.

The load average shows around 12 when idle. This does not mean the processor is busy: these are driver threads that are waiting, and Linux counts them too. At the same time, the processor is about 90% idle.

Temperature and thermal protection

Every chip heats up when it works, and high heat can make it work incorrectly or wear it out over time. That is why the driver watches the temperature and slows the processor down if it gets too hot.

The chip has its own temperature sensor, read by the HiSilicon driver (the usual Linux interface for temperatures, /sys/class/thermal, is missing on this receiver). We measured the temperature in several situations, with one reading every 5 seconds:

Conclusion of the tests: while you watch TV, the temperature hardly depends on the processor frequency, because the picture is produced by the video blocks. The 1600 MHz step helps with short peaks (changing channel, menus), but under a long load on all cores the receiver quickly gets close to 95 °C. At 1200 MHz, the same load stayed below 95 °C for 10 minutes.

How the HD Satelit image uses the processor steps and what it does when it heats up is described under “Processor and heat”, in the “What it brings” list.

Working memory (RAM)

RAM is the working memory: it holds the programs while they run and the video frames while they are decoded. It is cleared when the receiver is switched off. On a receiver, part of it is reserved at startup for the video hardware, so that the decoder always has room, however many programs are running.

The receiver has 1 GB of DDR3 memory, in two SK hynix H5TQ4G63CFR chips of 4 Gbit each, each connected on 16 bits (a 32-bit bus in total). At every startup, the bootloader prepares the memory with the table hi3798mv2dma_hi3798mv200_DDR3-1866_1GB_16bitx2_2layers.reg, that is, for 1 GB of DDR3-1866 memory in two 16-bit chips.

MMZ (media memory zone) is a continuous block of physical memory, managed by the hi_mmz module. The chip's video blocks work in it: decoded frames are stored here in NV21 format and go from the decoder to the picture processor and then to the output, without passing through the programs' memory.

Internal memory (eMMC) and partitions

The internal memory (eMMC) is a kind of small SSD soldered onto the board: it keeps the system, the settings and the channel lists even when the receiver is switched off. It is divided into partitions, each with its own role. Only the last two contain the Enigma2 image; the others belong to the startup and to the device data, and they do not change when you install an image.

The memory has 7,675,904 sectors of 512 bytes each, that is 3.66 GiB (3748 MiB); it is sold as 4 GB memory. The chip identifies itself as G4MYM0 and works in HS400 mode, on an 8-bit bus. Besides the main area, it has two small boot areas, boot0 and boot1, of 2 MiB each, and a protected area (RPMB) of 128 KiB.

The kernel boot line starts with console=ttyAMA0,115200 root=/dev/mmcblk0p10 rootfstype=ext4 rootwait, continues with the partition list (blkdevparts=mmcblk0:...), in the same order and with the same sizes as in the table, and ends with mem=1G mmz=ddr,0,0,96M vmalloc=500M. In the list, the rootfs partition is declared with 7200 MB and is followed by one called others, but the memory only has 3.66 GiB: rootfs stops at the end of the memory, and others does not exist.

When you install an image from a USB stick, only p9 (from the kernel.bin file) and p10 (from the rootfs.tar.bz2 archive) are written. Partition p6 is different on every device: a copy taken from another receiver would bring that receiver's MAC address and data.

Tuners

The tuner receives the signal from the aerial or from the cable network and turns it into data that the receiver can decode. The Viper 4K V20 has two independent tuners: one for satellite and one combined tuner for cable or terrestrial aerial.

DVB-S2X is the newest version of the satellite television standard, after DVB-S and DVB-S2. DVB-C is the standard for cable television, and DVB-T and DVB-T2 are the standards for terrestrial aerials; DVB-T2 is the newer version.

Tuner B works on one thing at a time, either cable or terrestrial. The program that uses it reads, when it opens it, the list of systems it supports (DTV_ENUM_DELSYS) and tells it at each tuning what kind of signal is coming (DTV_DELIVERY_SYSTEM).

Amiko presents the satellite tuner as DVB-S2X Multistream. The list of systems that the driver gives through the DVB interface contains only DVB-S and DVB-S2; the DVB-S2X type appears separately, in the system's tuner description (/proc/bus/nim_sockets).

DAB+ radio and DVB-T2 programmes transmitted via satellite, from the “What it brings” list, are received through the satellite tuner. While they run, the tuner is busy, because the receiver has only one tuner for satellite.

Picture: resolutions, HDR, colours

The resolution tells you how many dots the picture has: 2160p means 3840 x 2160 dots (4K), 1080p means 1920 x 1080 (Full HD). The letter “p” stands for “progressive”, meaning each frame is complete, and the number of hertz (Hz) is the number of frames per second.

HDR (high dynamic range picture) brings brighter highlights and more shades between white and black. There are several kinds of HDR; this receiver supports HDR10 and HLG, and the TV must support them too. The colour space tells you how many colours the signal can describe: BT.709 is the one used for normal HD pictures, BT.2020 is wider and is used for 4K and HDR.

The channel picture and the menus are two separate layers, placed one on top of the other only at the output: the channel can be 4K, while the menus are drawn at 1920 x 1080 and scaled up.

The conversions done by the chip's display block: HDR10 to SDR, HLG to SDR, SDR to HDR10, SDR to HLG, HDR10 to HLG, HLG to HDR10, BT.2020 to BT.709 and BT.709 to BT.2020. This way, an HDR channel can also be watched on a TV without HDR, and a normal (SDR) channel can be sent out as HDR. In SD modes (576 and 480 lines), the HDR output cannot be used.

The HDR output type (automatic according to the channel, HDR10, HLG or SDR) is applied the next time the channel starts, after about 30 frames (around 0.6 seconds at 50 frames per second). When you switch from an SDR channel to an HDR one, the screen may stay black for a moment: the HDMI driver waits 500 ms when the mode changes, and when leaving HDR it sends an empty HDR signal for 2 seconds, so that the TV returns to SDR. In the HD Satelit image, you choose this under “HDR output”.

The HDMI bandwidth sets a limit. At 2160p50 with 10 bits, an RGB or YCbCr 4:4:4 output would need a 742.5 MHz clock, above the 600 MHz that the test HDMI 2.0 TV accepted. That is why 10-bit 4K HDR is output as YCbCr 4:2:2 or 4:2:0. The HDMI driver chooses the colour space and the depth by itself, according to what the TV reports. At 1080p50 (148.5 MHz) any combination fits.

For developers: the HDR choice goes through /proc/stb/video/hdmi_hdrtype (auto, hdr10, hlg, none; an empty or unknown text means SDR), which the platform program reads every time a channel starts. A write to /proc/stb/video/hdmi_colorimetry is applied immediately, but it switches the output to YCbCr 4:4:4 with 30 bits until the next restart; in HDR, the HDMI driver sets BT.2020 colorimetry by itself.

Hardware video decoding

A TV channel arrives compressed, so that it fits in the signal. The decoder unpacks it into frames, then the picture processor cleans up each frame and scales it to the output resolution. On this receiver, all of this is done by dedicated blocks in the chip, not by the main processor and not by the graphics card. The result is a smooth 4K picture without loading the processor.

The less visible part: a program that wants to use the decoder must send it the data along its own path. The usual players on a computer do not know this path. The route of a channel through the chip looks like this:

A measured example: an interlaced 1920 x 1080 H.264 channel at 5.38 Mbit/s leaves the frame processor at 50 frames per second and is scaled by the display block to 3840 x 2160, 50p. An interlaced 720 x 576 SD MPEG-2 channel is also scaled by it, up to 2160p. Scaling uses a filter with 8 taps and 32 phases for brightness and 4 taps for colour.

The picture processor (PQ) has a factory profile, chosen according to the source width: up to 720 dots SD, up to 1920 HD, up to 4096 UHD. On SD channels, deblocking (DB), edge cleaning (DM) and noise reduction (TNR and SNR) are on; on HD channels, temporal noise reduction (TNR), sharpness, adaptive contrast (ACC) and colours (ACM) stay on, while DB, DM and SNR are off. The settings come from the pqparam partition and are not kept after a restart. The super-resolution function from the chip's data sheet is not used by the driver. The HD Satelit image adds its own profiles on top of these (“Picture quality profiles”, in the “What it brings” list).

The Mali-450 MP2 graphics card (600 MHz, OpenGL ES 2.0 and 1.1) takes no part in the TV picture: while a channel plays it stays idle, at 0% usage. It could not scale any better either: a filter of the same quality at 4K and 50 frames per second would need 4.8-5.6 billion reads per second, 3 to 4.7 times its peak of 1.2-1.6 billion pixels per second.

Why hardware decoding does not work in computer players such as VLC: on this chip, the decoder is not used through the usual Linux interfaces (V4L2 M2M or VA-API), but through the HiSilicon modules, which work with the MMZ memory (hi_mmz) and with the decoder (hi_vdec). A player that decodes into normal memory would do everything on the processor: the processor at full load, heat and dropped frames. Players that work are those that send the compressed data directly to the decoding device /dev/dvb/adapter0/video0, for example GStreamer with dvbmediasink or exteplayer3, and the player built on the HiSilicon libraries (servicehisilicon).

Enigma2 does not use the HiSilicon libraries directly either: it works with the DVB devices (/dev/dvb/adapter0) and with the /proc/stb files, which are created by a module from the board manufacturer, loaded under the name firedtv.

Sound

Channels send sound in several formats. The usual ones, such as MPEG audio or AAC, are converted to stereo by the receiver itself. Multichannel sound (5.1), in AC3 or DTS format, can be handled in two ways: converted to stereo by the receiver (downmix) or sent unchanged over HDMI (passthrough), so that the TV or the amplifier decodes it.

With downmix, an AC3 track plays in stereo (tested on one channel); DTS and E-AC3 should behave the same, but we have not tested them yet. With passthrough, the receiver puts the frames into the form required by HDMI (IEC 61937) and passes them on without decoding them.

Real 5.1 sound reaches the speakers only through passthrough, and only if the device connected over HDMI reports that it accepts the format. An AAC 5.1 track cannot be sent as 5.1 without re-encoding, so it stays stereo.

The chip's sound processor has no equaliser; an equaliser has to run on the main processor. The one in the HD Satelit image is described under “Equaliser”, in the “What it brings” list.

Network, USB ports, display and remote

The receiver connects to the internet by cable (Ethernet) or wirelessly (Wi-Fi). You can connect USB sticks, drives or a keyboard to the USB ports. USB 3.0 transfers up to 5 Gb/s, more than ten times as much as USB 2.0 (480 Mb/s), which matters for large files.

The front display shows the time, the channel or other information, and the remote sends commands by infrared.

The front display is written first by the bootloader at startup (for example MENU and, in update mode, UPDT), then by the system driver, through the /dev/dbox/oled0 device. What the display shows with the HD Satelit image is described under “Front display with lots of data”, in the “What it brings” list.

The USB controllers are compiled directly into the kernel, not as separate modules, so they work from the first seconds of startup.

Software inside: the kernel and the drivers

The kernel is the core of the Linux system: it shares the processor and the memory between programs and talks to the receiver's hardware through drivers. On this receiver, the drivers for the main hardware (tuners, decoders, HDMI, display) are supplied by the board manufacturer as ready-compiled modules, for a specific kernel version. That is why the kernel stays at version 4.4.35: a newer kernel could not load these modules.

The system has several layers, all supplied by the board manufacturer:

The modules are tied to the exact version and configuration of the kernel they were compiled for, and their source is not public. The set from 9 December 2021 is the last one published for the u57 board. Other manufacturers that use the same chip have published newer sets, but each is made for its own board. The kernel of the HD Satelit image is compiled by us, also at version 4.4.35 (with GCC 15.2), so that the manufacturer's modules load unchanged.

Modules loaded at startup, by role: hi_mmz (MMZ memory), hi_vfmw and hi_vdec (video decoding), hi_vpss (frame processing), hi_vou (display), hi_pq (picture quality), hi_hdmi (HDMI output), hi_demux (demultiplexer), hi_adec and hi_adsp (sound), hi_fb (graphics layer), hi_tde (2D engine), mali (graphics card), hi_tuner (tuners), hi_keyled (front display and buttons), hi_ir (remote).

The reference kernel configuration for u57, for developers: the USB controllers (EHCI, OHCI, xHCI) are built into the kernel; CONFIG_PANIC_TIMEOUT=0, so after a panic the kernel stays halted and does not restart by itself; CONFIG_KEXEC and loop devices are enabled, OverlayFS is missing; FUSE and WireGuard are built into the kernel.

How the receiver starts

At startup, several programs run one after another, each preparing the next: a fixed program in the chip, the bootloader, the Linux kernel and, finally, Enigma2. In the first seconds it is also decided whether the receiver starts normally or enters update mode from a USB stick. The steps, in order:

• The BootROM, the fixed program in the chip, reads the start of the eMMC memory, writes “Bootrom start” on the serial console and prepares the DDR3 memory with the table from the bootloader.
• The fastboot 3.3.0 bootloader in p1 reads the boot variables from p2 (64 KiB from 1 MiB, checked with CRC32), draws the logo from p5 on HDMI and starts the front display and the button reading.
• The display shows MENU. If you press the GREEN key on the remote at this moment, the bootloader starts the updater in p7 and the display shows UPDT. Otherwise, startup continues normally.
• The bootloader reads 32 MiB starting from sector 0x1d000 (58 MiB, the start of p9) to address 0x1FFFFC0 and starts the kernel: bootcmd=mmc read 0 0x1FFFFC0 0x1d000 0x10000;bootm 0x1FFFFC0. With bootdelay=0, it does not wait for any key on the serial console.
• The Linux 4.4.35 kernel starts. The small boot system inside it (initramfs) finds the root on /dev/mmcblk0p10 and mounts it as ext4.
• The manufacturer's script loads the HiSilicon modules and sets the processor cap to 1200 MHz; the platform program (showiframe) takes over the video and sound devices.
• Enigma2 starts. The logo drawn by the bootloader stays on screen until the interface replaces it.

If the root in p10 cannot be used, the kernel stops (it panics) and stays that way: the logo on screen, nothing on the network, because the kernel is configured not to restart by itself. In that case you repair the receiver through update mode, which does not depend on the image in p9 and p10.

The updater in p7 has its own kernel (Linux-4.4.35_hi3798mv2x, dated 17.08.2020), which works with 128 MB of memory. It mounts the USB stick, looks for the image in a specific folder, runs the ofgwrite program, which writes the kernel to p9 and the system to p10, and then restarts the receiver.

Serial console (for developers)

The serial console is a connector on the board through which the receiver writes everything it does at each startup: the BootROM, the bootloader, the kernel, update mode. It shows what is happening even when the receiver has no network and shows nothing on the TV. Normal users do not need it: the image is installed and restored from a USB stick, without opening the receiver.

On the Viper 4K V20, the console in Linux is the ttyAMA0 device (UART0), at 115200 bits per second, 8N1, without flow control. During a normal startup you see the messages from the BootROM, the bootloader and the kernel, up to the mounting of the root; in update mode, the updater in p7 writes all its steps there.

Warning: opening the receiver and connecting an adapter to the board are only for people who know what they are doing, and are done at their own risk. A wrong connection can damage the board or the adapter. You do not need it to install or restore the image.

Recovering the receiver

If an image no longer starts, you can restore the receiver without opening it, through update mode (Maintenance Mode). This is a separate program, in partition p7, that starts even when the image in p9 and p10 is damaged.

In short: on a FAT32-formatted USB stick, put the extracted files kernel.bin, rootfs.tar.bz2 and imageversion in a specific folder. Insert the USB stick into the blue port (USB 3.0), switch the receiver on at the mains, and when the display shows MENU, press the GREEN key on the remote. The display shows UPDT, the receiver writes the image and restarts by itself. Do not cut the power during this time. The exact steps and the folder are described where you download the image.

UPDT on the display only means that the updater has started, not that it has written anything. A real write takes a few minutes. If the folder is not found, the receiver restarts in less than a minute without writing anything.

The folder name is stored in a tag in partition p6 and is rewritten at every startup by the platform program, according to the image that is running. With the HD Satelit image, the updater looks in amiko/viper4kv20/; after other images it may look in another folder, for example e2/update/.

When even the bootloader no longer starts, rewriting can only be done with HiSilicon's HiTool utility: the bootloader is sent through the serial console, and the other partitions over the network (TFTP). This is a job for specialists, with real risks. Rules that protect against permanent damage:

• Never write a bootloader, a partition or a recovery package made for another model, not even for the Viper 4K V30 or V40: the internal memory, the DDR memory table and the device data are different, and the receiver can end up permanently bricked.
• If the receiver still shows the logo and MENU, the bootloader (p1), the boot variables (p2) and the updater (p7) work; do not rewrite them, and do the repair through update mode.
• Partition p6 (deviceinfo) is unique to each device. Anyone working at this level first keeps a copy of partitions p1-p9 of their own receiver, made while it still works; it is better than any package made from another device.
• The bootloader also contains commands that blow internal fuses in the chip (OTP). They are irreversible and can make the chip accept only signed software, for ever. Never run a command that starts with “otp”.
• Do not use a full erase of the internal memory (EraseAll in HiTool).

Related receivers (same board)

The same board, with the internal name u57, is also sold under other brands. They all have the same chip, the same kernel and the same drivers; what differs is the name, the remote, the folder where the updater looks for the image on the USB stick and, on one model, the layout of the internal memory. In brackets is the model name in the image build system:

The folders in the table are those from each model's build configuration, and the remotes differ in their keymap. An image made for the V20 must not be installed on the other models: each one needs its own build.

The Viper 4K V30 has the same board but, according to a test published on a specialist forum, it has 8 GB of internal memory, and a full memory copy taken from a V20 does not start on a V30. The Viper 4K V40 uses the same chip on a different board (u571), and the first Viper 4K (V10, internal name viper4k) has a different memory layout (kernel on p12, root on p16).

Of the 420 receiver models we follow, 73 are built on the same Hi3798MV200 chip: besides the 8 above, models from Octagon, Zgemma, GigaBlue, AB-COM and others. They have their own boards, drivers, memory layouts and recovery methods. The status of each model for the HD Satelit image is on the Receivers page.

What the HD Satelit image brings to this receiver

The image's features are in the “What it brings” list on the home page and, in detail, in the online help. On the Viper 4K V20, the HD Satelit image is in beta: it works on the receiver and testing continues.

The image is based on the enigma2 code published by Dream Multimedia and, for this receiver, keeps kernel 4.4.35 and the board manufacturer's drivers described above. Several features in the list relate directly to the hardware on this page: “HDR output”, “Picture quality profiles”, “5.1 sound sent only where it can be played”, “Equaliser”, “Processor and heat”, “DAB+ from satellite” and “DVB-T2 from satellite”.

Last updated: 23.10.2026.