RagnerBG

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.

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.
 

I want tou share with you my experience with weston with mali wayland drivers
https://forum.odroid.com/viewtopic.php?f=138&t=28426&start=50#p213474
 
Wish list:
Can you guys add 
/lib/udev/rules.d/99-mali.rules
KERNEL=="mali",SUBSYSTEM=="misc",MODE=="0777"
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
 

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)

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.

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  

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.

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.

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.
 

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).

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?
 
 

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.

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.

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.

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.
 
 

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.

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 .

 

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!

 

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: 
 
TV ENCODER RE-SYNC PARAMETERS REGISTER Datasheet entry:
 
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!
 
Pictures:
 
 
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.

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.

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.

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)

Symptoms:
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.

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.
 
 

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/
:)