Orange Pi 2G-IOT: minefield map

Some time ago, I was offered to work a little with a single-board PC Orange Pi 2G-IOT (built-in 2G and the price looks very attractive). After reading a post about the Orange Paradise , I thought that I would repeat this path without difficulty, especially since with Linux I am on the “you” (or rather, I thought about three weeks ago) and already had experience with Raspberry Pi 2 B +. In practice, this path turned out to be much longer. There was a feeling that our Chinese friends intentionally created difficulties (and sometimes with special cynicism). If you want to save money and buy this board, then first read this post and think again.

If possible, I will try to restrain emotions or at least translate them into humor.
So, here I get into the hands of the board and the SD card of the tenth class. Go.

Everything written below refers to the Orange Pi 2G-IOT model, but in the Telegram chat (look for “Orange Pi and not only”) they say that the 2G, 3G and 4G models behave the same way (equally bad). The written does NOT apply, for example, to the Orange Pi PC and Orange Pi One, which, according to reviews, behave stably.

Mina No. 1 (training): downloading the OS image

It would seem that could be easier? We go to the manufacturer’s website and download. However, all links lead to, which collects it directly in the browser. My cheap laptop with 4 GB of RAM did not pull such a task and the tab fell. One could use a proprietary program for downloading from Mega, but it did not inspire confidence in me (especially since some people write on the Internet that the program is recognized by antiviruses as malware). Solution options: download from an unofficial site (for example, here ), deploy a virtual machine and put in it a client for downloading from Mega, ask someone with a more modern PC to download the image.

A little more about OSes for orange
For many Orange models, users recommend Armbian, but he didn’t impress me on 2G-IOT: it looks like minimalistic Raspbian. By the way, there is no image for 2G-IOT on the Armbian website, only on the Orange Pi website. I also tried Ubuntu Server, but it didn’t show any signs of life at all. The Android built-in NAND seems to be working, but I did not study it at all, most likely, without a touch screen it is of little use. By the way, I remind you that the boot device is determined by the position of the jumper in the corner of the board, by default there is a boot from the built-in NAND memory.

Mina No. 2: Internet access via modem

Following verbatim the configuration of wvdial and pppd on the Internet, I suddenly found out that ping requests were passing fine, but regular TCP packets weren’t in any way:

