The Raspberry Pi is an incredibly popular device, known for its availability, versatility, capabilities and active community. It is easy to find fan sites and articles, but most people are not aware of its weak points until they themselves suffer from them and search for information on the forums.

I will try to talk about some of the issues that I faced personally, as well as some typical problems that most often appear in people who are unaware of this. And finally, why I do not recommend Pi for some applications, in particular, NAS services, such as NextCloudPi and Open Media Vault. I hope this will save me time, so as not to repeat all this on the forums.

I have had a lot of Raspberry Pi, and I have been using them for years. When the first model appeared in 2012, it became an important milestone in the single-player market. Although there were already some good motherboards such as the Beagleboard and Odroid, they were quite expensive, and only hardcore lovers could buy and test them.

Pi is not as powerful compared to them, but because of the amazing cheapness it literally blew up the market. Blogs, expansion cards, lots of personal projects, tons of libraries ... Raspberry Pi was the first to achieve all of this, and to this day a thriving community is Pi's biggest advantage over other boards.

But now it's 2019 and it's time to look around again. In my opinion, there are more open alternatives of better quality at the same price. I will try to explain.

Performance

Raspberry Pi reduced the price by cutting corners. As a result, the board is not productive enough for some tasks, compared to competitors. In particular, it is poorly suited for network tasks and USB functionality.

Here stands the SMSC LAN9514 chip , which connects to the SoC with one USB channel, acting as a USB-to-Ethernet adapter and a USB hub at the same time. Thus, Ethernet and USB sit on the same channel and compete with each other, which is contrary to the typical use of the NAS, when something is downloaded over the network and stored on a USB drive, not to mention adding RAID here.

For the same reason, even when last year they finally released a model with Gigabit Ethernet support, the actual network performance never even came close to gigabit, and is 40 MB / s maximum in net speed and 20 MB / s maximum if Transferring to USB device . At that time, there were already cheap motherboards with true Gigabit Ethernet and USB3.

In fact, Wi-Fi does not come via SMSC , but connects to the BCM4343 chip via SDIO , so this bottleneck can somehow be avoided using Wi-Fi. However, the Wi-Fi chip is not omnipotent, it will have to deal with the surrounding interference, so this is not an ideal alternative.

For these reasons, I would not recommend using Pi as a NAS, whether it is Open Media Vault or Nextcloud.

Real Pi brain - closed source

If you participated in the software freedom debate, the main problem in our Linux systems is the binary source code blobs. I will not go into details, but the problem is that these parts of the system cannot be verified, and they have access to everything that happens in the device. This has generated large open source projects, such as Android Replicant , designed to free our systems from any binary blobs: a painful, tedious and slow process.

A similar problem with the Raspberry Pi, where the CPU and GPU are embedded in the same chip BCM2837B0 . The central processor is a 64-bit quad-core ARM A53 at 1,400 MHz (in Pi 3B), and the graphic processor is a dual-core 32-bit VideoCore IV with a frequency of 400 MHz. The integration of CPU and GPU is popular in the mobile world, because it reduces the price and power consumption. The NXP iMX and Allwinner competitors use a similar approach.

Thus, in the last Pi there are six cores, but only four of them are ARM. The processor runs Linux, but you may be surprised that Linux on this device is a second-class citizen. The GPU cores are running the ThreadX real-time operating system. This closed source operating system manages the system without the knowledge of the Linux kernel.

At the start of the Raspberry Pi boot, the processor is completely disabled (technically in the reset state) and it is the GPU that starts the system. You can take a look at the /boot folder - and find the binary blobs with which the GPU starts the processor and its own ThreadX OS ( bootcode.bin and start.elf ). Read more about the download process here .

It is the GPU that mounts the SD card, loads these blobs, and reads the configuration from the text file config.txt , which we are editing to adjust the video settings or overclock the GPU. Linux is not involved here.

