gounthar

I think this is the reason for the cap. This is the same in all kernels from 4.19.84 up to 5.5.0-rc2
 
 
Edit: Interesting. On 4.19.35 it is still capped, though more information in dmesg
[ 5.745212] cpu cpu0: Linked as a consumer to regulator.5 [ 5.745277] cpu cpu0: Dropping the link to regulator.5 [ 5.745464] cpu cpu0: Linked as a consumer to regulator.5 [ 5.746315] core: _opp_supported_by_regulators: OPP minuV: 1320000 maxuV: 1320000, not supported by regulator [ 5.746328] cpu cpu0: _opp_add: OPP not supported by regulators (1056000000) [ 5.746436] core: _opp_supported_by_regulators: OPP minuV: 1320000 maxuV: 1320000, not supported by regulator [ 5.746443] cpu cpu0: _opp_add: OPP not supported by regulators (1104000000) [ 5.746569] core: _opp_supported_by_regulators: OPP minuV: 1320000 maxuV: 1320000, not supported by regulator [ 5.746579] cpu cpu0: _opp_add: OPP not supported by regulators (1152000000) [ 5.746669] core: _opp_supported_by_regulators: OPP minuV: 1320000 maxuV: 1320000, not supported by regulator [ 5.746676] cpu cpu0: _opp_add: OPP not supported by regulators (1200000000) [ 5.746783] core: _opp_supported_by_regulators: OPP minuV: 1340000 maxuV: 1340000, not supported by regulator [ 5.746790] cpu cpu0: _opp_add: OPP not supported by regulators (1224000000) [ 5.746926] core: _opp_supported_by_regulators: OPP minuV: 1340000 maxuV: 1340000, not supported by regulator [ 5.746935] cpu cpu0: _opp_add: OPP not supported by regulators (1248000000) [ 5.747030] core: _opp_supported_by_regulators: OPP minuV: 1340000 maxuV: 1340000, not supported by regulator [ 5.747038] cpu cpu0: _opp_add: OPP not supported by regulators (1296000000) [ 5.747155] core: _opp_supported_by_regulators: OPP minuV: 1400000 maxuV: 1400000, not supported by regulator [ 5.747163] cpu cpu0: _opp_add: OPP not supported by regulators (1344000000) [ 5.747290] core: _opp_supported_by_regulators: OPP minuV: 1400000 maxuV: 1400000, not supported by regulator [ 5.747299] cpu cpu0: _opp_add: OPP not supported by regulators (1368000000)  

You need some NeoPixel library ...
Here are some info extracted from https://gist.github.com/probonopd/97f6826cc5aa3c0c0950682b0bc266bc
WS2812B Neopixels driven by Python Connect the data line of the WS2812B Neopixels to pin SPI1_MOSI/PA15. In /boot/armbianEnv.txt we need: overlays=spi-spidev param_spidev_spi_bus=1 param_spidev_max_freq=100000000 We can successfully compile the needed Python libraries on the device itself: git clone https://github.com/doceme/py-spidev.git cd py-spidev make -j4 make install cd .. git clone https://github.com/joosteto/ws2812-spi.git find ws2812-spi/ -type f -name '*.py' -exec sed -i -e 's|spi.open(0,0)|spi.open(1,0)|g' {} \; find ws2812-spi/ -type f -name '*.py' -exec sed -i -e 's|tx=\[\]|tx=\[0x00\]|g' {} \; Make sure to use spi.open(1,0); we need to use SPI bus 1 since the internal SPI Flash is connected to SPI bus 0. # Make 16 LEDs red ./ws2812-spi/ws2812.py -c "[[0,255,0]]" -n 16 # Make 16 LEDs white ./ws2812-spi/ws2812.py -c "[[255,255,255]]" -n 16 # Switch 16 LEDs off ./ws2812-spi/ws2812.py -c "[[0,0,0]]" -n 16  

