Larry Bank

Is there some DT overlay to enable or some software to install to use the onboard bluetooth radio of the Orange Pi Zero Plus 2?

It's at a good enough point that I have released it to my public github account. Please feel free to praise/criticize/fix/enhance it: https://github.com/bitbank2/ArmbianIO Thanks

I just got the first version ready. It should work correctly with Orange Pi Zero, OPZ+2, Orange Pi One/lite and Nano Pi Duo boards. Please let me know if you want to try it and I'll add you as a developer to my gitlab repo. Once it's in good shape, I'll share it to everyone on github.

@arox - interesting perspective, so you think that the RPF is actually having a destructive influence on Linux because of its customization/branding/selling? I feel the opposite because they've increased awareness dramatically and legitimized embedded boards running a "friendly" and universal operating system. I don't think Raspbian's customizations affect mainline Linux a whole lot, but there are nearly 10 million new Linux users because of them.

Please choose the best reason for selecting Armbian and using an ARM SBC not manufactured by the Raspberry Pi Foundation

I was chatting with @tido about ways to help the Armbian community and I came up with the idea of a common C library to access the I2C, SPI and GPIOs of all supported boards. There are of course kernel drivers to communicate with these things, but there are differences between boards that this API could help smooth out. For example, different CPUs (and boards) map the GPIO pins very differently. Projects such as WiringOP and WiringNP try to copy the Raspberry Pi library, but this is also flawed because it's based on the BCM283x GPIO numbering. What I propose is to create a set of simple functions for accessing GPIO pins using the physical pin number as a reference. On all boards, the 5V pin will be considered pin 2 and the numbering goes from there. There are also sometimes pushbuttons present on the board which are mapped to GPIO inputs. These are also covered by my API. Much of the code is already written and I will release it shortly. I'm posting this topic to get feedback and to reach out to people who might make use of this. Here is a list of the functions so far: int AIOInit(void); void AIOShutdown(void); const char * AIOGetBoardName(void); int AIOOpenI2C(int iChannel, int iAddress); int AIOOpenSPI(int iChannel, int iSpeed); int AIOCloseI2C(int iHandle); int AIOCloseSPI(int iHandle); int AIOReadI2C(int iHandle, int iRegister, unsigned char *buf, int iCount); int AIOWriteI2C(int iHandle, int iRegister, unsigned char *buf, int iCount); int AIOReadSPI(int iHandle, unsigned char *buf, int iCount); int AIOWriteSPI(int iHandle, unsigned char *buf, int iCount); int AIOReadWriteSPI(int iHandle, unsigned char *inbuf, unsigned char *outbuf, int iCount); int AIOReadButton(void); int AIOAddPin(int iPin, int iDirection); int AIORemovePin(int iPin); int AIOReadPin(int iPin); int AIOWritePin(int iPin, int iValue);

These SoCs are designed for set top boxes, not really for our little NAS/Gaming/Projects. The improvements of the H6 over the H5 may not have much effect depending on what OrangePi does with the board designs. The improvements possible for OPi boards are: 1) Faster RAM 2) USB3 3) Faster/more capable video encoder/decoder 4) Faster GPU Improvements that would have been nice to have: 1) Bigger L2 cache (still 512KB) 2) Replace A53 cores with A73 or use big/little design 3) Going to a 14nm process (H5=40nm, H6=28nm) The die shrink should reduce the power usage, but we'll have to see if that makes a measurable difference in the heat/power of the boards.

It's hard to tell from the photo, but it looks like it's using a LPDDR4 RAM module. If that's true, then besides the improved 4k/6k video codec, it might actually run code faster on the A53 cores due to faster memory bandwidth.

Here's my game emulators running on an Orange Pi Zero (AllWinner H2 SoC). I use the SPI_LCD library to talk directly to the LCD for better framerates than can be achieved with fbtft/fbcp: Below is a photo of a NanoPi Duo (AllWinner H2 SoC) using my oled_96 library when running my new "bb-hole" program. This is a replacement for pi-hole which acts as a DNS filter to block unwanted ads/sites. I will be releasing the source code to this shortly.

I have a running obsession with sensors/motors/SBCs and have been creating a collection of C libraries as I learn/conquer each new device. I recently added a few that might interest some of the forum residents here. They include a C library to talk to the RPI Sense Hat, ST Micro VL53L0X time of flight distance sensor, and CCS811 air quality sensor. You can find them all here: https://github.com/bitbank2 If anyone has a sensor/add-on that they would like to program in C from their Orange Pi and there isn't any code available, let me know and maybe I can add it to my collection.

Did you get them from AliExpress or another vendor? When I try to buy them from the BPi link to AliExpress it shows $15 + free shipping, but when clicking on the product link, the shipping jumps to $6.53.

Just appeared for sale on Aliexpress. Shipping is $6.53 to the USA ($21.53 total). https://www.aliexpress.com/store/product/Allwinner-H2-Open-source-hardware-platform-BPI-M2-zero-all-ineter-face-same-as-Raspberry-pi/302756_32839074880.html I have enough ARM boards to keep me busy, but it might make an interesting substitute if your project was designed for the board size of the RPi0.

It's a bit bigger than the GPD, but my favorite ARM notebook so far is the Asus Chromebook Flip. It's a RockChip RK3288 w/4GB RAM and 16 or 32GB fast eMMC. I run Debian Linux on it (with Crouton) and it's a great little machine. It gets about 10 hours of working time and runs about 5x faster than a Raspberry Pi 3B.

I've been hitting similar issues trying new builds on various boards. I find it much less stressful to just use a USB wifi dongle when doing these kinds of tests. I'm running Armbian with a 4.13 kernel built for the Orange Pi Zero on my NanoPi Duo and with a USB wifi dongle, it works fine: The Linux build provided by FriendlyElec has a super slow SPI driver, so I went in search of a way to see if it was a hardware or software bug. Running the OPZ build of Armbian on the Duo shows that it's purely a software bug.

I responded to your github issue

You're welcome to email me (bitbank@pobox.com). As far as I know, the ili9481 behaves the same as the HX8357 (which I do support in that code). My code was designed for speeding up game emulation and allows you to draw image tiles up to 4K bytes (typical SPI buffer limit). The LCD in your link only talks about its 8-bit parallel interface. My code is strictly for working with SPI (serial) connected displays.

Do you need to have a virtual framebuffer sent to the LCD to accomplish your task, or do you just need to draw text/graphics on the LCD under your control? The reason I ask is that I wrote a simple and fast set of functions to talk directly to SPI connected LCD displays. It doesn't create a virtual frame buffer, but it does offer simple functions to draw text and graphics (https://github.com/bitbank2/SPI_LCD). For some projects, it will be easier to work with (and faster) than sending 'late copies' of a virtual framebuffer to the LCD.

I tried activating USB with DT overlays - still didn't work. When I run the OP PC2 build on the OPZ+2H5, USB and video works, so why the difference between the 2 builds? How do I activate the video driver?

Has anyone tried the latest nightly for the OPZ+2 H5? It works fine when connected via TTY, but HDMI turns off right after the "loading kernel" message. It also doesn't enable any of the USB ports, but Wifi works fine The OrangePi PC 2 version runs better on the OPZ+2 H5. It has video out, usb works, but the wifi is not working.

All composite video out on all ARM boards I've tested always has cut off edges. Maybe it's my monitor, but I hear this from others, so I assume it's a universal problem.

Thanks for the info, but I don't know how to apply patches nor where to get the right one(s).

That would be disappointing if video out is permanently disabled on mainline kernels from now on. I was hoping to use it on the OPZ and NanoPi Duo. The older kernels have a slower/broken SPI driver and overheat.

I've been trying for the last 2 days to get composite video out on the mainline (4.11 and 4.13) kernels on the Orange Pi Zero. I've followed the old guide and the new and nothing works. On the 3.4 kernel, video out worked fine. Can someone please point me to a working set of instructions for accomplishing this?

I just set up my NanoPi Duo and I was hoping to get SPI performance similar to the Orange Pi Zero. I don't have an oscilloscope, but it looks like I'm getting a max frequency of around 3Mhz (based on ili9341 LCD refresh rate). Anyone else seeing sluggish SPI performance? I mapped the GPIO numbers for the pins too. I'll update my SPI_LCD project shortly with the new pin->gpio table.