• Content count

  • Joined

  • Last visited

About jock

  • Rank
    Advanced Member

Recent Profile Visitors

208 profile views
  1. ARMBIAN for Amlogic S905 and S905X

    There is no pci bus in these SoCs, you should use lsmod to see if there is any module related to wifi and iwconfig to show the network interfaces which support wifi
  2. The are a couple of updates to the original article page; the 2nd update in particular says that the rk3288 won't be phased out (source: rockchip itself)
  3. I compiled the Mali kernel driver for latest Armbian 5.34 (kernel 4.13.14) nightly for OrangePi PC; compilation goes fine. When I install the mali.ko module I get: mali: loading out-of-tree module taints kernel. [ 8.696542] mali-utgard: assigned reserved memory node linux,cma [ 8.697136] Allwinner sunXi mali glue initialized [ 8.697333] mali-utgard mali-utgard.0: dev_pm_opp_get_opp_count: OPP table not found (-19) [ 8.697357] mali-utgard: probe of mali-utgard.0 failed with error -14 [ 8.697419] Mali: [ 8.697422] Mali device driver loaded and /dev/mali filesystem object is not exposed This is unexpected: using the old armbian release (usinge the "next" kernel) I was able compile the mali kernel driver, patching the device tree assemblies to add HDMI support and compiling the kernel manually, and everything worked. I wrote some EGL code to initialize the binary userspace blob and it was working, but now obviously it isn't :/ edit: ok I got the issue sorted, practically the guy who maintains the github repository with sunxi-mali binary driver is updating the patches. I guess he is keeping them up to date with mainline kernel (4.15 at the moment), but actually breaking compatibility with armbian next (which is 4.13.16). I managed to compile, install and test successfully the driver using an old copy.
  4. I know, but the patch failed to find the hunks in sun8i-h3.dtsi. After spending some time digging into dts files, I found that the patch could fit in sunxi-h3-h5.dtsi, so manually changed the patch, run the compilation script and the patch was correctly applied. All of this is with kernel 4.13. Maybe 4.14 has been changed or will be changed: that could be the reason why the patch is currently disabled in the armbian source code. As far as mine is just an experiment, it's enough for me. BTW the mali kernel driver loads fine, that's the userland part which is missing something I guess.
  5. I'm back. Finally I managed to compile the sunxi-next kernel coming with armbian (4.13.y). I had to remove the .disable suffix and patch the patch (no pun) Zador pointed above because the DTS section to be edited is in file sunxi-h3-h5.dtsi and not in sun8i-h3.dtsi. Once I did that, compilation went fine, installed the proper .deb packages on my orange pi pc, rebooted and I got kernel 4.13.y working. Then I compiled the mali kernel module on the OPi using the instructions from Free Electrons having care to export the shell variables this way: export CROSS_COMPILE=arm-linux-gnueabihf- export KDIR=/lib/modules/4.13.y/build The build process produced the mali.ko driver and put it into /lib/modules/4.13.y/extra directory. I moved the module inside the kernel directory, run depmod finally run modprobe mali and at last I got the module loaded by the kernel. Nonetheless I could not run any of the benchmarks/utilities to query the EGL/OpenGL capabilities: all of them told me they could not find any suitable display :/ I guess you all already did this, but as long as I couldn't find suitable instructions nowhere, maybe this rough tutorial could be useful for someone else.
  6. Clean mainline, actually the latest nightly from the armbian repository for H3 with kernel 4.11.12. With this kernel I'm already able to drive a HDMI panel and the framebuffer console works. I'll give a shot then for latest sunxi-next kernel, yet the device tree should be manually fixed to load the kernel driver, I guess?
  7. Is the HDMI code required for the fbdev flavour? Just for curiosity I compiled the kernel driver successfully on an OPi-PC, installed it and also installed the userspace drivers; can't find a valid Device Tree overlay to let the kernel load the driver successfully. I tried a miserable attempt to use the device tree portion from another a33-based device, manipulated it a bit, but still get a sad "Couldn't retrieve our reset handle" error from the driver
  8. ARMBIAN for Amlogic S905 and S905X

    You didn't read accurately my post. The dtb file I extracted from my device is exactly the same as the one provided by balbes150 with name Nexbox-A95x in his ubuntu mate package. Actually both don't work, but I guess balbes provides a valid dtb file and the problem is somewhere else. The problem about hdmi audio is that the driver hangs somewhere, as much as like IRQs are not honored anymore and the DMA is supplying always the same buffer, so when the hdmi audio hangs, it just repeats infinitely the last buffer. I thought there may be an issue with the dtb file as long as I think the problem sits between the software to hardware interface. Most probably it is an issue with the driver though.
  9. ARMBIAN for Amlogic S905 and S905X

    I extracted the device tree binary from my Nexbox MXQ-Pro S905 (not X) device, which has 1GB of RAM and 8GB of eMMC and found that the file is exactly the same as the Nexbox-A95X shipped along with the images prepared by balbes150. In my setup I used the "generic" gxbb_p201.dtb file: the device booted and it worked well enough, but the wifi (8192es) module didn't load automatically and also sometimes the audio over hdmi get stuck and I have to reboot. I thought that nothing fit better than the dtb file from my own device, so I extracted it from the original android image which is still on the eMMC of the device. It ends up being exactly the same dtb as the Nexbox-A95x. When I try to use the dtb extracted from my own device, the device doesn't boot anymore: it stays stuck at boot with the Nexbox logo after reading some data from the USB hard drive. I supposed that the original dtb file would fit perfectly in the process. Can be a problem with a missing kernel module or what else?
  10. OpenGL for Orange PI PC

    mesa-utils package can be useful to start debugging with. The main problem is that drivers for the GPU are proprietary and there is no OpenGL driver, but just an OpenGL ES driver. OpenGL ES is a bit different than regular OpenGL, and provided with armbian there is an OpenGL shim which converts calls from OpenGL ES to OpenGL. As a wrapper, it is quite from being perfect and the result is that OpenGL applications are misbehaving.
  11. OPi GPU freq reverted to 252 Mhz?

    Just guessed about missed patches, as long as the changelog says that the clock has been raised in the past. Btw, Quake is working quite fine with opengl shim, just some minor issue with mipmaps I guess, and xfce seems to work with the compositor activated with no artifacts, so I was wondering if page scrolling and rendering could be pushed further a bit. I'm using a samsung EVO card which is sufficient for now, but I moved the home directory on an external hard disk using the USB. Just poking around with the hardware, nothing serious actually.
  12. I got an OrangePi Pc, and I see that Mali GPU frequency has been rolled back to 252 Mhz, or at least the kernel is saying so in dmesg. I took a look into the changelog, the frequency has been increased to nominal 600 Mhz in armbian v5.15, but now I installed a fresh 5.20, upgraded to latest packages and I see that kernel initializes the GPU at 252 Mhz. I found no traces of this rollback in the changelog. As I'm currently testing the SBC as a desktop replacement, I'm guessing if the increased gpu frequency could be of any benefit to the interface snappiness.
  13. Truly,abandon the idea to work on orangepi patchy software, armbian is WAAAAY better and much more carefully crafted that the crap you can download from the orangepi site or from the forums. Armbian is a real distro, others aren't
  14. Pwm on allwinner h3

    There is a python library to access the GPIO based on WiringPI/WiringOP around, but I didn't use the PWM feature. I successfully used this WiringOP fork (but this is only C) with software PWM: You may give a try to wrap using ctypes python module to gain access to the C library from python. I didn't try the hardware PWM, Orange PI H3 devices have just one hardware PWM exposed via GPIO, and it has to be activated via script.bin
  15. orange pi from start

    None of those voltages are fine with the boards. The board may run, but USB devices and HDMI devices won't work as long as they receive the proper voltage directly from the source. Also cheap power supplies with selectable output voltage usually have very little output amperage (200mA if you're lucky. These boards require 2000mA to work reliably with some USB devices attached)