Jump to content

jernej

Members
  • Posts

    1144
  • Joined

  • Last visited

Everything posted by jernej

  1. I will get two MiQi boards and I will try to make preliminary Armbian support.
  2. Can you point me where the term "Allwinner Cedrus" is used? It is not used in this topic.
  3. First, let's make something clear. Cedrus is open source project, which is aimed at creating open source Video Engine driver. Because of that effort, you have driver for BSP kernel which implements VDPAU interface. There is also effort to make mainline kernel driver using V4L2 interface, lead by FreeElectrons developers for C.H.I.P. (A13). Of course, this effort is using knowledge from Cedrus and with minimal changes it can be ported to other Allwinner chips too. That was already done for some of them and I'm not sure if it already works on H3 or it will be soon. This mainline driver has only few simple codecs supported, it is not yet intended to be used daily. But both interfaces, VDPAU and V4L2, currently support only decoding and from what I understand, you need encoding? There is open source code for encoding somewhere, but I think it is in PoC stage at the moment. Sorry, I don't know nothing about MT7688 platform. Last time I played with OpenWRT it was a few years ago and I never tried to use HW video acceleration or better said any kind of video processing on it. At most, I was using USB audio card and even that was big PITA to make it work at that time. BTW, I'm not sure why you are comparing NextThingCo. C.H.I.P. with Armbian. First is HW company which contracted FreeElectrons to make mainline support for A13 chip and Armbian is community effort to create build system which is simple to use and create best possible OS images for multiple platforms based on existing code, which gets improved by Armbian devs. I hope that you see that these two efforts are not comparable and of course there is no point for Armbian to support A13, because first, some dev must be interested in it (currently there is noone) and secodly, this platform has already decent SW support in comparison to Xunlong SW offerings, for example.
  4. I checked datasheet and board schematic and only setting possible is to select polarity. For any permanent disabling, HW solution must be used.
  5. Do you have access to (another) linux machine? If yes, then it is easy. Install sunxi tools, connect OPi through micro USB cable and remove SD card. Power on board and execute on host machine: sunxi-fel uboot u-boot-h3-video-helper.bin More detailed description at http://linux-sunxi.org/FELand http://linux-sunxi.org/FEL/USBBoot Another possibility is to write it to SD card. Only thing you need to do is: dd if=uboot-h3-video-helper.bin of=/path/to/sdcard bs=1k seek=8 conv=fsync,notrunc
  6. I created a tool (special U-Boot) which tells correct parameters for monitor native resolution: https://github.com/igorpecovnik/lib/issues/594#issuecomment-272992961 Please run it (link above) and copy output or post an image what is displayed.
  7. As I promised, I published helper tool. Please check this comment: https://github.com/igorpecovnik/lib/issues/594#issuecomment-272992961
  8. @martiinsiimon, unfortunately I don't see nothing wrong. You wouldn't be the first to burn HDMI part. Actually, I heard for many such unfortunate situations.
  9. It was explained many times on this forum. Do a search. No, it doesn't. It depends on Cedrus open source project which aims to replace CedarX (libvdpau-sunxi is part of that project)
  10. Ah, ok, I missed that. While you can still try SW decoding, imo it is too slow. You can still however use external program, but I'm afraid that mentioned shortcommings still applies. The most feature you will get from mosterta Kodi port (in your link), but I will have to figure how to compile everything. You need patched kernel, patched libvdpau-sunxi, patched Kodi and I think also some additional libraries. Again, you can do this only on legacy image.
  11. Disclaimer 1: I ported OpenELEC with Kodi to H3 Disclaimer 2: I don't know how exactly Kodi works under X11, becauce OpenELEC doesn't use it. I see that you are caught in the loop, so few clarifications: 1. Kodi doesn't need glshim, because it knows how to work with OpenGL ES 2. Currently you need legacy image. Vanilla a.k.a. mainline version is not there yet. Desktop version highly recommended. 3. You will have issues with HW acceleration of video decoding. Mali has nothing to do with it. libvdpau-sunxi doesn't work with Kodi, unfortunatelly. You have two choises. First, use SW decoding (can't use H265, because it is too slow, higher SoC temperature, ...) or secondly, use external player (mpv) which knows how to use libvdpau-sunxi, but you'll lose overlays (GUI which is rendered over video -> subtitles, stop, pause, ... buttons, info about video, etc.) and you have to learn mpv keyboard shortcuts. Choice is yours.
  12. RagnerBG, slight correction - mesa is not only SW implementation of OpenGL (ES). It can be also HW accelerated, but unfortunatelly not with Mali400 GPU. There is a stalled project to do that.
  13. Ok, thanks for the explanation. Probably nobody really checked the wiki. Maybe another important advantage of sunxi-fel method which I couldn't find mentioned on that page is that you don't need to fiddle with SD card images just to flash chip for the first time. Anyway, I'm convinced. Maybe this method just need some promotion on this and other forums along with the explanation why SPI NOR chip is a good thing.
  14. Great, I should check it before I made a post. A bit off topic, H5 support is marked as WIP. Any info on that? I see that H5 FEL support was added to sunxi-tools master. I tought that is enough?
  15. I heard that capability for writing to SPI flash might be added to sunxi-fel so it will be even easier. I forgot what is the current state regarding this.
  16. I think the best way is to ask monitor what timings it prefers. That way you can be sure to use best possible combination. As soon as I will have some time I will prepare something as described here: https://github.com/igorpecovnik/lib/issues/594
  17. What Igor meant is that in newer version of Armbian TV driver is hardcoded into kernel and it is not module anymore. This means that it should work by changing only script.bin. I don't think you can properly load driver as a module if same driver is part of the kernel.
  18. Everything you described seems to be in order. Removing ESD diodes also work, because they are mean to be connected to ground. If you remove them, there will be no protection, but otherwise should work just as well. Last chance - can you post deatiled photo of your board (top and bottom), so I can check if anything is out of order?
  19. I bough RK3299 at one point for hacking. Unfortunatelly, I can't find any SDK. Does anyone now where to find it? On the other hand, I'm more and more interested in RK3288 based boards. Support for that chip should be pretty good in mainline kernel. If someone know cheap board (max. 50 USD), please tell me. I think I could find some time to add support for it.
  20. I'm dev behind OpenELEC fork for Oranges. I received a lot of complaints about CEC on PC Plus. Most of them says that CEC simply doesn't work while it works with other boards. My suspicion is ESD protection diode ESD20. Can you please check if it is populated (next to the HDMI connector)? Better yet, which ESDXX element is placed?
  21. I don't know if it is hw or drivers. I would say both. Router SoC are completely different segment, so you can't really compare. I'm not fan of doing benchmarks. What I can tell you is that I reached max around 400 KiB/s on 8189es chip and few MiB/s on ath9k_htc, but this wasn't in the same environment.
  22. 1. Oh, sorry, it might be. However, I still don't recommend Realteak. 2. With kernel patching and recompiling.
  23. Yes, I heard, but I don't have it, so I can't tell you anything about it. From what I heard, I don't think it is particulary good chip. In fact, I wouldn't recommend anything from Realtek. BTW, I think P2P interface (for WIFI direct) is also disabled in Armbian.
  24. No, OpenELEC and Armbian share most of the BSP kernel improvements. I took something from them and they took something from my kernel. There is very little difference about kernel functionality. Mostly some out of tree improvements. For example, Armbian has overlayfs support while OpenELEC uses BFQ governor. It should be the same regarding WIFI and ethernet support. I'm not sure what you mean by power regulation... Secondly, OpenELEC has completely different goals that Armbian. Armbian is general purpose distro, while OpenELEC can do only one thing good - it runs Kodi. OE doesn't have any apt-get or similar packaging system (although it can be extended using Kodi plugins). In fact, most of the filesystem is read only, except /storage which can be seen as home folder. It is also single user system - (almost) everything is run as root. It also doesn't use X11 and doesn't have desktop environment at all. Thirdly, I didn't add support for OrangePi Zero, because it didn't want that users with 256 MB version start to complain and Kodi is not optimized for low resolutions offered by TV out. As mentioned before, Kodi is the only program which is meant to be run. So there is no option to install VLC. If you badly want it, you can take build system and somehow make VLC Kodi addon, which would in reality be separate program. I saw some attempts to port VLC to OpenELEC, but please don't ask me for help. TVheadend client could be used in Kodi via plugin. Someone also attempt to use TVheadend server in OpenELEC but the main issue here is lack of HW encoder support in SW. As with all addons, I don't offer any support. There are simply too much of them. OpenELEC is distribution. However, Kodi uses CedarX libraries for decoding, yes. What is "VLC codec"? There is no such thing. VLC is a program, which is usualy used for video playback. I think it can also transcode using separate program. It usually uses ffmpeg for managing video. ffmpeg is a great collection of various codecs (encoders/decoders), (de)muxers (*.avi, *.mkv, TS), transports (HLS, files, sockets). I'm not sure what do you mean by that. Kodi is used for video or audio playback. Because it is meant to be mediacenter, I'm not sure if you can play more than one stream at the same time. You mean one ath9k usb dongle? I bought one no name chineese wifi dongle and by pure luck, it uses that chip. I bought also one TP-Link dongle, but I read on the net that even if you buy same model and version, there is no 100% gurantee that you will get exactly same chip. There are some: https://wiki.debian.org/ath9k_htc#Supported_Devices I really don't know anything about WIFI Direct or Miracast. I never used them. In fact I disabled WIFI Direct support at one point in OpenELEC because it gived two wifi interfaces which was very confusing in Kodi.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines