jock

Members
  • Content Count

    125
  • Joined

  • Last visited

About jock

  • Rank
    Elite member

Recent Profile Visitors

564 profile views
  1. jock

    kodi on armbian?

    There's also a bigger model (c400). This is exactly what I was talking about "no support from manufacturer" when dealing with tv boxes; you're on your own. edit: BTW I see that c300 is a s905d devices, but your link points to some documentation about a s912 device, maybe they are not the same device PS: for the chronicles, this could be interesting just to say I was in good faith when I was talking about H3
  2. jock

    kodi on armbian?

    there also was something by another manufacturer (magicsee) with the same s905d, maybe you are luckier with that
  3. jock

    kodi on armbian?

    You're absolutely right, so let's back on the tracks. A tv box is very handy if you're going to use it like a tvbox or some headless servering, here boxes with S905X are all around and mostly work good. If you want an all-purpose device which you can use for development, kodi, interfacing to arduino, with best all-around compatibility and don't want to bother with GPU and VPU issues, take an RPi3 (maybe latest Model B+), but here you have to resign to some "latest and greatest" (hw decoding for H.265 most of all, but also capped gigabit ethernet and the ethically discutible BLOB firmware) If you want to try armbian, get GPIO and be on the edge about performance and features, but also unable to use some features because of chipset manufacturers, you can select any board which sports Allwinner, Amlogic or rockchip (OrangePi, Odroid, Libre Computer, ...). This is the most adventurous and can be both satisfactory and frustrating when see you can't reach the goal (the same applies with tvboxes too, somewhat amplified) Maybe this link can be helpful to clarify current hardware accelerated video status for various chips.
  4. jock

    VPN Server Questions

    I tried it, but only on a Raspberry Pi 1 Model B. At work we use OpenVPN but are planning to switch to wireguard as soon as possible. I did some cheap benchmark to see if it worths and turned out that it worths! Wireguard on such old machine (ARMv6, without NEON) was 3x faster than OpenVPN against a simple download of a file (900 kb/s vs 3.2mb/s) and latency was actually a bit better. I didn't test more powerful ARMv7 and ARMv8 machines, but I expect the gap to be even bigger. On the opposite side, you lose some ancillary nice things OpenVPN has like pushing the routes on connections, automatic IP assignment, etc... Also running a DHCP service on the server is impossible because Wireguard lays on top of IP protocol
  5. jock

    kodi on armbian?

    1. Can you provide a link where I said H3 with Armbian + KODI has full HW support? Those are NOT my words, I said something completely different in the purpose to give the OP an idea of the actual state of the art about the various chips, not trying to sell him something!. 2. Glad to hear, but developers are saying that's far from being usable, and the same applies for others too. But just stick to the thread "Kodi + Armbian" - not "S905X on LibreELEC" - would you? 3. The differences between utgard and midgard gpu architectures are totally irrelevant to this thread That's your opinion, which may be respected but from my point of view is completely wrong. Start from vanilla Armbian and tell me how many steps you need to get GPU and VPU working for your favourite chip. My rk3288 tvbox was nothing more than a brick a couple of months ago, stuck with Android 4.4, before I poured time and time to bring armbian on it... hardware is nothing without software support, and software support for tvbox is totally absent. Suggesting to buy an unsupported chinese tvbox for a person who asked something completely different is intellectually dishonest.
  6. I changed my device tree to add HDMI frequencies and other things exactly as described in rk3288-veyron-chromebook.dtsi. The result is that the device boots and HDMI seems fine. Again changing resolutions via xrandr works and all resolutions I tried worked (1920x1080, 1280x720, 800x600, 1680x1050) but sometimes the purple line is still there. Also it seems that the purple line appears much often when I physically turn the monitor off and on than when I change resolution via xrandr. Also when the purple line is there, HDMI audio does not work. The fact that HDMI audio goes away and gets back once in a couple times makes me think about a flag that does not reset or so...
  7. jock

    kodi on armbian?

    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 (linux-meson.com 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
  8. jock

    kodi on armbian?

    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
  9. jock

    kodi on armbian?

    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
  10. jock

    kodi on armbian?

    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
  11. 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?
  12. jock

    RK3288 Media Testing Script

    Ok, made a little post on general chit-chat so even other people may benefit from gl4es:
  13. 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: https://github.com/ptitSeb/gl4es), 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 'https://github.com/ptitSeb/gl4es.git' 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 OpenGLES_v2.so 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/libGL.so.1 /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
  14. jock

    Armbian for RK3288 TV Box boards (Q8)

    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
  15. jock

    RK3288 Media Testing Script

    @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