• Content Count

  • Joined

  • Last visited

Reputation Activity

  1. Like
    RagnerBG reacted to Tido in Kickstarter: Allwinner VPU support in the official Linux kernel   
    Free Electrons is changing to a new name, in the context of a trademark dispute.
    The weird thing about this campaign - you support ALLWINNER, while ALLWINNER actually should pay Bootlin to do this for them.
    Especially people using OSMC  OpenELEC  LibreELEC  Kodi - should be strong supporter of this Kickstarter ... unless you use a different SoC.
  2. Like
    RagnerBG reacted to m][sko in weston and gnome3 works with mali wayland drivers   
    I want tou share with you my experience with weston with mali wayland drivers
    Wish list:
    Can you guys add 
    to for all board with mali GPU
    And also set up directory and library cache for mali userspace drivers 
    so all application will use mali  version istead of mesa
    We still have problem with v-sync with amlogic DRM driver
  3. Like
    RagnerBG reacted to Icenowy in Orange Pi One Plus   
    No USB3/PCIE. This makes this board not interesting at all. I think people should wait for Orange Pi 3 (I think 3 Plus may also have also some problem) or Pine H64.
    P.S. The DRAM chip is branded "Allwinner". (noted by TL Lim)
  4. Like
    RagnerBG got a reaction from Димитър Мазнеков in h.265   
    I don't know how build-in mpv in Desktop Armbian behave. But i am using my own built of mpv and it play h265 video fine. I tried several videos, including 4k resolution and they all played with very low CPU usage. OPI PC is great device for such purpose, fueled by Armbian, of course . I don't know if you want to try this, but here are the basic steps i think should be enough to build it yourself too. Some of this may be redundant, but this way works for me.
    First the newest version of libvdpau-sunxi is needed for h265 and especially for subtitles support. As i don't know what is in Desktop Armbian, i will post this too. First make some temporary directory, it's "t". located in ~home in my example. We need livdpau>=1.1, so:
    cd t wget http://ftp.de.debian.org/debian/pool/main/libv/libvdpau/libvdpau1_1.1.1-3_armhf.deb wget http://ftp.de.debian.org/debian/pool/main/libv/libvdpau/libvdpau-dev_1.1.1-3_armhf.deb wget http://ftp.de.debian.org/debian/pool/main/v/vdpauinfo/vdpauinfo_1.0-1+b1_armhf.deb sudo dpkg -i libvdpau1_1.1.1-3_armhf.deb sudo dpkg -i libvdpau-dev_1.1.1-3_armhf.deb sudo dpkg -i vdpauinfo_1.0-1+b1_armhf.deb Then libvdpau-sunxi:
    git clone https://github.com/linux-sunxi/libcedrus.git cd libcedrus make sudo make install cd .. wget http://cairographics.org/releases/pixman-0.34.0.tar.gz tar -xzvf pixman-0.34.0.tar.gz cd pixman-0.34.0 ./configure make -j4 sudo make install cd .. git clone https://github.com/linux-sunxi/libvdpau-sunxi.git cd libvdpau-sunxi make sudo make install We need to "export VDPAU_DRIVER=sunxi", "export VDPAU_DISABLE_G2D=1" and for subtitles support "export VDPAU_OSD=1". As i had a lot of troubles with this and never new for sure where is the correct place for this, i do it in several places. So put this:
    export VDPAU_DRIVER=sunxi export VDPAU_OSD=1 export VDPAU_DISABLE_G2D=1 in /etc/environment , in /home/"user"/.bashrc  and in /etc/X11/Xsession.d/ create file named "90environment" (sudo nano /etc/X11/Xsession.d/90environment) and put the lines there too. This is all done for libvdpau-sunxi.
    For mpv, first get dependencies:
    sudo apt-get update sudo apt-get build-dep libav sudo apt-get build-dep mpv If you want youtube support, install youtube-dl:
    sudo curl https://yt-dl.org/downloads/2016.02.27/youtube-dl -o /usr/local/bin/youtube-dl sudo chmod a+rx /usr/local/bin/youtube-dl Install x264:
    git clone git://git.videolan.org/x264.git cd x264 ./configure --enable-static --enable-shared make -j4 sudo make install sudo ldconfig cd .. and get x265:
    sudo apt-get install mercurial cmake cmake-curses-gui build-essential hg clone https://bitbucket.org/multicoreware/x265 There is a bug here and we can't build shared libraries, so before compilation open this file x265/source/common/primitives.cpp (sudo nano x265/source/common/primitives.cpp) and at the end remove the lines i marked with "-" in front:
    - #if ENABLE_ASSEMBLY && X265_ARCH_ARM == 0 void PFX(cpu_neon_test)(void) {} int PFX(cpu_fast_neon_mrc_test)(void) { return 0; } - #endif } #endif now compile and install x265:
    cd x265/build/linux ./make-Makefiles.bash make -j4 sudo make install sudo ldconfig cd ~/t I used to install some other codecs, but this should be enough for most people. Now the mpv itself:
    sudo apt-get install git devscripts equivs git clone https://github.com/mpv-player/mpv-build.git cd mpv-build ./update rm -f mpv-build-deps_*_*.deb mk-build-deps -s sudo -i .deb part is to get some more dependencies. This may not be necessary, but i remember i had build errors because of this before.
    Put some options for ffmpeg:
    echo --enable-nonfree >> ffmpeg_options echo --enable-gpl >> ffmpeg_options echo --enable-version3 >> ffmpeg_options echo --enable-vdpau >> ffmpeg_options echo --enable-libass >> ffmpeg_options echo --enable-libfdk-aac >> ffmpeg_options echo --enable-libfreetype >> ffmpeg_options echo --enable-libmp3lame >> ffmpeg_options echo --enable-libopus >> ffmpeg_options echo --enable-libtheora >> ffmpeg_options echo --enable-libvorbis >> ffmpeg_options echo --enable-libvpx >> ffmpeg_options echo --enable-libpulse >> ffmpeg_options echo --enable-libv4l2 >> ffmpeg_options echo --enable-libx264 >> ffmpeg_options echo --enable-libx265 >> ffmpeg_options echo --enable-libmpv-shared > mpv_options If you miss some of this codecs just skip the line, or remove it later from ~/t/mpv-build/ffmpeg_options file. Finish building and installation:
    ./rebuild -j4 sudo ./install That's all
    Optionally, you can add your config in file, so you don't write it every time - sudo nano /usr/local/etc/mpv/mpv.conf :
    vo=vdpau hwdec=vdpau framedrop=vo hwdec-codecs=all ao=alsa:device=[hw:1,0] slang=bg,en, fs=yes "slag" line is for subtitles, you can replace "bg" with your language, or remove it at all.
  5. Like
    RagnerBG got a reaction from hazardsneon in Samba Setup   
    I think you should check the permission of this folder - "/media/mickey/OPants", make it 777 for guests. But i would suggest you, to make it as simple, as possible. "guest ok = yes" - you don't need this, just add your user, as samba user (or create another user, only for samba sharing) and use - "valid users = <user_name>". "browseable = yes", "writeable = yes", i don't use this, so why should you? "read only = no" is enough. Try this config, as i already post above:
    sudo smbpasswd -a <user_name> [OPants] path = /media/mickey/OPants valid users = <user_name> read only = no That's all what i add and it's worked every time. And better change the sharing path to something in your samba user, Home directory, so you don't have to touch the permission. But i haven't deal with this joke - Win 10, so there may have some other surprise. Try to add the same workgroup, as on your Win 10 machine:
    [global] workgroup = WORKGROUP  
  6. Like
    RagnerBG got a reaction from hazardsneon in Samba Setup   
    Mount your HDD in folder inside your Home directory, so you will have full access through you active user elevations. You can edit fstab to be sure your HDD will be mounted in the same folder and paths after reboot. Better use mount by name (if you add name to your HDD volumes), or UUID. Then add your active user as smb user:
    sudo smbpasswd -a <user_name> Then add this at the end of your smb.conf (sudo nano /etc/samba/smb.conf):
    [<folder_name>] path = /home/<user_name>/<folder_name> valid users = <user_name> read only = no testparm sudo service smbd restart To avoid sharing of all your Home directory by Samba, comment all sections, related to ";[homes]", including. Of course you can use different user, from your actual, system user, for Samba sharing, but this is the easiest way.
  7. Like
    RagnerBG got a reaction from Ucino in VLC Issue   
    The only thing i can guess is that mplayer is using internal ffmpeg, or what is present in Armbian, or self mencoder (at least if it's build from source), while mpv have it's own ffmpeg (again - at lest if it's build from source). Maybe if you start mpv in fullscreen with command line argument (or in conf file), this a/v desynchronisation will be gone. I had this problem before, with framebuffer version of Mali driver and this solved it. But Armbian now using X11 version, i think. Maybe there is a bug in newer versions of binaries (mali, libvdpau-sunxi). I would try to compile everything from source, including mpv, mplayer, vlc (good luck with that) and not install from repos. About vlc, i am surprised it even worked (sort of) with libvdpau-sunxi, without compilation from source. It wasn't before.
  8. Like
    RagnerBG reacted to @lex in FFmpeg 3.3.4 "Hilbert" with Cedrus on github   
    For anyone interested I have pushed the sources to github here: https://github.com/avafinger/ffmpeg-3.3.4_cedrus264
    Feel free to try. It has been tested on A64, R40 and possibly will work on H5 too.  Cross compiling and re-writing the package in a compliant way would speedup things.
  9. Like
    RagnerBG got a reaction from Tido in Lamobo R1 as Router using the Wifi as Gateway and running a DHCP-Server in all the Switchports   
    If you plan to use built in WIFI in "Client" mode only, there shouldn't be a problem. I haven't tested much, but problems were in "AP" mode, client was kind of stable. So better test first, before changing the whole module (witch is generally good idea for this crappy board, but may be too much for your needs), how it interacts in client mode. About setup @reverend_t post explain briefly what you need. But if you prefer quick and not so complicated solution, with GUI, check out OpenWrt for this board (if there is still any download link alive).
  10. Like
    RagnerBG reacted to tkaiser in how to set up swap partition   
    No time wasted!
    I thought today a little bit about why Armbian ships with such an anachronistic default configuration and whether it would be worth a try with more recent kernels to switch from swap to zram (and adjust vm swappiness since with vm.swappiness=0 most probably no one will ever see a difference).
    An interesting test would be
    sed -i 's/vm.swappiness=0/vm.swappiness=60/' /etc/sysctl.conf FILE=$(mktemp) wget https://mirrors.kernel.org/ubuntu/pool/universe/z/zram-config/zram-config_0.5_all.deb -qO $FILE && dpkg -i $FILE reboot But I've to admit that I don't know how to test whether something changes since I know swapping only as problem of the past. I've now 3 ROCK64 with different DRAM sizes. Maybe someone has an idea how a useful 'benchmark' could look like comparing different DRAM sizes?
  11. Like
    RagnerBG got a reaction from Tido in Banana Pi R2   
    Hello. I just want to say - all this blah, blah, but you missing the point. People are not rude against you just like that, but because of your company actions. This is reputation you've earned. False advertising, incorrect information, hardware issues, this is the problem. TK is maybe sort of sarcastic, but it is for a reason. Most of his comments are not "full of malice and disgust", but full off useful information, for you and your potential customers. It's only better for you if you not ignore them, but take a notes. 17 years software and hardware development and you don't know, it's not all about open source (at lest for your company), but to provide support. If you care about open source support, provide the sources opened and proper documentation, so people can do development for you. But if the hardware vendor don't want to do this, there is nothing wrong in closed source, if it's workable and with proper license. But nor you, nor your vendors do any of this, it's just NO support at all. Let's see MTK now, but with your other partner AllWinner, we see a lot of circus with free interpretation of what "open source" and "GPL" means, reflection mostly on end customer. Things like these are the reason, people with experience with your company, been not so nice. Not your English language (mine is not good too). I personally have experience too. I own one of your products and use it for good, but only at 50% of what was advertised back then and with a lot of hardware and software interventions from my side to make it at least stable at these 50% of usability. How could i be very gentle and buy another product from you? And i could be potential buyer of this new R2, if only things were different this time. But from what we see so far, even in this thread, it's the same - hardware and software, a huge deja-vu. Poor new owners, they don't get it yet, but we do and with this exposure, in this very thread, you don's make things different. You had one good product - the first BPI-1, what's gone wrong since then?
    I will keep following this topic. It's really fun . And with latest efforts to use this forum for the same false advertising and reclame, make it even more interesting. Only need popcorn.
  12. Like
    RagnerBG reacted to tkaiser in Banana Pi R2   
    Especially since it's the same since ever or let's say since we have to deal with these guys (in the beginning when Foxconn let LeMaker do the support/software/documentation job for the original Bananas it was different, then LeMaker got greedy, applied for Banana trademarks and has been kicked out... since then we suffer from total ignorance). 
    Please look at https://archive.is/tY9gt -- the copy&paste monkey they hired to run the forum and fill their gitbook resources with random nonsense fetched a table from FriendlyELEC wiki where a responsible vendor describes their internal engineer's work to move away from Allwinner BSP to mainline Linux kernel (the result of an email conversation between them and us which even led to hardware improvements once FriendlyELEC realized that mainline kernel allows for DVFS unlike BSP). Now they garnish this with some sentences mentioning MTK/R2, add a screenshot and make a forum post out of it. The sole purpose is to create the impression of some 'hard work' being done and to feature this forum post on G+ and Facebook where a clueless crowd applauds.
    And in the meantime this sort of advertising happens even here. It's unbelievable especially that these guys don't get it why lies are wrong, that correct information/specifications are important and so on. That's such basic stuff but they simply don't give a sh*t about this at all since years while at the same time whining about 'people attacking us'. And their ignorance totally shields them from reality.
    Edit: 'Lion_Wang, the figure you posted' has been removed by him now. Guess why. The same game they play since years now happening even in Armbian forum, really unbelievable.
  13. Like
    RagnerBG reacted to TonyMac32 in Banana Pi R2   
    In the case of specific hardware with partial or incorrect device trees, etc, the schematics are quite useful for pin numbers etc.  There are always examples of features not fully implemented, even when advertised. 
    As an Electrical Engineer, I would politely remind you that code does not execute in a magical place where no physics exist.  Things like "can this board be powered via GPIO?"  "What is the maximum current available via USB?".  "Is the SD regulator capable of switching to 1.8V for high speed?" "How are the processor opp voltages derived?". All require schematics to verify, especially when the company spends all their time on new boards and almost none on support.
  14. Like
    RagnerBG reacted to tkaiser in Banana Pi R2   
    Well, 'I can confirm that sound support isn't compiled into the kernel' so 1) it has been never tested by the 'manufacturer' as expected and 2) users need to compile the kernel on their own to get at least HDMI audio. Besides that combining multimedia features with router/firewall functionality on the same device without appropriate separation is still one of the most stupid goals ever.
  15. Like
    RagnerBG reacted to tkaiser in Banana Pi Zero   
    There's no need to rely on my comments, not rejecting reality is already sufficient. The CSI connector is physically incompatible and even if there were adapters still no Raspberry camera would be compatible to Bananas and vice versa. Same with the DSI display connector on the so called 'RPi 3 killer' also known as Banana Pi M2 Berry. At the same time resellers have to lie to their customers about 'all accessories being fully compatible' since SinoVoip simply doesn't give a shit about providing correct information (check this link and 'Fragen und Antworten' there).
    Their official 'technical documentation' is just the result of a brain damaged retard playing 'copy&paste gone wrong' and if you want a proof that these Banana products are not supported even by their own manfucaturer just visit their forum and ask a very simple technical question. You will only get an answer if your question is sales related and/or the moron posting as 'sinovoip bpi team' responsible for censoring their forum thinks he can squeeze some money out of you. Just visit their forum to get the idea how lost you are if you have to rely on 'vendor support'.
    Some people were stupid enough to try to help these irresponsible guys now for over 2.5 years ( @Tido and me amongst them) but they simply don't get that they need to improve, stop being notorious liars, provide correct information, release sources they have as soon as possible, provide correct schematics (they fail even with this! It's just unbelievable how lousy this company behaves). My last try to help was suggesting how to solve the M2 Ultra instabilities but now it's enough (I had to use a different account of course -- guess what happened as soon as they found out that 'charles' is 'tkaiser'? The 'sinovoip bpi team' moron immediately started to delete a lot of my posts)
    Let's leave this Banana stuff for the clueless crowd they defined as their target audience, let them babble in Facebook groups or whereever they want and simply forget about it. At the moment the manufacturer starts to improve let's talk again.
  16. Like
    RagnerBG reacted to jackmax in Orange Pi One - adding USB, analog audio out, TV out, mic and IR receiver   
    Hi everyone, I've just tried doing the audio out mod on my Orange Pi One. Here are my observations:
    1. The solder points are tiny, but if you have the right equipment (fine point soldering iron, fine solder wire) and a steady hand you can do it without much problem.
    2. The output is powerful enough to drive headphones directly (the volume isn't very high, but it works).
    3. You don't need the extra components (resistors, capacitors) to do this mod BUT if you plan on using an external amplifier, you should. These components form a simple high-pass filter. The output is DC biased, which means your amplifier will waste power and potentially overheat your speakers if you don't filter it out.
    4. You can use the HDMI port shield or the SD card shield for the ground.
    5. I connected the wires in reverse (left to right, right to left), so I had to swap the channels in software .

  17. Like
    RagnerBG reacted to giri@nwrk.biz in [Program] Move Composite AV Video Output to fix Overscanning   
    Hey folks!
    On monday I was able to fix the overscanning issue of my Orange Pi zero (read here).
    Because fiddling around with the register values can be pretty harsh some times I decided to created a small programm to move the picture of the composite video output. You can find the project page here: https://projects.nwrk.biz/projects/allwinner-tvout
    With this tool you can easily move the picture relative to its actual position by just calling :
    $ sudo tvout -m -x <value in px> -y <value in px>  
    To reset the position you can use:
    $ sudo tvout -r  
    I hope some of you may find this useful.
    If I have enough spare time i will add more features to this project (like changing the resolution, etc.). If you have any questions or ideas please feel free to tell me in this thread!

  18. Like
    RagnerBG reacted to giri@nwrk.biz in PSA: Orange Pi Zero expansion board tv-out not working solution   
    Yeah!! I managed to fix the overscanning issue!  (Credits go to this guy here for pointing me to the right direction!).
    All in all my Picture was Overscanning 20 px on every edge.
    At first I changed my resolution from the detected 720x576 to 680x536 (2 * -20 px = -40 px) in the script.bin. This results in an visible edge at the bottom of the screen and an visible edge on the right hand side (with a small black border!).
    $ bin2fex /boot/script.bin ~/script.fex $ nano ~/script.fex find these lines: fb0_width = 0 fb0_height = 0 and change them to: fb0_width = 680 fb0_height = 536 then: $ fex2bin ~/script.fex ~/script.bin $ sudo cp ~/script.bin /boot $ sudo reboot  
    Now the picture needs to be moved down and to the right by 40px to be fully visible!
    Next I needed to manipulate TV ENCODER RE-SYNC PARAMETERS REGISTER of the H2+ SoC. For this I used a little tool called devmem2 which helped me to directly read and write to the memory, and thus allowed me to manipulate the H2+ registers!
    devmem2 can be installed by using following commands:
    wget http://free-electrons.com/pub/mirror/devmem2.c gcc ./devmem2.c sudo mv ./a.out /usr/local/bin/devmem2  
    After Installing devmem2 I was able to shift the picture by manipulating the value on following Address: 0x01E00130! (=TV ENCODER RE-SYNC PARAMETERS REGISTER, this may differ depending on your SoC, check the Datasheet!)
    First I read back the actual value (so I could revert back changes in case I messed anything up!):
    $ sudo devmem2 0x01E00130 /dev/mem opened. Memory mapped at address 0xb6f0d000. Value at address 0x1E00130 (0xb6f0d130): 0x3005000A Now I was able to move the picture by writing a custom value to the register according to the R40 Datasheet: 
    Here is how I calculated this value with the help of the Datasheet:
    31 ... Re-Sync Field => 0b 
    30 ... Re-Sync Disable => 0b
    29:27 ... not used => 000b
    26:16 ... Vertical => 40d px => 0000101000b
    15:11 ... not used => 00000b
    10:0 ... Horizontal => 40d px => 0000101000b
    All in All: 000000000101000000000000101000b => 0x00140028
    So I used this command to set my display:
    $ sudo devmem2 0x01E00130 w 0x00140028 EDIT: I created a small tool which does the work above for you
    Finally I saved the command above in my rc.local file to shift the picture during boot.
    $ sudo nano /etc/rc.local paste following line: devmem2 0x01E00130 w 0x00140028 This is a dirty workaround and should be fixed within the driver!
    Hope this helps to correct your overscanning issues! This should also work with many other Allwinner based Boards. I read that some Bananapi users had a pretty similar problem with overscanning on AV out.
  19. Like
    RagnerBG got a reaction from Johann Pascher in HDMI Color to much saturation   
    I noticed this long ago, but it's not that obvious i think. You can always change saturation level in mpv - --saturation=<-100-100>. Last time i checked it's worked, but it was on A20 (different sunxi-vdpau version). I remember there where some work about these default values, because video was too dark for A20 version of sunxi-vdpau and tweaking saturation actually make it bright, before brightness levels was fixed.
    About video, you can try something else, not just Big Buck Bunny. For some reason this test video is not smooth in some builds (not using h/w acceleration), while working fine in others. You can check terminal messages about what decoder is used. If it's sunxi-vdpau, it have to be fine.
  20. Like
    RagnerBG got a reaction from Johann Pascher in Kodi on Armbian   
    Well, fortunately for me, i kind of understand Russian :), there is a lot useful info in this language anyway. I tried this guys previous project of Kodi 17 and it worked very well, but without h/w video acceleration. For Kodi only, the most useful for now is @jernej OpenElec. I tried IR there and it worked fine. Everything needed for IR is already in the image and is well explained - [FAQ] Openelec OPi for beginners. But if you need the whole Linux OS plus useful Kodi, there is no easy solution for now. Maybe this Kodi 18 with external player, or maybe this - OrangePi: Installing OpenELEC chroot into Armbian. This is what i am going to test these days if i find free time.
  21. Like
    RagnerBG reacted to divis1969 in HW accelerated video decoding/encoding on BPI M?   
    I have reworked ffmpeg's cedrus264 encoder to use libcedrus and modified libcedrus to allow few clients to use VE (in the same process).
    How it is possible to use both vdpau-sunxi decoder and cedrus264 encoder to transcode the video.
    The results for
    ./ffmpeg -hwaccel vdpau -i big_buck_bunny_720p_H264_AAC_25fps_3400K.MP4 -pix_fmt nv12 -r 5 -an -b:v 64k -c:v cedrus264 stream.mp4 are the following:
    Video is viewable, CPU usage is ~80-90%, FPS while encoding ~6.7, time real 0m56.523s, user 0m28.210s, sys 0m15.720s
    It is not as good as I was expecting though. Perhaps, copying data in memory is a bottleneck.
    Not sure it could be improved
    The code is located at https://github.com/divis1969/libcedrus (branch master) and https://github.com/divis1969/FFmpeg (branch 2.8-cedrus)
  22. Like
    RagnerBG reacted to zador.blood.stained in MMC: No card present error on Allwinner boards   
    Board does not boot Armbian from inserted SD card, but may boot other distributions (based on old/legacy u-boot).
    Following or similar output can be grabbed from the serial console:
    U-Boot SPL 2017.01-armbian (Feb 02 2017 - 03:04:04) DRAM: 2048 MiB Trying to boot from MMC1MMC: no card present spl: mmc init failed with error: -123 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ### The key message here is "MMC: no card present"
    Most likely cause:
    Malfunctioning microSD slot card detect switch.
    It can be verified either visually (with a magnifying glass) or electronically (with a multimeter) - at least in the slots used on Orange Pi boards and on Pine64 the pin near the switch should be shorted to the ground (i.e. SD slot casing) when card is inserted.
    Illustration (example) of a working switch:

    Verification (with a multimeter):
    Probe 1 - slot pin near the switch (may be different for different slot types, but at least true for Oranges and Pine64)
    Probe 2 - microSD slot casing or other parts connected to GND (not shown on the photo)
    No card - circuit is open
    Card inserted - circuit is shorted
    Photos - card is not inseted on the left and is fully inserted on the right:
    Orange Pi
    Pine64 (switch is more visible)
    Can it be fixed?
    Yes if the switch is not broken completely, by carefully adjusting (bending) the stationary contact (left on the pictures and photos, it usually is a part of the SD slot casing) i.e using a needle so it touches the moving contact (mostly hidden inside the slot on the photos) when card is inserted and not touching it when it is not inserted.
  23. Like
    RagnerBG reacted to dumischbaenger in Lamobo R1 hardware mods - all needed   
    Here is my housing!

    An here is a special cable to solve the HD power issue:

    With this configuration it is possible to supply the HD directly with energy.
    Although I do understand the criticism of tkaiser I think it would be a pity for me and perhaps others to drop support. I use it as a simple desktop switch and home server. With Armbian 5.24 it runs stable here. With 5.25 I was unfortunately not able to get the switch switchting till now.
  24. Like
    RagnerBG reacted to cu6apum in BananaPiPro. Video Accelerated No Work.   
    Hey, maybe you'll help further.
    Any way I try mpv, I get Error when calling vdp_device_create_x11: 25.
    Noticed that I don't have /dev/cedar_dev despite CONFIG_VIDEO_SUNXI_CEDAR=y in the kernel (included in armbian image, 3.4.113-sun7i).
    I tried to create the device, sunxi_cedar_mod cedar_dev c243:0 in /lib/modules/modules.devname, and then I get Bus error with mpv.
    What am I doing wrong?
    libcedrus, libvdpau, libvdpau-sunxi built from sources, no errors.
    Thank you.
    EDIT: solved, sorry. Put sunxi_ve_mem_reserve in wrong place. Should be in boot.cmd.
    EDIT2: https://addons.mozilla.org/en-US/firefox/addon/watch-with-mpv/
  25. Like
    RagnerBG reacted to tkaiser in H3 board buyer's guide   
    H2+/H3/H5 boards overview (2017/03 update)
    Since it has been a while since this topic has been updated and a lot of new boards have been released in the meantime it's time for a new overview.
    I'll add also H2+ and H5 based boards since in the meantime we learned that those SoCs are pin-to-pin compatible and recently vendors started to simply exchange H3 with H5 on some PCB (and vice versa in at least one occurence). From a software point of view H5 is quite different (using 64-bit Cortex-A53 CPU cores and ARMv8 instruction set, some early boot stages are also totally different compared to Cortex-A7/ARMv7 used in H3 and H2+) and it should also be noted that Armbian currently only provides OS images based on mainline kernel for H5 boards (so please forget about HW accelerated video decoding or 3D for now or maybe ever since none of the developers is in the mood to deal with Allwinner's BSP/legacy kernel for H5 (regarding 'BSP' just look above in post #2).
    While software support for H5 is currently somewhat different hardware features are pretty much the same as with H3 (still 3 to 4 real USB2 host ports and one USB2 OTG port: a simple register setting can switch the Micro USB port's PHY between the so called 'musb' controller used for OTG and a real EHCI/OHCI controller pair: with mainline kernel it will soon be possible to switch OTG to a real 4th USB2 host port with full feature set that still has not to share bandwidth with any of the other USB ports).
    CPU performance with H5 compared to H3 is slightly higher at the same clockspeed but some workloads that benefit from either 64-bit or ARMv8 instruction set are significantly faster (eg. software making use of NEON instructions might perform almost twice as fast and the best example is the stupid 'sysbench' CPU pseudo benchmark which shows over 10 times better scores on the same hardware when compiled with ARMv8 settings).
    In the following list I will also introduce some subjective 'categories' to deal better with the huge amount of boards we can use in the meantime:
    NAS category: these are the H3/H5 boards with Gigabit Ethernet IoT category: these are the small and cheap boards best suited for low consumption 'General purpose' category: all the other H3 devices, these are also those you should look for if you want a cheap device to run with X11, OpenELEC, RetrOrangePi or Lakka since they all feature HDMI and full legacy kernel support As already said the differentiation is subjective and partially misleading since new boards like NanoPi NEO 2 featuring Gigabit Ethernet are also that inexpensive, small and energy efficient that they could serve both as NAS and IoT nodes (actually you can somewhat control behaviour since GbE vs. Fast Ethernet makes a pretty huge difference in consumption so it's up to you). Boards that might fit in multiple categories are listed more than once to make comparisons more simple if you're only interested in a specific device category:
    NAS category (only due to Gigabit Ethernet available):
    Banana Pi M2+: H3, 1GB DRAM, 8GB slow eMMC, 1+2 USB ports useable, Wi-Fi/BT Banana Pi M2+ EDU: H3, 512MB DRAM, no eMMC, 1+2 USB ports useable NanoPi M1 Plus: H3, 1GB DRAM, 8GB slow eMMC, 1+3 USB ports useable, Wi-Fi/BT NanoPi M1 Plus 2: H5, 1GB DRAM, 8GB slow eMMC, 1+3 USB ports useable, Wi-Fi/BT NanoPi NEO 2: H5, 512MB DRAM, no eMMC, 1+1+2 USB ports useable NanoPi NEO Plus 2: H5, 512MB DRAM, no eMMC, 1+2+2 USB ports useable, Wi-Fi OrangePi PC 2: H5, 1GB DRAM, no eMMC, 1+3 USB ports useable OrangePi PC Prime: H5, 2GB DRAM, 1+3 USB ports useable, Wi-Fi/BT OrangePi Plus: H3, 1GB DRAM, 8GB eMMC, 1+4 USB ports useable (hub), Wi-Fi OrangePi Plus 2: H3, 2GB DRAM, 16GB fast eMMC, 1+4 USB ports useable (hub), Wi-Fi OrangePi Plus 2E: H3, 2GB DRAM, 16GB fast eMMC, 1+3 USB ports useable, Wi-Fi IoT category (cheap, small, energy efficient, most of them headless):
    NanoPi Air: H3, 512MB DRAM, 8GB slow eMMC, 1+1+2 USB ports useable, Wi-Fi/BT, no Ethernet NanoPi NEO: H3, 256/512MB DRAM, no eMMC, 1+1+2 USB ports useable, Fast Ethernet NanoPi NEO 2: H5, 512MB DRAM, no eMMC, 1+1+2 USB ports useable, Gigabit Ethernet NanoPi NEO Plus 2: H5, 512MB DRAM, no eMMC, 1+1+2 USB ports useable, Wi-Fi, Gigabit Ethernet OrangePi Zero: H2+, 256/512MB DRAM, no eMMC, 1+1+2 USB ports useable, Wi-Fi, Fast Ethernet OrangePi Zero Plus 2: H3, 512MB DRAM, 8GB fast eMMC, 1+0+2 USB ports useable, Wi-Fi/BT, no Ethernet but HDMI OrangePi Zero Plus 2: H5, 512MB DRAM, 8GB fast eMMC, 1+0+2 USB ports useable, Wi-Fi/BT, no Ethernet but HDMI General purpose (HDMI and full legacy kernel support: video/3D HW accelerated):
    Beelink X2: H3, 1GB DRAM, 8GB slow eMMC, 1+1 USB ports useable, Wi-Fi, Fast Ethernet NanoPi M1: H3, 1GB DRAM, no eMMC, 1+3 USB ports useable, Fast Ethernet OrangePi Lite: H3, 512MB DRAM, no eMMC, 1+2 USB ports useable, Wi-Fi, no Ethernet OrangePi One: H3, 512MB DRAM, no eMMC, 1+1 USB ports useable, Fast Ethernet OrangePi PC: H3, 1GB DRAM, no eMMC, 1+3 USB ports useable, Fast Ethernet OrangePi PC Plus: H3, 1GB DRAM, 8GB fast eMMC, 1+3 USB ports useable, Wi-Fi, Fast Ethernet OrangePi Zero Plus 2: H3, 512MB DRAM, 8GB fast eMMC, 1+1+2 USB ports useable, Wi-Fi/BT, no Ethernet pcDuino Nano 4: See above, it's just an OEM version of NanoPi M1 done for Linksprite Some important notes:
    The following boards are listed in more than 1 category due to advanced feature mix: NanoPi NEO 2, NanoPi NEO Plus 2 and OrangePi Zero Plus 2 H3/H5 CE/FCC certifications: Please check individually and don't trust in logos silkscreened on the PCB, even if it looks like 'CE' it might mean 'China Export' instead IO bandwidth: H2+/H3/H5 SoC features 3+1 USB2 ports but on a few boards an internal USB hub is used so while these expose more USB receptacles some ports have to share bandwidth. Also on these boards a buggy/slow GL830 USB-to-SATA bridge is used. Search for 'hub' above to identify them. eMMC: shows most of the times higher random IO performance compared to 'the average SD card', but some vendors use pretty slow eMMC on their boards (Xunlong being the exception with OPi PC Plus, Plus, Plus 2, Plus 2E and Zero Plus 2). Please do not overestimate eMMC -- there's no need to choose crappy/slow SD cards and if you follow the usual recommendations difference in performance varies not that much (for example eMMC on most boards shows pretty low sequential write speeds that will be easily outperformed by any good SD card and differences in random IO don't have to be that huge, simply watch out for SD cards showing A1 or even A2 logo) USB ports: Some of the IoT devices have two of the SoC's USB host ports available on a pin header to be used with soldering or combined with various Docks, HATs or 'Expansion boards' (search for '1+1+2' above). On OPi One/Lite the unexposed USB host ports are available at pretty tiny solder pads so only usable with a lot of soldering experience Wi-Fi/BT: all boards providing both Wi-Fi and BT rely on Ampak's AP6212 so performance is identical, the Wi-Fi only boards either rely on RTL8189ETV/8189FTV (slightly better Wi-Fi performance than AP6212) or Allwinner's XR819 (so expect low Wi-Fi performance with OPi Zero or NEO Plus 2 since implementation is low-end and currently driver sucks) Yeah, each vendor's naming scheme totally sucks. Partially there are rules involved (the 'Plus' then means eMMC with Xunlong or GBit Ethernet with FriendlyELEC... mostly) but please don't trust in and check always individually!  
    And now another few words on a different technical detail affecting both performance and thermal behaviour of the various boards: Voltage regulation / DVFS. TL;DR: the SoC can be fed with a variable voltage (VDD_CPUX), the lower the voltage the lower the temperature (less problems with heat/overheating), the higher the voltage the higher the maximum CPU clockspeed. So the best idea is to adjust this dynamically (low voltage/clockspeed when idle and only increasing both when needed). There are 3 variants to implement this: not at all, primitive or advanced (using a voltage regulator that's able to adjust VDD_CPUX in 20mV steps)
    Only 3 devices implement no voltage regulation at all: Banana Pi M2+/EDU (frying the SoC constantly at 1.3V therefore prone to overheating), Beelink X2 (no idea) and NEO 2 (only 1.1V therefore limited to 1008MHz cpufreq max since above instabilities might occur).  Some boards use SY8106A I2C accessible voltage regulator where we can use fine grained voltage settings (Armbian fine-tuned these for every board so far to achieve max performance). This applies only to the following Xunlong boards: OPi PC, PC Plus, PC 2, PC 3, Plus, Plus 2 and Plus 2E. All other boards implement a simple two voltage scheme and are able to switch between 1.1V (up to 912MHz possible with H2+/H3 or 1008MHz with H5) or 1.3V (1.2GHz max with H2+/H3 and 1.25GHz with H5) And finally to add some stupid rankings: the cheapest board is from Xunlong (Orange Pi Zero: $7), the fastest is from Xunlong (Orange Pi PC 2 for $20) and the one with best feature set and onboard peripherals is also from Xunlong (Orange Pi Plus 2E: $35). And that's only due to OrangePi PC 3 Prime still not being released at the time of this writing (since otherwise regarding both performance and features this specific Xunlong board... )
    Hope that helps
    Edit: OPi 3 is now known as OPi Prime and (almost) nothing has changed compared to the leaked pictures back from last August.