MX_Master

Xorg config is standard, by armbian - /etc/X11/xorg.conf.d/01-armbian-defaults.conf
Section "Monitor"         Identifier              "Monitor0"         Option                  "DPMS" "false" EndSection Section "ServerFlags"         Option                  "BlankTime" "0"         Option                  "StandbyTime" "0"         Option                  "SuspendTime" "0"         Option                  "OffTime" "0" EndSection Section "Device"     Identifier  "Default Device"     Driver      "modesetting"     Option      "AccelMethod"    "glamor" EndSection May be this "Device" section is a source of my problem.

Moved to Common issues / peer to peer technical support

If I'm not mistaken, yes. You can always make a SPL hack, which do stuff with otherwise protected resources.

Thanks to Werner, I have a stable desktop on my Orange Pi 3 running the Armbian_20.05.4_Orangepi3_focal_current_5.4.45_desktop.img.xz (stable release).  MOD can put this elsewhere if it belongs in tutorials and not bugs.
 
Here is how to step through his fix for anyone new to linux (like myself).
1. After flashing and setting root and user, the user will be logged into the graphical Xfce desktop environment (DE) and will freeze soon.
2. On the next reboot you can try to use one of the separate terminals instead of the DE.  This is done by holding CTRL+ALT and selecting F1-F6
3. Quickly log into root account and type the following "sudo systemctl set-default multi-user"  This will disable the DE next time you load.
4. The system may freeze as the DE is being loaded, so its best to reset and log into the bash shell with root again.
5. We have to setup a shell script that runs every boot, as the files that Werner overwrites get replaced every time. We will edit/etc/rc.local
6. Goto "cd /etc/ " and chose your favorite editor.  I used vim, so I type "vim rc.local" to start editing.
7.  Add the lines that Werner posted earlier to the rc.local file 
cd /sys/devices/platform/soc/1800000.gpu/devfreq/1800000.gpu/ echo userspace > governor echo 756000000 > max_freq echo 756000000 > min_freq 8. Save and exit to shell.
9. last step is to enable the DE again, type "systemctl set-default graphical"
10.  Reboot and enjoy a stable desktop.
 
It took me about a day to have this working, mainly because of me not understanding the the GPU clock values were getting reset and not knowing unix commands & file structure.  It reminded me as a kid messing with the autoexec.bat on a ms-dos machine.  I am hoping to use an SDR and make this into a HD Radio Decoder (already built the NRSC-5 & GUI) , have it stream to an android head unit in my car & control via VNC.
 

We have moved the forums to a new host with higher availability.  Caches may need to be cleared.  Hopefully performance will be better as well.   Please reply here to report any forum-related issues.

Xupdate: includes updated mesa libraries for mali GPUs.
 
how to use:
add below to you source.list
 
 
gpg key can be found at:
 
 
after that, run `sudo apt update && sudo apt upgrade`
 
before reboot, please update your xorg.conf, follow below webpage:
 
 
 
 

Your truth  I forgot to `apt update` first. My bad. Thanks

@MX_Master I sent you a private message with the link to the sdcard image.
Anyway I thought that you may double check your libEGL* and LibGLES* symbolic links using ldconfig -p.
Otherwise you could create a directory /opt/mali, put in libMali.so and create there all the necessary libEGL and libGLES symbolic links to libMali.so, then run glmark2 (or other gles apps) using LD_LIBRARY_PATH=/opt/mali glmark2-es2 --fullscreen command line, so the app will first check the libraries in /opt/mali, bypassing the - messy IMHO - mesa/glvnd machinery.

Mmmh, no there's definitely something not working... I got totally different results when I tried it myself, but it was with an older kernel and an older X server. It should have worked with latest bits although. I still have the sdcard for the Orange PI PC around here, let me compress and upload it for you.
 

this xorg conf does not refer to the armsoc driver - here is a proven to be working example for an armsoc xorg.conf: https://github.com/hexdump0815/imagebuilder/blob/master/files/extra-files/etc/X11/xorg.conf.d.samples/01-armsoc.conf