In the new year, I plan to focus on improving and developing Armbian-TV  (Armbian-TV is a version that is based on the official Armbian, aimed at improved support for media capabilities and ease of use by ordinary users) support for the platforms Rockchip and Allwinner  (perhaps a few more platforms will be added that are not yet in use). To do this, I have already ordered several popular models based on rk3399 (NanoPC T4, RockPi 4, Renegade-Elite), in a complete set with obligatory Support of nvme carriers (I consider this support essentially important, for transition of TV boxes and SBS to the category of mini-PC, as highly effective and improved replacement of the usual PC). I'm plan to buy several more models on Allwinner (I'm still evaluating the capabilities of the selected models). 
I had plans to buy some more models based on rk3399 from other manufacturers, but there were problems with delivery and / or payment for my country.
 
If anyone has any suggestions for models that I should consider, I'm willing to listen to reasonable descriptions of the models.

The offical place to look is on linux-sunxi site :
http://linux-sunxi.org/Orange_Pi_Zero#Expansion_Port
 
Schematic is here :
https://linux-sunxi.org/File:Orange-Pi-Zero-Schanetics-v1_11.pdf
 
So 2 I2C buses are available on the header, the third one is normally for CSI port, but OPiZero doesn't have such port ...

for those interested in a board bring up
 
the kernel DT can be found here (it's the commit bringing the board up, so rk3399-orangepi.dts is the most important here):
https://github.com/orangepi-xunlong/OrangePiRK3399_kernel/commit/ca6af5e3a951938bcd2516ed410e1a3173d640d2#diff-a6cab00e04d1f9f954107a5555ea160a
 
this is (likely) the used defconfig for u-boot:
https://github.com/orangepi-xunlong/OrangePiRK3399_uboot/blob/6f4a1947dd2e648c36d53dd1410679865c6b257b/configs/rk3399_defconfig
 
this might also be of interest for the first stage loaders:
https://github.com/orangepi-xunlong/OrangePiRK3399_scripts/blob/a62950cafa093437f55eb0ed5a846963edbf006f/lib/compilation.sh#L40-L45
 
it seems xunlong did quite some cleaning of their sources to build proper images.

only a man's year work, full time, for one (1) mobile. That's it       So, if you have some time start programming.
 

And the final result. This will encode an OpenCV numpy format image using hardware encoding. https://github.com/kkroening/ffmpeg-python/issues/301

Hi there,
 
I was wondering if there is a GPIO generic Python library somewhere for Armbian?
I think I remember that the pins are not always announced the same way on Armbian and on OrangePi distros.
I have seen this effort by @chwe, but is there anything else?
 
Thanks.

Within armbian you find following User-Supported options for GPIO and more:
ArmbianIO (sysFS) or
UserSpaceIO (libgpiod),
pyGPIO accesses 'pins' directly through /dev/mem

 ArmbianIO API - in C
https://forum.armbian.com/topic/5655-armbianio-api-proposal/
 
 User Space IO - is Python 3 and Java 8 bindings for user space GPIO, SPI, I2C, PWM and Serial interfaces
https://forum.armbian.com/topic/6523-user-space-io-is-python-3-and-java-8-bindings-for-user-space-gpio-spi-i2c-pwm-and-serial-interfaces/
 
 pyGPIO - A 'more general' python GPIO library based on pyA20
https://forum.armbian.com/topic/5662-pygpio-a-more-general-python-gpio-library/
 
 

Yes. Sometimes we implement such features even before ... 5.5 will probably landed to Armbian DEV kernel in 1/2020 while switching on stable will happen later. In case once wants to have this in the next LTS kernel (5.4.y) it has to be ported.

You're right, now I remembered there are some arm64 SoC's that don't have crypto extensions because the manufacturer didn't pay the license. For example, Amlogic S905 (though S905X has the extensions). So we can also discard Odroid C2 and Nanopi K2.

I ended up using ffmpeg-python since I know ffmpeg hardware encoding/decoding work. Unfortunately OpenCV doesn't allow a lot of flexibility on the video back end (VideoWriter). I'll end up using a ffmpeg adaptor for my security system since ffmpeg-python allows me to set vcodec and convert numpy arrays. To hardware encode h264 use:
#!/usr/bin/env python import ffmpeg (     ffmpeg     .input('test.avi')     .output('out.mp4', vcodec='h264_v4l2m2m', pix_fmt='nv21', **{'b:v': 2000000})     .run() ) Output #0, mp4, to 'out.mp4': Metadata: encoder : Lavf57.83.100 Stream #0:0: Video: h264 (h264_v4l2m2m) (avc1 / 0x31637661), nv21, 1280x720, q=2-31, 2000 kb/s, 7 fps, 14336 tbn, 7 tbc Metadata: encoder : Lavc57.107.100 h264_v4l2m2m  

Looong boot delay is (currently) normal on those board. If this is the problem?

Using ffmpeg -i motion-19-05-10.avi -an -vcodec h264_v4l2m2m -b:v 2M -pix_fmt nv21 test.mp4 I get the results I expected. Hardware encoding works fine. The key is to look for Stream #0:0 -> #0:0 (mpeg4 (mpeg4_v4l2m2m) -> h264 (h264_v4l2m2m)). The issue with the CPU nice time was caused by OpevCV using the software H264 encorder/decoder. I need to look for a way for OpenCV to use the hardware encoder for video encoding.
 
Basically h264_v4l2m2m is working as expected in HK's image, so it should work the same way in Armbian.

this is a pure  Server    

I just bought six, now I have to figure out what to do with them.

I don't know where to write it, but if there is someone looking for MC1 at discount price, there is a big sale going on.
I took 5 of them to build a h.264 encoding farm.

So far what I'm seeing is dt slop (on all boards using this chip)
1) lack of a connector node, which, when added, brings along
lack of port nodes for the connector IRQ errors (related how?  no idea) 2) lack of "op-sink-milliwatt" property
 