orangepi@OrangePi:~$ curl --interface ppp0
curl: (7) Failed to connect to port 80: Connection timed out
orangepi@OrangePi:~$ curl --interface ppp0
curl: (7) Failed to connect to port 80: Connection timed out
orangepi@OrangePi:~$ curl --interface ppp0
curl: (7) Failed to connect to port 80: Connection timed out
orangepi@OrangePi:~$ curl --interface wlan0
orangepi@OrangePi:~$ ping -I ppp0
PING ( from ppp0: 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=52 time=664 ms
64 bytes from icmp_seq=2 ttl=52 time=240 ms
64 bytes from icmp_seq=3 ttl=52 time=234 ms
64 bytes from icmp_seq=4 ttl=52 time=246 ms
64 bytes from icmp_seq=5 ttl=52 time=241 ms
64 bytes from icmp_seq=6 ttl=52 time=237 ms
--- ping statistics ---
7 packets transmitted, 6 received, 14% packet loss, time 6032ms
rtt min/avg/max/mdev = 234.634/310.971/664.998/158.370 ms

The solution prompted edtun : , although I admit that it could have been somehow simpler.

Immediately alerted that the IMEI modem is packed with zeros. Fortunately, the red-white telecom operator does not pay attention to this. (By the way, the built-in WiFi similarly does not have a MAC address: it is randomly generated with every jerking of the power supply.)

Mina No. 3: USB port

We stick a WiFi whistle in the USB connector and ... Nothing happens. lsusb displayed an empty USB port. A little digging showed that the board really only has one USB. And by default, it is connected to the microUSB port. To switch it to a regular USB HOST, you need to switch the jumpers on the board, which are located next to the jumper to select the boot. Their description is on Solution: switch jumpers to position: 1234 down, 5678 up. Only then did I find a small mention of this nuance in the Orange Pi manual.

Mina No. 4: Drivers

Now the device is detected in the system, lsusb displays the manufacturer and product code, but the wireless network interface is not detected in the system. Because the developers did not deliver drivers for WiFi adapters on an orange. And none at all. There is a driver only for built-in WiFi, no more and no less. And what do we do when we do not have a driver for our hardware? That's right, let's collect them from the source code !

Mine # 5: Preparing to Build

In correspondence, bad__day suggested assembling directly on Orange Pi. Maybe this is possible, but I failed.

For Orange Pi, the developers made a special Orange Pi Build System, with the help of which, in theory, to assemble the kernel or modules, it is enough to simply follow the instructions on the screen. Detailed instructions are given in the manual starting on page 61. It would seem that just follow, and everything will be fine, but no.

Firstly, in order not to manually edit all the dependencies on my computer (I regularly update software, this is great, but not this time), I deployed a virtual machine with Ubuntu 16.04 and carried out all the actions there. Secondly, an error crept in the scripts somewhere, and the Build System did not put a toolchain for cross-platform compilation. This is solved such a crutch:

  1. Manually apt-get'om put the toolchain for cross-compilation for ARM.
  2. Making symlinks:
    mkdir $HOME/OrangePiRDA/toolchain/bin
    ln -s $(which arm-linux-gnueabi-ld) $HOME/OrangePiRDA/toolchain/bin/arm-linux-gnueabi-ld
    ln -s $(which arm-linux-gnueabi-gcc-4.9) $HOME/OrangePiRDA/toolchain/bin/arm-linux-gnueabi-gcc
    ln -s $(which arm-linux-gnueabi-g++-4.9) $HOME/OrangePiRDA/toolchain/bin/arm-linux-gnueabi-g++
    ln -s $(which arm-linux-gnueabi-ar) $HOME/OrangePiRDA/toolchain/bin/arm-linux-gnueabi-ar
    ln -s $(which arm-linux-gnueabi-nm) $HOME/OrangePiRDA/toolchain/bin/arm-linux-gnueabi-nm
    ln -s $(which arm-linux-gnueabi-objcopy) $HOME/OrangePiRDA/toolchain/bin/arm-linux-gnueabi-objcopy
    ln -s $(which arm-linux-gnueabi-size) $HOME/OrangePiRDA/toolchain/bin/arm-linux-gnueabi-size
    Please note: the compiler is taken version 4.9, nothing will be collected on versions above.
  3. Open OrangePiRDA / scripts / and just in case, comment on lines that mention the toolchain.

In fact, all these scripts just call apt-get install -y ... and make. The script does not offer the user to change the configuration in any way (or didn’t I find it?).

But after all, nothing prevents us from calling ourselves

make menuconfig

and mark the necessary drivers. We do this and collect again (now only modules are possible) and ...

Mine # 6 (with a screwed-on IR motion sensor and a spare detonator): Driver assembly

... And then the script kindly began to ask questions about how to configure the kernel. He called up the old-fashioned kernel configurator, but why ?! What's wrong?

It turned out that the Makefile is written to check the TIME (!!!) changes to the config!

The comment reads literally "someone was digging." (In the screenshot, the already modified Makefile, I prescribed menuconfig.) I tried calling make oldconfig, I didn’t notice that this changed anything somewhere. Okay, now after the menuconfig is called during the assembly, it's not scary. I call the assembly again, the assembly notices that “someone was digging into the config”, calls menuconfig, I exit and wait for the completion. Now imagine my surprise when I did not find the driver I selected.

Disclaimer before reading
At this point, I left the understanding of what is happening, and also I finally lost touch with reality, common sense and civilization from the planet Ross 128 b. I went beyond the boundaries of my knowledge, of all my friends and TARDIS. I started to create complete nonsense, and the only goal was to collect this [CENSORED] driver at all costs. If, when reading the text above, you grabbed your head more than two times, then do not read the text below. It will be calmer both for you and me. If you can give a clear explanation of what is happening and explain where I am wrong and how to, then please tell me. You are welcome.

Well, we climb to understand. It turns out that make creates the modules.order file, which describes all the modules that will be compiled. And even after all the configuration changes and its saving, this file is filled with the same set. I did not come up with anything better than manually adding lines to it (my whistle is assembled on the RTL8192CU chipset):


All references to this file in the Makefile were replaced by modules.order.fake. I start the assembly. This time, the assembly went, but broke off, since there is no similar file in the rtlwifi source code folder. I renamed the modules.order.fake files to modules.order in this folder and subfolders, and this was my last adventure in building the driver. After that, the system showed me menuconfig two more times, as if asking me “do you really want this?”, But nevertheless collected three more treasured .ko files, which wound up as expected.

Mina No. 7: Joint work of an external WiFi and a modem

Having played a little with airodump and making sure that the device can at least catch packets in monitor mode, I decided to check the modem again. Doing

sudo wvdial

And the LED on the external WiFi adapter goes out, and SSH falls off. Then I read in the logs that the adapter was disconnected. The first thought is a nutrition problem. Until that moment, I used my charger for 1.5 Amperes, and the manufacturer recommends as many as 3 (so much? She doesn’t even eat one Ampere ). At hand was a 2-amp charger, which for years regularly fed the Raspberry Pi.

At the moment, I have not found any stable solution to this problem. Here are some solution attempts:

  • With a 80% probability, you can disable external WiFi using:

    chmod 777 /sys/bus/usb/drivers/usb/unbind
    echo 1-1 > /sys/bus/usb/drivers/usb/unbind

    and then run wvdial, which will establish a connection with 1-3 attempts and you can go online. In 20% of all kinds of hangs and glitches.
  • Once, by chance, it turned out that wvdial was killed, but pppd remained working (how could it be?), After which external WiFi rose (see above, we write bind instead of unbind) and there was a connection through the modem. It was not possible to reproduce the situation.
  • It turned out that without rebuilding the kernel, you can turn off the power to USB using such a utility with the command

    ./hub-ctrl -h 0 -P 1 -p 0

    and turn on the power
    ./hub-ctrl -h 0 -P 1 -p 1
    On 2G-IOT, the behavior is unpredictable: a power outage can be either for one second, or before a reboot. In some phases of the moon, an attempt to return power causes the board to freeze.
  • Switch the jumpers to OTG (1234 up, 5678 down), feed power to the legs of GPIO 2 and 6 (ringing, they are directly connected to microUSB power)


    Connect the WiFi adapter via the USB-OTG adapter from the smartphone. The system does not see the USB device at all. Perhaps you need to persistently play with jumpers.

Not tested, but it may work (plans to try all of these options):

  • Another WiFi adapter.
  • Very stable power supply with a maximum current of 3 Amps.
  • Extra power to USB feet.
  • Gasoline and matches.

In general, the task looks like pulling a triangular blanket over a quadrangular orange.

That's all for now.

I would like to express my gratitude to bad__day , edtun , A. Repin, forum users from , old-timers in the Telegram chat and Kotu, who patiently listened to me all this time and almost did not try to escape.

UPD: Today they brought me a power supply with a 5V 3A output. With it, it was possible to simultaneously launch both the modem and the USB WiFi adapter. The modem spills errors, stops responding, but on average it connects from the third attempt. After that, you can use USB WiFi.


The single-board Orange Pi 2G-IOT is very raw and almost not supported by the manufacturer. Even on simple things, where it seems that nothing portends trouble, something may go wrong. If you need to use a device with Internet access via a mobile network and you are not sure that you can cope with Orange Pi, then it is better to pay extra and take something more reliable and debugged. Save time and nerves.

Also popular now: