Domestic processor from ELVIS

Hello! Our article about the domestic Multiclet processor caused quite a lot of interest. True, many for some reason decided that this article was from the Multiclet itself.

This article will focus on domestic manufacturers of processors (microcontrollers). Now this topic is quite popular: for example, the OSDay conference was dedicated to this . In general, this time we got a board from the company ELVIS Electronic Computing and Information Systems . We dragged our Embox there and decided that users of the Habr would be interested to learn about this epic.

So, the processor, and more precisely the system on a chip (SOC), and more precisely, the “Integrated Circuit 1892ВМ14Я ”, as stated inuser manual has:

• two Cortex-A9 cores or, as the documentation says, a standard multiprocessor central processing unit (MPU) system in the form of a 2-core coherent ARM Cortex-A9 MPCore cluster with SIMD Neon coprocessors;
• two Dcore cores Elcore-30M
• built-in core of hardware-software graphic accelerator ARM MALI-300;
• the core of the hardware-software video accelerator “VELcore-01”;
• ...

We were interested in the Cortex-A9 cores, the rest, unfortunately, were not “felt”. We already had some support for Cortex-A9 for the i.MX6 and vexpress-a9 (qemu) platforms, so we hoped that everything would work right away. Looking ahead, I’ll say that almost happened.

Unpacking

So, the Salyut-EL24D2 board came to us , in appearance it was pretty well executed, and we were already joyfully wanting to supply power, but then we found out that there is a power connector, but we don’t see a connector for the console (UART).


Given that the kit included a USB adapter with RX / TX / GND / 3V3 / 5V outputs, it was most logical to start looking for a port with the same names. With a cursory glance at the board, nothing was found for any suitable inscriptions on the pins.


In addition to RS-485, in the manual in the list of connectors is an XP3 connector, which is compatible with RaspberryPi, which contains an RS-232 interface. It turned out that it is precisely what u-boot uses. As technical support explained to us, “on Salyut-EL24D1, the console is by default output to the port on the same Raspberry Pi-connector (UART0). UART3 ”is displayed on DB9. They also clarified that RS232 is a 12-volt interface, and UART (three-volt interface) was launched on XP3.

Having completed this task, we saw the Linux console (we will not list the whole listing) and found that the radiator included in the delivery is clearly needed, because without it, the processor is very hot.

U-boot issues

After a clear success, we started launching Embox, because, as already mentioned above, we had support for Cortex-A9, which means that we only needed the correct memory card (memory map) and the driver of that UART to see our console.

They found the memory card and the description of the UART in the documentation, wrote some drivers, but found that there is no network support in the installed u-boot, that is, you can download from the SD card, as Linux starts, well, or through the console via UART, that is, very slow.
To a clarifying question, the support service confirmed to us that there is no network support, since the drivers are not ported to u-boot.


The next significant problem was the cache and other settings that remain after u-boot, for example, the included address translation.

The problem was the following: the assembler program just writing something in UART worked, and even a small Embox (several tens of kilobytes) did not display anything with the same driver, and generally behaved very strange. As a result, it turned out that after filling the image into memory, you need to flush the cache. We contacted the support team, after some correspondence, they reproduced the situation, offered to rebuild u-boot with an additional flag, flash it in spi-flash, and also use the dcache flush command.

With the MMU turned on, there were also problems. In fact, the first thing we do in our bootloader is to turn off address translation. Enabled, if I understand correctly, MMU was just for enabling caching, in large ARMs, if I understand correctly, caching is defined in page descriptors. Why do I need to enable the cache in U-boot, to be honest I do not know, but it is possible to speed up the download.

Drivers

After dancing with the cache, Embox “took off”, displayed a command line in which it was possible to execute commands, because, as already mentioned, we had support for cortex-a9, and the Cortex-A9 standard also included an interrupt controller and timers, well, the ARMv7 standard contains work with MMU and caches. In general, I wanted to make a network card to try at least some interesting functionality.

The manual had a description of the network card, but of course I wanted to borrow the code as much as possible, or at least as an example. There was no indication what kind of IP-core it was, in the documentation the card was called “GEMAC”. On the Internet, there were no stubbornly source for this network card. In the support service, we were told that in fact this is a network card from Arasan, and the drivers were offered to look in Linux, the source of which is available (link ), because now in the vanilla core such a network card is not supported.

For the sake of interest, we looked at what else in this Linux has been finalized. Having executed the grep command, we got the following output:


As you can see, ELVIS uses third-party IP cores for many of its blocks, and the blocks are sometimes so new that you have to modify the drivers yourself.

Having started the development of the driver, for a long time we could not understand why we did not see anything in its registers, we checked the base address, we stupid, while in those support we were not told that it was necessary to apply a frequency to this module. The power management control module or, as described in the manual, the PMCTR controller allows you to control not only the power supply, but also the device clock frequency. As a result, the reading and writing of registers started working, but the lights did not light up on the PHY, that is, there was no link, and PHY itself did not respond to any MII interface.

In the support service, we were offered to do the same as in Linux, but it was completely incomprehensible that we had forgotten this. That is, there was a suspicion of the reset function, or rather, it was necessary to set the corresponding GPIO to one, but it was not easy for programmers who did not like to read the documentation to determine which GPIO controller was used, which leg. Fortunately, the port and contact number were prompted in support (PORTB1). The configuration search told us that the dwapb_gpio driver was being used. After correctly implementing the GPIO interface and supplying a unit to this port, the link caught fire, PHY was detected on the seventh port of MII. There were no further significant problems, of course there were ordinary problems with errors in implementation, but there were no special ones, as a result the network card worked.

To test the performance, they launched a telnet:



Actually, everything works quite sane.

conclusions

Of course, the processor from ELVIS cannot be compared with the Multiclet, the companies have too unequal weight categories. But it is worth noting that the completeness of the solution is also completely different. Of course, you can refer to ready-made software for Cortex-A9, but even its development is a significant and resource-intensive problem, which Elvis solves, though not perfectly, but is quite sane. Or take a support service: it is also far from ideal and global companies, but still you can achieve results from it in an acceptable time frame.

Therefore, with all the pros, I will focus on the cons.

The main minus, in my opinion, is just that purchased blocks are used. This is an absolute plus for entering the market, but the Cortex-A9 can hardly be called a domestic processor. I understand perfectly that there are two more DSP cores, but still the basis is third-party blocks with very low added value, as we like to say recently. That is, the money from this chip is mainly developed by engineers of companies from which these cores were purchased (ARM, ARASAN and others), and which develop the corresponding software.
Compared with the same i.MX 6, consumption is much higher, although ELVIS said that unnecessary blocks must be disabled, and then consumption will be comparable. Probably it is, because the processor cores are the same.

The price, to put it mildly, is high. ELVIS, of course, states that the overall performance of the microcircuit is also very high, but something I doubt that having several DSP cores can increase it enough to make it attractive compared to the same i.MX 6. That is, I assume that there are a number of tasks for which price is not important, for example, avionics, but it is not clear why there are DSP kernels.

The target market is not clear. As stated in the previous paragraph, due to the high price and high performance, it is incomprehensible (very narrow) the class of tasks for which the use of this chip would be justified, with the exception of those places where only domestic equipment can be used. References to cameras with pattern recognition and counting the number of visitors that, as I know, exist, personally do not convince me very much, as well as statements that a line of Western buyers has already been lined up.

Let me finish on this. In general, I personally like that, although with difficulties, domestic microelectronics is developing.

Traditionally, everything that is written in the article can be reproduced from source .

PSIn the minuses, a personal opinion was expressed, I think ELVIS will find decent answers to my complaints :)


Regarding the temperature, I admit that a temperature of 50 degrees might well seem uncomfortable for such a convolutional measuring tool like a finger :)

In addition, those support told us that “as of today, this support is already integrated into U-Boot, it will be in next release of Buildroot ”