Once op-sink-milliwatt is added it will boot, which leads me to believe the chip is receiving commands from the driver, however probe fails with "failed to register tcpm error -22"  I haven't gotten past that, so 5V only, no mode switching.  And I am not immediately inclined to write a driver for the dc-dc converter.  ;-)
 
My current device tree entry:
&i2c7 { i2c-scl-rising-time-ns = <600>; i2c-scl-falling-time-ns = <20>; status = "okay"; fusb0: usb-typec@22 { compatible = "fcs,fusb302"; reg = <0x22>; interrupt-parent = <&gpio1>; interrupts = <2 IRQ_TYPE_LEVEL_LOW>; pinctrl-names = "default"; pinctrl-0 = <&fusb0_int>; vbus-supply = <&vcc_vbus_typec0>; usbc_con2: connector { compatible = "usb-c-connector"; label = "USB-C-0"; power-role = "dual"; sink-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM) PDO_VAR(5000, 15000, 3000) PDO_PPS_APDO(5000, 15000, 3000)>; op-sink-microwatt = <25000000>; ports { #address-cells = <1>; #size-cells = <0>; port@0 { reg = <0>; usb_con_hs0: endpoint { remote-endpoint = <&u2phy0_otg>; }; }; port@1 { reg = <1>; usb_con_ss0: endpoint { remote-endpoint = <&tcphy0_usb3>; }; }; port@2 { reg = <2>; usb_con_sbu0: endpoint { remote-endpoint = <&tcphy0_dp>; }; }; }; }; }; };  
[edit]  I want to be clear all the port definitions could be nonsense, the documentation is a bit thin on all sides of this.  One thing I'd like to consider is the interrupt type, even though the fusb302 specified it's interrupt pin is active low...
 
@Neil Armstrong, in case you have some insight into this.

Wow, the discount is huge. Though, since shipping and toll fees will be much more than the board itself, you need to order several units to make it worth.
 
Good choice!

Trying HK's image now with same configuration. Using Linux video 4.14.157-171 #1 SMP PREEMPT Wed Dec 4 08:21:54 -03 2019 armv7l armv7l armv7l GNU/Linux. I'll circle back once I test this out to get past my current need. Looks like hardware encoding is embedded already as well.
 

Just a follow up while trying to run 3 cameras on the UX4 like I was doing with HK's Ubuntu release. Armbian always is showing a large amount of nice time. I'm not sure if this is the hardware encoder, but I'm not seeing this with HK's release. I'm also having issues where the XU4 just dies and shuts down. I might dig around in the logs, but there's definitely something up. I'll switch back to HK release and try the same configuration and see what happens.
 
Armbian release:

 
HK release:

Armbianmonitor: http://ix.io/24iC My end game is to use hardware h264 encoding for my security camera streams (using OpenCV, etc) . The first step is testing ffmpeg. It appears that all the necessary pieces are already present in the release I'm using. If I use:
 
ffmpeg -i centaur_2.mpg -acodec aac -vcodec h264 -b:v 2M -pix_fmt nv21 test.mp4
 
CPU stays below 12% and I get 44 FPS. Seems like hardware encoding is working here.
 
If I use:
 
ffmpeg -i centaur_2.mpg -acodec aac -vcodec h264_v4l2m2m -b:v 2M -pix_fmt nv21 test.mp4
 
About the same performance, but the file is 10x larger!
 
If I use:
 
ffmpeg -i centaur_2.mpg -acodec aac -vcodec libx264 -b:v 2M -pix_fmt nv21 test.mp4
 
About the same as h264. So it looks to me like h264_v4l2m2m is used by h264 and libx264 codecs?
 
Linux 4.14.150-odroidxu4 #1 SMP PREEMPT Mon Oct 28 07:56:57 CET 2019 armv7l armv7l armv7l GNU/Linux BOARD=odroidxu4 BOARD_NAME="Odroid XU4" BOARDFAMILY=odroidxu4 BUILD_REPOSITORY_URL=https://github.com/armbian/build BUILD_REPOSITORY_COMMIT=1221d592 VERSION=5.95 LINUXFAMILY=odroidxu4 BRANCH=default ARCH=arm IMAGE_TYPE=stable BOARD_TYPE=conf INITRD_ARCH=arm KERNEL_IMAGE_TYPE=zImage ffmpeg -encoders | grep 264 V..... libx264 libx264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (codec h264) V..... libx264rgb libx264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 RGB (codec h264) V..... h264_omx OpenMAX IL H.264 video encoder (codec h264) V..... h264_v4l2m2m V4L2 mem2mem H.264 encoder wrapper (codec h264) V..... h264_vaapi H.264/AVC (VAAPI) (codec h264)  

There is special driver work done in their kernel to cover an unsupported I2C buck/boost converter that provides the 12V rail on this board, and for reasons I'm digging into, the fusb302 driver is a complete mess after they moved it out of staging, it has a lot of odd behaviors and a completely new set of requirements for the device tree.  I temporarily ran it back to the staging driver for our mainline expert builds (limited improvement), but am working on the proper driver.

You could do that as well, but I guess it is even more tricky than by using test point. I wonder why they didn't simply install a switch? Or a jumper.

Well... the troubles are not with the power units per se but with the combination of issues in mainline kernel for this board:
lack of support for MP8859 buck-boost converter which means it always provides 5V instead of switching to 12V possible misconfiguration of FUSB302B PD chip driver used in roc-rk3399-pc If I understand the patch correctly, Markus made some modifications to the power curve of fusb302 PD chip to switch usb-c voltage to 15V when more power is needed.
This should workaround power issues when powering from usb-c with pd compliant power units.