When the GPU allows the CPU to load the Linux kernel, it does not just leave the stage, working only as a graphics processor . No, the GPU is still in charge. Have you ever thought who displays these logos when Pi connects to HDMI? Or are these symbols of lightning or temperature warning signs? That's right, this makes the system ThreadX on the GPU, and Linux doesn’t know what is going on at all.

We can not know all the functionality of the GPU, but we know something for which he is responsible. For this article, it is important that ThreadX monitors voltage reduction — a widespread problem, as we will see later, and reduces the frequency of the processor in order to prevent processor crashes and freezes. Therefore, in humans, the devices operate at a frequency of 600 MHz instead of 1400 MHz, at best. This throttling starts at 4.65 V and can also be triggered by temperature. At the same time, Linux still thinks that the system is operating normally at full frequency.

This is just what we see. Since the main OS is proprietary, we have no way of knowing what else it does or can do, so there is always the issue of privacy.

There is at least one patent included in the closed source blob that prohibits opening the code until at least 2025 , but we don’t know if it will be done even then. There have been attempts to reverse-engineer VideoCore IV and create open source firmware for it. Unfortunately, the project died before it gave something useful. As with Android blobs, this is an incredibly difficult job.

Power problems

This is not a technical error of the Raspberry Pi, but rather a typical user error.

The first model hardly used 80 mA, but each new generation became more and more powerful, and for this reason more energy-consuming. In addition, many users connect USB devices that also consume power if they are not supplied with their own power sources.

The microUSB connector was originally designed only for 1.8 A, and although this is an old standard, you can find chargers that give out more, so many people try to use old 1 A phone chargers or buy cheap adapters on the Internet to power their "Raspberry". But Pi is a computer, and it requires a high-quality, stabilized power supply that provides stable 5 V at the input with a current of up to 2.5 A. Not only a decent transformer is needed, but also a good connection (or a voltage drop will occur), but more importantly that you need a good cable , otherwise the voltage drops across it. Bad cables are more common than unstable voltage sources, so be sure to use a good cable: perhaps 20AWG or similar, or just buy an official power supply. The conclusion is that not any USB charger will work properly, even if it is 2.5A 5V.

Add this to what we discussed in the last section, and begin to understand the big picture. Most users work on their devices at a reduced frequency, and the GPU hides it from them, so they actually work at a reduced frequency of 600 MHz: almost the same as ARMv6 on the very first Pi.

In many cases, the GPU is not enough effort, and the system randomly crashes or just freezes, possibly damaging data or damaging the SD card. This usually happens under load , that is, when transistors need maximum power. Then the user comes to the forums and complains: my power supply is in order, I ran this and that, and nothing failed . Of course, this is not true, but often they do not believe it.

In my opinion, here is what the Japanese can call Poka Yoke , that is, we must design such systems that, by their design, will not allow the user to shoot himself in the leg. Again, the official power source is of very good quality for its price, and I highly recommend it.

I do not like the fact that the hidden proprietary system lowers the frequency beyond our control. It would be better if the system hung up: then you can immediately see what is happening, and a person can replace the power supply. In my opinion, this is better than deceiving users and forcing them to complain all over the internet . It is hard to imagine the reason why Pi developers would do this if they did not hide the problem of Poka Yoke.

Check for power problems