maybe build your own kernel with lima disabled (i'm not sure, but i think it might conflict with the old mali driver even if the module is not loaded) ... make sure you apply those two patches:
https://github.com/hexdump0815/linux-mainline-and-mali-generic-stable-kernel/blob/master/misc.av7/sunxi-drm-gem-cma-Export-with-handle-allocator.patch
https://github.com/hexdump0815/linux-mainline-and-mali-generic-stable-kernel/blob/master/misc.av7/sunxi-drm-sun4i-Add-GEM-allocator.patch
 
here are my own notes on getting this to work, which are verified to work up until v5.4 kernels:
https://github.com/hexdump0815/linux-mainline-and-mali-generic-stable-kernel/blob/master/readme.av7-mali-sunxi
 
good luck and best wishes - hexdump

another thing to keep in mind is that your user needs access to /dev/mali - usually granted via some udev rule and the video group (usermod -a -G video username) ... example udev rule: https://github.com/hexdump0815/imagebuilder/blob/master/files/extra-files/etc/udev/rules.d/50-mali.rules
 
good luck and best wishes - hexdump

@MX_Master
 
Yes, you need to create a configuration file for X to use armsoc driver. Edit a file /etc/X11/xorg.conf.d/10-armsoc.conf and put this into:
Section "Device" Identifier "mali" Driver "armsoc" EndSection also you must be sure that libEGL* and libGLES* libraries are all pointing to libMali.so. Be also sure that the Mali library userspace library has really name libMali.so, because otherwise it won't work!

The answer is yes, it can be done, but you need a bit of knowledge about compiling kernel modules.
I made it on an Orange PI PC (Allwinner H3) to test my armsoc drivers and it worked, although Mali-400 MP2 embedded into H3 was quite slow.
 
You should be able to take everything you need (both the kernel driver and the userland EGL+OpenGL ES drivers) from https://github.com/mripard/sunxi-mali
Kernel and userland libraries should match their versions to be sure that they work correctly together: if you use r6p2 kernel driver, use r6p2 for userland too.
Instructions are easy but here are some hints:
You need the kernel headers package installed, you won't get far without this; you should be able to use apt-get to install the appropriate package for your armbian version You can compile the kernel driver on your very same board (I strongly suggest this), so you don't need to export the CROSS_COMPILE environment variable export the KDIR env variable to point to your kernel headers. Typically: export KDIR=/lib/modules/$(uname -r)/build export INSTALL_MOD_PATH env variable to point to your kernel modules:. Typically: export INSTALL_MOD_PATH=/lib/modules/$(uname -r)/kernel follow the instructions as described, but expect some patch won't work or compile fail. Just don't be scared to get your hands dirty, it is common that you may need to do some little manual adjustments (a missing kernel file here, a missing header there...) Once the driver is compiled and installed, you should be already able to modprobe it.
 
Follow the instructions to install the userland EGL and OpenGL ES libraries too.
If you are using the X server, you need the x11_dma_buf flavour and you also need to compile this armsoc driver too (maybe you can try the already compiled version I published on this post, it should work for your SoC too. Ignore the media script part which is for rockchip socs).
If you don't use X you can use the fbdev flavour, in this case add extraargs=drm_kms_helper.drm_fbdev_overalloc=200 to /boot/armbianEnv.txt as per-instructions.
 
 
 
 

I've started the work of switching SUNXI-DEV to 5.6.y, as usual, few DT duplicates and fixes ...
But I've faced also a big change related to 'file_operations' been changed to 'proc_ops' in all places over the kernel, which cause that all our EXTRAWIFI needs to be fixed.
I hope to get it done by the end of this evening ...
 

Release details

https://docs.armbian.com/Release_Changelog/
 
Upgrading your Armbian to v19.11.y
 
This upgrade is changing kernel branch names and first upgrade is not done via regular apt-upgrade process, but you have to login as root or get super user privileges with sudo su. Than do the following:
apt update apt upgrade armbian-config -> system -> Other -> select either legacy or current with v19.11.3
 
 
Choose latest version of 19.11.x and select upgrade according to this scheme:
Odroid XU4 default, next or dev -> legacy (stock 4.14.y) Allwinner default, next, dev -> legacy (4.19.y), current (5.3.y) Odroid C2 and other meson64 boards -> current (5.3.y) Odroid N2 -> legacy (4.4.y), current (5.3.y) Tinkerboard and other rockchip boards -> legacy (4.4.y), current (5.3.y) Cubox and Udoo -> imx6 current (5.3.y) Helios 4 and Clearfog -> mvebu legacy (4.14.y), current (4.19.y) Espressobin -> mvebu64 legacy (4.14.y), current (4.19.y) Those upgrades were tested manually:
 

Note: upgrade will replace your boot script. In case you made changes, you can find a backup in /usr/share/armbian
Main build system changes
Due to changes in branch names and removal of all legacy kernels < 4 your predefined automatic scripts might need updating. Temporally quick fix is to add
LIB_TAG="v19.08" to your build config file which by default is:
userpatches/config-default.conf Then run your script as you did before.
 
Thanks to all who are contributing their time to Armbian in various forms and especially developers who contributed to this release. Also thanks to the greater kernel developers community which are playing great role in this.

In case you want to participate, you are more then welcome. Step up and start making changes! In case you run into the troubles or find a bug, forum is the place for talking about while fixes you are welcome to prepare and send here.

Note: some images will be missing today and tomorrow from the download section. Missing one are being created and uploaded but this takes time ... Most of the images were manually tested for booting, upgrades as stated above, but we can't afford to make stability, functional or just boot auto tests on industrial scale. Not with our ultra tiny resources. Perhaps in the future if "you" will support that.
 
Enjoy! 

Legacy and mainline kernel.
 
https://www.armbian.com/rock-pi-4/

Playing with freshly installed/updated armbian, tried to compile "patched" realtek drivers for those weird realtek 81xx things.
Bumped error: ./scripts/recordsmcount not found
 
Go to /usr/src/linux-headers-whatever-version-4.x/scripts
then, sudo make  recordmcount
 
After this even DKMS version installed/build without any issues.
Not sure I will survive next kernel update without manual intervention with this "make", but anyway, it worked for me.

Images are building and uploading at this moment. A few more tests and repository will also be updated, so you will be able to upgrade your current build to 4.19.y

Hello,
 
enabled patch for OrangePi Zero H2+ 512 with build environment Armbian 5.41 on Ubuntu 16.04.3 LTS for build Xenial 3.4.113 with rt143.
Following results:
dev@orangepizero:~/rt-tests-1.0$ uname -a Linux orangepizero 3.4.113-rt143-sun8i #2 SMP PREEMPT RT Thu Feb 22 17:25:21 EET 2018 armv7l armv7l armv7l GNU/Linux dev@orangepizero:~/rt-tests-1.0$ sudo ./cyclictest -p 80 -t5 -n # /dev/cpu_dma_latency set to 0us policy: fifo: loadavg: 0.47 0.41 0.70 2/138 20170 T: 0 ( 2844) P:80 I:1000 C:3969645 Min: 8 Act: 62 Avg: 54 Max: 2062 T: 1 ( 2845) P:80 I:1500 C:2646431 Min: 8 Act: 90 Avg: 56 Max: 571^C T: 2 ( 2846) P:80 I:2000 C:1984823 Min: 8 Act: 52 Avg: 55 Max: 346 T: 3 ( 2847) P:80 I:2500 C:1587859 Min: 8 Act: 91 Avg: 55 Max: 341 T: 4 ( 2848) P:80 I:3000 C:1323215 Min: 8 Act: 64 Avg: 55 Max: 297 Following interrupts are reported
dev@orangepizero:~$ cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 10: 564 440 442 277 sunxi_gpio_irq_chip xradio_irq 29: 3727320 3647150 3611500 1844956 GIC arch_timer 30: 0 0 0 0 GIC arch_timer 32: 446 0 0 0 GIC uart0 38: 24 0 0 0 GIC twi0 39: 18 0 0 0 GIC twi1 43: 0 0 0 0 GIC PA 49: 1723 0 0 0 GIC PG 50: 0 0 0 0 GIC sunxi_timer0 63: 0 0 0 0 GIC Thermal 72: 0 0 0 0 GIC sunxi-rtc alarm 77: 0 0 0 0 GIC PL 81: 0 0 0 0 GIC arisc_hwmsgbox_irq 82: 0 0 0 0 GIC sunxi_dmac 90: 0 0 0 0 GIC cedar_dev 92: 63924 0 0 0 GIC sunxi-mmc 93: 126255 0 0 0 GIC sunxi-mmc 97: 0 0 0 0 GIC spi0 98: 0 0 0 0 GIC spi1 103: 353 0 0 0 GIC sunxi_usb_udc 104: 0 0 0 0 GIC ehci_hcd:usb1 105: 0 0 0 0 GIC ohci_hcd:usb5 106: 0 0 0 0 GIC ehci_hcd:usb2 107: 0 0 0 0 GIC ohci_hcd:usb6 108: 0 0 0 0 GIC ehci_hcd:usb3 109: 0 0 0 0 GIC ohci_hcd:usb7 110: 0 0 0 0 GIC ehci_hcd:usb4 111: 0 0 0 0 GIC ohci_hcd:usb8 114: 1459073 0 0 0 GIC gmac0 119: 336585 0 0 0 GIC dispaly IPI0: 0 0 0 0 CPU wakeup interrupts IPI1: 0 0 0 0 Timer broadcast interrupts IPI2: 376490 1088699 535403 326760 Rescheduling interrupts IPI3: 111 112 111 106 Function call interrupts IPI4: 2 1 3 0 Single function call interrupts IPI5: 0 0 0 0 CPU stop interrupts IPI6: 0 0 0 0 CPU backtrace IPI7: 0 0 0 0 completion interrupts Best regards!
Dani

Service monitoring and restart functionality can be made by any ARM Linux program or script.
 
If you want to be shure that Linux OS is running normally, you can use a combination of ARM Linux program and ARISC program. If linux program didn't answering to ping from ARISC program, the ARISC program can restart whole device.
 
I will use the ARISC firmware just for GPIO toggling. My ARM Linux program periodically will send to ARISC a commands to generate exact number of pulses on the specific GPIO pins, with specific frequency rate. 

AFAIK, mainline kernel runs in unsecure mode, where you can't write to secured registers like R_CPUCFG.

... and here are the openssl/7z tests: https://pastebin.com/huSB5LhC
 
@tkaiser updated results with the performance governor: https://pastebin.com/pUR5D7AA
 
You were right, it makes a big difference to the openssl results at the smaller block sizes.
 
The board has passive heatsinks only at the moment, fan is still to be added. I saw some temperatures in the high 60s during these runs, so it's possible/likely that some throttling still occurred.

@tkaiser Memory test you requested on OPi one+ board: https://pastebin.com/ubszDSUH
 
Temperature peaked at 53C during the test, so should have stayed well clear of any throttling. I added heatsinks this morning

Thanks again to the jernej.
 
Finally i got what i want. Now I can upload a firmware and run the ARISC core without any problems with armbian mainline kernel.
 
Here is a test firmware source - https://github.com/MX-Master/h3-firmware/blob/test_3/main.c (simple leds blinking)
Here is the uboot script source - https://github.com/MX-Master/h3-firmware/blob/test_3/fixup.cmd
 
If somebody wants to test it.. the firmware blob and compiled uboot script can be found here
https://github.com/MX-Master/h3-firmware/raw/test_3/h3-firmware.zip
 
Tested with Orange Pi One and Armbian mainline image.