nightseas

Was in dire need of Armbian on my new toy, the HBP with a iMX8Q CPU ;-) The board features dual WWAN (PCIe + M.2) sockets for highspeed 3G/4G/5G modems with a SIM socket. The Debian build from SolidRun did not have any modem drivers enabled in the kernel so there was headache. Wipped up this WIP configuration and it builds and runs with:
```
$ ./compile.sh  BOARD=hummingboardpulse-imx8q BRANCH=legacy RELEASE=buster BUILD_MINIMAL=no BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no
```
NOTE: It uses the HDMI and LPDDR4 binary blobs from NXP. You will get a prompt during build to accept the license.

The board is default configured to boot from SD using the Boot Select DIPs
 
_ _ ____ ____ _ _ __ ____ _____ | | | | __ ) | _ \ _ _| |___ ___ (_) \/ \ \/ ( _ ) | |_| | _ \ | |_) | | | | / __|/ _ \ | | |\/| |\ // _ \ | _ | |_) | | __/| |_| | \__ \ __/ | | | | |/ \ (_) | |_| |_|____/ |_| \__,_|_|___/\___| |_|_| |_/_/\_\___/ Welcome to Armbian buster with Linux 4.19.72-imx8-sr-imx8 System load: 0.41 1.82 1.38 Up time: 29 min Memory usage: 4 % of 2997MB IP: 192.168.10.148 CPU temp: 47°C Usage of /: 18% of 7.1G [ General system configuration (beta): armbian-config ] http://ix.io/27FC
 

What about an universal lib which is  totally decoupled from HW platform, and with functions (SPI, I2C, UART, GPIO) separated?
  - It should be not only able to run on Allwinner SoCs, but also other
  - No kernel driver hacking or physical register access, only based on Linux userspace interface
 
I did port the wiringPi last year. Both C and Python (Cython based) are supported.
The only customizing needed is to fill in the GPIO number map (standard Linux GPIO number) and device number (SPI1, ttyS2 etc.)
 
https://github.com/nightseas/nightWiring
https://github.com/nightseas/python-nightWiring/

Attached is the full OpenCV 3.3.0 + OpenCL perf test report except video test part, which failed probably because of corrupted GLES.
Just for your reference.
x86_opencv_perf_reports_20170817.html

I tried to build libmali deb pack for RK3399 but failed. There's no instruction or guide, so I may need to ask Rockchip for help again.
Then I manually linked the lib in /usr/lib and destroyed the the desktop GUI. After some experiment the desktop was back but still could not test gles2 as you suggested.
 
The good news is, OpenCL works well. I'll do some OpenCV + OpenCL perf test and put the result here.

Thanks a lot for the hints.
 
I chose the Marvell 64-bit patch instead of RK3288 to replace compressed zImage with the binary Image.
https://github.com/armbian/build/blob/master/patch/kernel/mvebu64-default/packaging-4.x-with-postinstall-scripts.patch
 
Now Armbian 5.32 (Ubuntu 16.04 Desktop) is successfully running on my board.
 
I forked the repo and make my own commit to add the support for RK3399. You can find the changes to original repo here:
https://github.com/nightseas/armbian-build/
 
Know issues:
 1. No GPU or VPU pack installed for now;
 2. There's a binary tool from RK used to convert u-boot, which can't be packed into the u-boot deb because it's for x86_64. Means you can't update bootloader in a running Armbian.
 
Next step will be GPU and VPU userspace lib porting. 
 
Screenshot of desktop, with CPU, temperature, and frequency:

 

Thanks a lot for the hints.
 
I chose the Marvell 64-bit patch instead of RK3288 to replace compressed zImage with the binary Image.
https://github.com/armbian/build/blob/master/patch/kernel/mvebu64-default/packaging-4.x-with-postinstall-scripts.patch
 
Now Armbian 5.32 (Ubuntu 16.04 Desktop) is successfully running on my board.
 
I forked the repo and make my own commit to add the support for RK3399. You can find the changes to original repo here:
https://github.com/nightseas/armbian-build/
 
Know issues:
 1. No GPU or VPU pack installed for now;
 2. There's a binary tool from RK used to convert u-boot, which can't be packed into the u-boot deb because it's for x86_64. Means you can't update bootloader in a running Armbian.
 
Next step will be GPU and VPU userspace lib porting. 
 
Screenshot of desktop, with CPU, temperature, and frequency:

 

I'm starting to add RK3399 to Armbian, in my spare time.
 
Here's the board I got, RK3399 official EVB, which spent me 500CNY (~63EURO) on Taobao, quite cheap comparing to Firefly.
https://item.taobao.com/item.htm?spm=a1z09.2.0.0.1f30a53flpk7IA&id=554454257549&_u=31t0eea9a1c
 
Spec:
 - Rockchip RK3399 (2xA72 + 4xA53, Mali T860 MP4)
 - 4GBytes Dual channel LPDDR3 (64-bit in total)
 - 8GBytes eMMC, Micro SD Slot
 - USB 3.0 Type-A, USB Type-C (DP over Type-C), USB2.0, HDMI
 - 1G Ethernet
 - Raspberry Pi compatible 2x20 pin header
 - Other interfaces: PCIe 2.0 x4, MIPI CSI & DSI, eDP, LVDS....
 
   
 
You can download Cadence OrCAD format schematic and Allegro format PCB files for free. It's open sourced and you'll also find BOM, gerber files ready for production.
http://opensource.rock-chips.com/wiki_Excavator_sapphire_board
 
I was able to build Linux 4.4 + Debian 9 with build scripts from Rockchip. And it looks like the OpenGLES and OpenCL are ready? (not fully tested). VPU still has some problem.
 
Will continue to update in this post...

Even though it's off-topic, I'm using dd with verifying for unattended writing images to SD cards on a build host.
 
Not a mistake, but putting the u-boot on a SPI flash can be used to boot images from USB if for some reason you want to store rootfs on USB drive instead of SD/eMMC.

And it has 4GB dual-channel LPDDR3 by default, a small cortex-M4 MCU for board management or real time processing.
The real purpose of this board is not for SBC but micro blade server cluster.
that's why all connectors are placed to one side, as front panel in the future.
I was also planning a real open cluster project to DIY blade system with managed switch blade ( the SOM on clearfog could be a good start ), backplane power delivery and cooling control.
Just need more TIME. Ouch...

And it has 4GB dual-channel LPDDR3 by default, a small cortex-M4 MCU for board management or real time processing.
The real purpose of this board is not for SBC but micro blade server cluster.
that's why all connectors are placed to one side, as front panel in the future.
I was also planning a real open cluster project to DIY blade system with managed switch blade ( the SOM on clearfog could be a good start ), backplane power delivery and cooling control.
Just need more TIME. Ouch...

[ This thread started more or less here :  And what do you think about porting to a cheap Android TVBox ]
 
If anyone's interested we can discuss Armbian or linux for those rk3288 devices here.
 
I'll start with mine (Q8 without front panel) which is the XT-Q8L-V10 from enybox (Chiptrip Q8 on gearbest or that other EKB328 on Aliexpress with front panel).
 
I have a feeling that those boards are discontinued and being put on sale as end of stock.
There are various other boxes with rk3288 which prices are pretty high (>80e) and were probably seen at some point as high end boxes.
 
Other threads for that board can be found here : 
- freaktab.com serial header thread
- Timp74 bitbucket.org
(both pretty old sources from mid 2015)
 
the board is the following :  (front panel is optional)
 

 
 
I already own and use many arm boards, regular ones like raspberry pi, odroid, orange pi and tv boxes mainly amlogic ones from s805 to s912.
I favor amlogic for their large availability and good linux and armbian support (thx to @balbes150 ).
 
My decision of trying to get a working rk3288 linux, is only driven by the high single core performance of that soc.
Mostly in an (high speed >100Mbps) openvpn context (openssl), some figures showed it was 30-40% faster than the s905 which is already quite fast compared to other allwinner socs.
 
I'm only looking for cheap tv boxes and for any price over 50e i would turn to dev boards with good support.
 
The idea is to take advantage of the recent popularity of rk3288 dev boards, Miqi and asus tinker although other boards already existed which is not surprising considering that soc entered the market in 2014.
Rockchip seems to be very active on the linux front and rk3288 is getting mainline uboot / kernel support.
 

Hi,
 
Is there any plan fro Armbian to support Rockchip processors like RK3288 or RK3399? Any guide on how to port Armbian on them?
 
These processors have official support on GPU (both openCL and openGL ES), HW video codec (like H264 encoding and decoding with gstream), and also open-sourced Kernel 4.4.x. And most important thing is they are willing to support opensource community and fix their bugs continuously.
 
I've got a RK3288 proto board which was able to run Linux 4.4 + Debian with HW accelerated desktop and video playing, and it worked perfect. The only thing that troubled me is the Debian system that maintained by Rockchip is suck...
 
So I'm looking on the great Armbian now. I'll star to port it when I have time. But I'm here to ask if it's considerable to have Rockchip supported officially.