• Content Count

  • Joined

  • Last visited

 Content Type 


Member Map





Everything posted by jock

  1. No non-sense, the OP asked for hardware acceleration and preferably mainline kernel, so the thing which scores the most this sense is H3, with all the cons I wrote in the post you quoted (plus the fact that I'm not fond of allwinner which is by far the most non-opensource company of the group). AmLogic has no committment for mainline kernel and hardware video decoding is missing in mainline ( says "No" "WiP"), so to stay stick to the original question (armbian + kodi) is a step behind the H3. Now you can use it with the legacy kernel and get all the nice things working on a carefully crafted armbian image, but with an ancient kernel. The summary of all this is that armbian + kodi requires a decent amount of exercise either because armbian target is not multimedia and because the "best" SoC here has still several missing things. That's also the reason why many people said buy a RPi3 which has all the USB ports, GPIO, hardware acceleration (with the notable exception of H.265), 64 bits, chips, fries and desserts for the miserable price of €35
  2. Maybe all the things you want may be found in an Allwinner H3 box, probably the best choice for armbian is Beelink X2 which is supported out-of-the-box. Pros: Cheap (below 30$) Have decent support in mainline linux, thanks to the effort of the community GPU drivers can run Bootlin works for reverse engineering the VPU and thus hardware video encoding and decoding Cons: The SoC is a bit old nowadays (Cortex A7) The GPU is quite old (Mali 400) The GPU drivers are quite horrible (but if you just run Kodi they should suffice) and have no vsync I don't what is the status of the VPU hardware video decoding now, probably will require some months to mature. Maybe ask on Kodi forums about would turn out to be interesting Otherwise the most decent thing which has everything you ask, but not in mainline but fairly recent kernel, is rockchip family (rk3288/rk3328/rk3399). However, except for the Beelink X2 (Allwinner H3) which are supported out of the box by armbian, it's a matter of luck getting a tv box and hoping everything works. I have a discontinued rk3288 tv box which is capable of being a decent media center, but I spent several weekends to reverse engineer lots and lots of details to make it useful (but now I can proudly write this comment from it ) AMLogic has the oldest kernel of the group, dunno what is the status of mainline kernel but I think they did not release their customized GPU drivers at all
  3. Yes, indeed RPi3 is a good choice. The only drawback is that h.265 being software decoded because the VPU/GPU part has not been updated since their debut, on the other side you get plenty of support by community and foundation, and also an opensource GPU OpenGL driver which works pretty well, as opposite of the crappy blobs for ARM Mali GPUs
  4. Well, you should at least specify the hardware you want to run armbian and kodi on. If your intent is to just run armbian + kodi, usually you get most hardware acceleration (GPU + video decoding) if you use the kernel provided by the hardware manufacturer, but don't expect a warm soup ready for lunch. Each SoC is a different story: GPU drivers are not always available (mostly due to ARM Mali license, the most common GPU in SoCs), and sometimes they are misbehaving. It's kind of puzzle-game where not always all the pieces are there to be fit togheter. At the moment, I don't know any board which works out-of-the box with vanilla armbian. Some work has been done by the community for rockchip rk3288 (see here). Rockchip are the most promising because the manufacturer provides documentation and source code and also GPU drivers works. Allwinner provides GPU drivers for their old Mali400/450 GPUs. Bootlin reverse engineered the VPU on older SoCs (H3 and going back) to provide hardware acceleration for videos on mainline kernel and apparently some support is appearing in ffmpeg, although I don't know if it is ready to be used. AmLogic is unknown to me, I think you should stick to their white-beard old kernel if you want GPU and VPU acceleration
  5. Took the 6 .patch files and dropped them as-is into patch/kernel/rockchip-dev directory. Compiled a new Bionic image with 4.18.11 kernel, burnt the image on a SDcard and here it is, everything seems perfect to me. My panel is 1920x1080 60hz and works flawlessy, but also tried lower resolutions (1280x1024, 1280x720, 1024x768, 800x600) via xrandr and all of them worked fine. The purple line never appeared and the monitor never complain. HDMI sound also works fine, except for the fact that it works every other time I switch the resolution, but I think this is another issue. Patches were applied correctly with no errors to the 4.18.11 kernel, but they didn't make it into mainline 4.14. Did not try at all on legacy 4.4 dmesg log is uploaded here (but I guess there's nothing interesting in there) edit: I think I talked too early, after turning the monitor off and on the purple line was there. Should I also try by copying the frequency table and other bits from the veyron DTS?
  6. Ok, made a little post on general chit-chat so even other people may benefit from gl4es:
  7. This mini-tutorial is for those interested in running OpenGL applications and games on OpenGL ES. Most (maybe all?) SoCs around support OpenGL ES, which is almost a stripped down version of OpenGL. OpenGL ES is mainly used by smartphone apps, but on Linux and generally on desktop computer OpenGL clients are the most common. This tutorial is very simple and will teach you on how to download and compile GL4ES (github:, a nice piece of software that converts most OpenGL calls into OpenGL ES counterparts to achieve some degree of compatibility and let your apps run on our SoCs. The target of this tutorial is the Rockchip RK3288 SoC with Mali-760 MP4 GPU, but hopefully it runs on other GPUs as well. 1) First of all you need git and cmake, so on your Armbian distro run: $ sudo apt update $ sudo apt install git cmake 2) Now clone the GL4ES repository: $ git clone '' 3) Run cmake to create the appropriate Makefile with our preferred configuration. We here use the ODROID profile and set OpenGL ES 2 as default (gl4es will look by default for libary this way): $ cd gl4es $ cmake . -DODROID=1 -DDEFAULT_ES=2 4) Compile the code: $ make GL 5) If everything went well, copy the library into /opt: $ sudo mkdir -p /opt/gl4es $ sudo cp lib/ /opt/gl4es 6) Set the LIBGL_COPY environment variable in /etc/profile, so it will always be set at startup. This is needed because by default GL4ES applies a workaround for an issue in some drivers and the workaround is not needed on Mali drivers. Not setting this variable will result in incredible slowdown on some scenes which use a particular OpenGL function: $ su -c "echo export LIBGL_COPY=1 >> /etc/profile" 7) Reboot your system This should be enough to run OpenGL 1.5/2 applications. We run our preferred application setting the LD_LIBRARY_PATH environment variable pointing to /opt/gl4es, like this: $ LD_LIBRARY_PATH=/opt/gl4es glxinfo You should get something like this: The first lines (like "LIBGL: Initialising gl4es" and so on...) tells us that GL4ES library is being used and tells you what kind of extension is used too. In particular, you should see gl4es in version string to be sure that gl4es will work. If you want to see something moving, glxgears is the perfect candidate: $ LD_LIBRARY_PATH=/opt/gl4es glxgears A trick I found to be very powerful in some cases is setting the LIBGL_BATCH environment variable. This trick tries to reduce the calls to the driver batching vertices together in a single call. For some games this works wonderfully and gives a huge boost (Quake II, for example), on others it is harmful for performances (Quake III) and on others creates graphical glitches. Use it when appropriate: $ LD_LIBRARY_PATH=/opt/gl4es LIBGL_BATCH=1000 glxgears GL4ES has a lot of other environment variables that can be tested for various purposes. The complete list is available here Last delicacy - Quake shareware If all the steps have been done right, running Quake shareware should be a breeze: $ sudo apt install quake quakespasm lhasa game-data-packager $ game-data-packager -i quake $ LD_LIBRARY_PATH=/opt/gl4es quake
  8. at the moment my bluetooth chip is not described in the device tree. Your finding could be nice although, but I think it works only for a small amount of bluetooth chips (guessing from the documentation above, just one chip). Normally it is enough to load the correct firmware file for your chip using the brcm_patchram_plus utility (this what I do for my AP6330) without bothering the device trees at all, so I guess that if you know the bluetooth chip which is inside your AP6335, the next step is find the firmware file for it (usually a file with .hcd extension) and try to modify /lib/systemd/system/ap6330-bluetooth.service file to load the new firmware
  9. @JMCC yes of course, I will do a small tutorial as soon as I have some spare time! The compilation process is quite easy to accomplish, although documenting important environment variables is essential
  10. I guess this script will never work on rock64: it has a RK3328 SoC and Mali-450 GPU. This script instead installs drivers for RK3288 which has a totally different and not compatible Mali-760 GPU
  11. @naseeb As JMCC already said, the script will work on Armbian Ubuntu Xenial. I'm using it with latest dev kernel (4.18) and it works too, but don't expect it works on other distributions, expecially Bionic which has a different way to handle mesa packages. Also if you compile the kernel from the rockchip repository, probably you miss the mali kernel driver and you have to compile it yourself later as a module. Armbian includes some useful patches for that too. Does /dev/mali0 exist on your filesystem? I first would stick to a kernel built for Armbian, which has some useful patches that helps. You can build just the kernel following the instructions and then drop it into your filesystem to see if it boots/works. You may also try one of the Xenial images of my armbian fork for RK3288 TV boxes (see the TV Box forum section) which, with a bit of luck, may boot on your board... many devices won't work, but the basics of the SoC (GPU, USB, HDMI, ethernet, ...) should be fine
  12. I think the issue is the same as described here: You should have a recent revision of the kernel to include the working version. I lost some amount of time trying to guess what was happening on my setup, which was working fine some days ago, and finally it turned that Linus Torvalds made a patch to the kernel that broke some non-conform gpu drivers, including Mali. Finally Myy made a patch for that which I included and I guess TonyMac32 included in the upstream armbian.
  13. This: which comes from this: can be useful to you. Using that script you get all the fancy things needed to enable glamor in X11 session (drivers, patches, and other things...) It works only with Xenial and I'm not totally sure what it does under the hood, but surely it would be nice to have something which works out of the box. By the way, glamor has poor performance for the 2D X server: general applications are quite slow to render, the terminal emulator is painfully slow when scrolling for example. Nonetheless it enables hardware acceleration and those applications which can render in EGL surfaces themselves, like Chromium, or games or multimedia players works very well.
  14. Glad to hear it works! Normally brcmfmac looks into /lib/firmware/brcm directory for its firmware files. armbianEnv.txt instead sets the kernel command line argument that changes the directory to /lib/firmware/ap6335/brcm, so the driver will look there. It is just to keep things tidy, as long as other firmware files for broadcom are into their own directories Also renaming the binary into the filename expected by the driver is essential, without doing this it will never be able to find it. Did you have the chance to try bluetooth too?
  15. Yes, you are missing the appropriate firmware files. My box has AP6330, which is manufactured by AmPak and is actually a combo of broadcom chips. In my case it has the BRCM4330 wifi chip and BCM40183 for bluetooth. In your case you have a hint by the brcmfmac driver telling you it is expecting brcmfmac4339-sdio binary file. Now the first thing to do is some tidying up. On your box edit the file /boot/armbianEnv.txt and change this line: extraargs=brcmfmac.alternative_fw_path=ap6330 cma=64M into this line: extraargs=brcmfmac.alternative_fw_path=ap6335 cma=64M This way we are telling the brcmfmac driver to find all its things into /lib/firmware/ap6335/brcm path. Now you can grab the necessary firmware files from this repository: In particular you will need to: download the firmware blob fw_bcm4339a0_ag.bin into /lib/firmware/ap6335/brcm/brcmfmac4339-sdio.bin (you may also try fw_bcm4339a0_ag_apsta.bin or fw_bcm4339a0_ag_p2p.bin) download the nvram configuration nvram_AP6335.txt into /lib/firmware/ap6335/brcm/brcmfmac4339-sdio.txt after a reboot (or modprobing the module) you should have done a step forward to get the wifi working. A last note: It is possible that you also get bluetooth. At the moment there is a systemd service (ap6330-bluetooth) that loads the bluetooth firmware binary used on the AP6330. In the lucky case the firmware is compatible you also get free bluetooth, but I don't guarantee anything on this.
  16. Nice to see that it boots on ugoos board Although I didn't intend to support it, it's nice to see that at least it boots and most of the functionality works!
  17. Nope, this is expected. Try to unplug and replug the HDMI cable (or turn the TV off and on). It is a strange but common issue I guess with the HDMI driver. edit: also check from the speaker icon on the upper-right side that pulseaudio is sinking to HDMI and not to spdif
  18. Normally writing the beginning of mmcblk0 to mmcblk2 substitutes the partition table wrote by armbian-config script on the eMMC with the one from the SDCard. Since the sdcard is usually bigger, it is not wise to overwrite the partition table tailored for the eMMC by armbian-config. To transfer correctly u-boot from mmcblk0 to mmcblk2 you should copy a small but sufficient amount of data this way: dd if=/dev/mmcblk0 of=/dev/mmcblk2 skip=64 seek=64 count=2048 conv=sync,fsync This way you copy 1 megabyte (u-boot is around 600 kbytes, the rest are zeros) starting from sdcard at sector 64 to the eMMC at sector 64. You may also try to install armbian on the eMMC and then boot with an USB stick plugged (use the non-OTG ports) and without the sdcard inserted. If u-boot on the eMMC is booting correctly, it should detect the USB stick and boot from there.
  19. Yeah you would be the first tester of the spdif interface, since I had no equipment to do it ;) I hope it works though!
  20. No DAC at all on the board, at least on mine: there is no analog out audio. If you're interested in some kind of audio out from the device you can either use it via HDMI on your monitor/TV or buy a decent optical DAC depending on your requirement.
  21. u-boot has its own device mapping and, on my board, u-boot detects the device in reverse order (sdcard has index 1 and mmc has index 0). I thought it was something common for our boards and not to be worried, but probably it needs to be fixed. About not booting from eMMC, I have no clue at the moment. Unfortunately no video output during boot makes hard to guess what happens if you don't have a serial port, I'm working on it but it is a bit hard to sort it out :/ edit: mainline-dev actually installs and boots fine on my board, but occasionally it turns off during kernel bring up. Using the serial I see that it is something which happens during the initialization of the sdcard controller and its vcc regulator: ... [ 2.934789] usbcore: registered new interface driver bfusb [ 2.941136] usbcore: registered new interface driver btusb [ 2.947343] Bluetooth: Generic Bluetooth SDIO driver ver 0.1 [ 2.954765] of: /cpus/cpu@501: Couldn't find opp node [ 2.962388] cpufreq: cpufreq_online: CPU0: Running at unlisted freq: 500000 KHz [ 2.971865] cpufreq: cpufreq_online: CPU0: Unlisted initial frequency changed to: 600000 KHz [ 2.982620] sdhci: Secure Digital Host Controller Interface driver [ 2.987609] usb 1-1: New USB device found, idVendor=1a40, idProduct=0101, bcdDevice= 1.00 [ 2.989591] sdhci: Copyright(c) Pierre Ossman [ 2.998815] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [ 3.003679] Synopsys Designware Multimedia Card Interface Driver [ 3.004581] dwmmc_rockchip ff0c0000.dwmmc: IDMAC supports 32-bit address mode. [ 3.011735] usb 1-1: Product: USB 2.0 Hub [MTT] [ 3.018481] dwmmc_rockchip ff0c0000.dwmmc: Using internal DMA controller. [ 3.027111] hub 1-1:1.0: USB hub found [ 3.031669] dwmmc_rockchip ff0c0000.dwmmc: Version ID is 270a [ 3.031700] dwmmc_rockchip ff0c0000.dwmmc: DW MMC controller at irq 30,32 bit host data width,256 deep fifo [ 3.039317] hub 1-1:1.0: 4 ports detected [ 3.043482] vcc_sd: supplied by vcc_io --- stops and turns off ---
  22. I see that your board is a tiny bit different than mine. Mine has XT-Q8L-V10, instead yours is ENY-Q8L-V10. Yours has a frontal LCD panel connected to the board header, instead mine has just the IR remote and a red/blue LED. I think a dmesg log would clarify the mmc device block names. Actually I had no idea on how kernel assigns names for the different devices. On my setup mmcblk0 is the external Sdcard and mmcblk2 is the internal eMMC. I should normalize this, like mmcblk0 for the eMMC and mmcblk1 for the external SD.
  23. Looks strange, normally sdcard controller is described in the common device tree for all the rk3288 devices. Maybe, for some reason, the device is not enumerated as mmcblk0 but something else. Could you paste the dmesg on pastebin or here so I can take a look into? Also if you have access to it, it would be nice to see a photo of the internal board, just to understand if it is a different revision or has some kind of different hardware.
  24. Bump up due to some news: New Xenial image with mainline 4.14.68 kernel New Xenial image with latest and greatest 4.18.6 dev kernel (which seems pretty stable to me) Both new images now fully support the IR Remote out of the box, in native mode via kernel keymappings and drivers. Kernel keymap table can be customized using ir-keytable tool. Kernel 4.18.6 also exposes the native lirc interface, so in theory any remote controller can be trained to work with the box Both new images enables the SPDIF connector (it is untested though due to lack of a Optical DAC at home) Added devfreq support for the GPU: at the moment the base frequency is 100 Mhz and maximum frequency is 600 Mhz. The GPU may be too lazy to switch frequency, so you can force a minimum frequency issuing (as root) echo 300000000 > /sys/class/devfreq/devfreq0/min_freq to force the pre-devfreq default operating frequency. You may also force 600000000 (600 Mhz) as minimum to run the GPU always at full speed. Beware the thermals anyway, when the core reaches 70°C it starts throttling and your performance may not be as you expect if you don't cool enough the SoC Every other thing which has been put into Armbian lately is also in the images Enjoy!
  25. Mmh, the first question that arise to me is if you are really sure about your setup. Looking at the device tree you described I see that: 1) you attached the os8104 to the i2c bus 0 and configured it to use address 0x41 on that bus 2) you attached some pins of os8104 to the board gpio 3) you describe a "default" pin configuration using pinctrl-names and pinctrl-0 properties. What you do with these directives is more like: "Setup the board pins with those settings at default", and not "my device uses these pins and I want to control them from the kernel". Actually your kernel module does not know about the "default pins configuration", you should instead also describe the GPIO bank and pins used with some proprietary codes. Something like this: &i2c0 { clock-frequency = <400000>; status = "okay"; os8104: os8104@41 { compatible = "smsc,os8104"; reg = <0x41>; master = <0>; /* slave mode*/ bypass = <0>; /* /ABY (all bypass mode) im register bXCR */ os8104,reset-gpio = <&gpio2 RK_PD7 ACTIVE_HIGH>; os8104,int-gpio = <&gpio3 RK_PA4 ACTIVE_HIGH>; . . . pinctrl-names = "default"; pinctrl-0 = <&os8104_reset &os8104_int &os8104_aint &os8104_error &os8104_3dB>; }; }; Then you should be able to grab the gpio from your kernel module using the OF functions. You may take a look to the other device trees and drivers combo shipped with the linux kernel for other examples