It took too much time, but we still managed to log the problem at the kernel level. If you see such a message in the system logs:

  kern: crit: [1701.464833 2.116656] Under-voltage detected!  (0x00050005)
 kern: info: [1707.668180 6.203347] Voltage normalized (0x00000000 

then you have a decrease in voltage. It's good that now Linux captures at least such information, but if we want to learn more, we need direct access to the GPU.

The vcgencmd command can get system information from the ThreadX firmware.

 # vcgencmd get_config int arm_freq=1000 core_freq=500 sdram_freq=600 over_voltage=6 disable_overscan=1 force_pwm_open=1 

You can use the vcgencmd measure_clock arm and vcgencmd measure_volts to check the actual frequency and voltage. Here is an example of the output from the tkaiser monitoring script .

 # With a crappy PSU and/or Micro USB cable output looks like this # on a RPi 3: # # 44.0'C 600 MHz 1010000000000000000 1.2V # 44.5'C 600 MHz 1010000000000000000 1.2V # 44.0'C 600 MHz 1010000000000000101 1.2V # 44.0'C 600 MHz 1010000000000000101 1.2V # 44.0'C 600 MHz 1010000000000000101 1.2V # 44.5'C 600 MHz 1010000000000000000 1.2V # 45.1'C 600 MHz 1010000000000000101 1.2V # # With an ok-ish cable it looks like this (when running cpuburn-a53): # # 48.3'C 1200 MHz 0000000000000000000 1.3312V # 48.3'C 1200 MHz 0000000000000000000 1.3312V # 48.3'C 1200 MHz 0000000000000000000 1.3312V # 48.3'C 1200 MHz 0000000000000000000 1.3312V # 50.5'C 1200 MHz 0000000000000000000 1.3312V # 56.4'C 600 MHz 0000000000000000000 1.2V # 54.8'C 600 MHz 1010000000000000101 1.2V # 55.3'C 600 MHz 1010000000000000101 1.2V # 55.8'C 600 MHz 1010000000000000101 1.3312V # 53.7'C 600 MHz 1010000000000000101 1.2V # 51.5'C 600 MHz 1010000000000000101 1.2V # 51.0'C 600 MHz 1010000000000000101 1.2V # # And only by bypassing the crappy connector you can enjoy RPi 3 # performing as it should (please note, there's a heatsink on my RPi # -- without throttling would start and then reported clockspeed # numbers start to get funny): # # 75.2'C 1200 MHz 1010000000000000000 1.3250V # 75.8'C 1200 MHz 1010000000000000000 1.3250V # 75.8'C 1200 MHz 1010000000000000000 1.3250V # 76.3'C 1200 MHz 1010000000000000000 1.3250V # 76.3'C 1200 MHz 1010000000000000000 1.3250V # 73.6'C 1200 MHz 1010000000000000000 1.3250V # 72.0'C 1200 MHz 1010000000000000000 1.3250V # 70.4'C 1200 MHz 1010000000000000000 1.3250V # # Now with a pillow on top for some throttling: # # 82.2'C 1200/ 947 MHz 1110000000000000010 1.3250V # 82.7'C 1200/ 933 MHz 1110000000000000010 1.3250V # 82.7'C 1200/ 931 MHz 1110000000000000010 1.3250V # 82.7'C 1200/ 918 MHz 1110000000000000010 1.3250V # 82.2'C 1200/ 935 MHz 1110000000000000010 1.3250V # 79.9'C 1200/1163 MHz 1110000000000000000 1.3250V # 75.8'C 1200 MHz 1110000000000000000 1.3250V # # And here on RPi 2 with crappy USB cable and some load # # 50.8'C 900 MHz 1010000000000000000 1.3125V # 49.8'C 900 MHz 1010000000000000000 1.3125V # 49.8'C 900/ 600 MHz 1010000000000000101 1.2V # 49.8'C 900/ 600 MHz 1010000000000000101 1.2V # 48.7'C 900/ 600 MHz 1010000000000000101 1.2V # 49.2'C 900/ 600 MHz 1010000000000000101 1.2V # 48.7'C 900 MHz 1010000000000000000 1.3125V # 46.5'C 900 MHz 1010000000000000000 1.3125V # # The funny thing is that while the kernel thinks it's running # with 900 MHz (performance governor) in reality the 'firmware' # throttles down to 600 MHz but no one knows :) 

Conclusion

I really think that Raspberry Pi has become a very important event in the history of single-board computers, but today it is lagging behind in terms of quality, performance and openness. There are alternatives available where the developers paid more attention to these issues.

Despite this, I still use Raspberry Pi, helping users install their own cloud hosting. Given the popularity of this board, for me it makes sense to support it as long as it is useful to people.