zador.blood.stained

I don't think it would cost much for mass production. And it is possible that decision to ship with unsoldered headers (including Ethernet port) was made after the decision to pre-populate eMMC with OS image.
 
From my perspective for boards with eMMC an ideal user experience would be a special button or jumper which would force booting from onboard SPI flash pre-populated with something close to "fel-mass-storage" payload, so you would get eMMC exposed via g_mass_storage on OTG port.

Please download this: http://www.lemaker.org/product-bananapi-download-33.html
There is "Banana Pi 2D.pdf" file with board dimensions, but I can't confirm if this is correct since I don't own this board.

We don't have to test anything every day or even every week. Testing is required mostly when bumping u-boot and/or kernel versions and before releasing new packages and/or images.

I also added DVI compatibility option (disp_dvi_compat=on), untested.

Now setting display resolution in uEnv.txt is supported for Pine64 default kernel:
root@pine64:~# cat /boot/uEnv.txt ethaddr=ca:17:10:f7:2b:29 disp_mode=720p60 Available modes are listed in boot script. Al least 720p60 works for me in addition to default 1080p60

There is a syntax for sources.list to tell which architectures to use for the repository:
deb [arch=armhf] https://dev2day.de/pms/ jessie main

Armbian build script depends on OS specific and architecture specific tools and configuration, and the only supported environment is Ubuntu Xenial x64.
Virtual machine is recommended in case you don't want to install development tools to your home or work environment, but it is not required if you run Ubuntu Xenial x64 natively or in a container.

https://github.com/igorpecovnik/lib/commit/3332e4bb38d89e96b77201bbde60e1da08c15ca1
It's fixed in build script but images need to be updated.
 
Possible workaround: reboot a board at first login and it might be o.k. (untested)

I downloaded and checked Armbian_5.20_Cubieboard2_Ubuntu_xenial_4.7.3.img, and it has SPL signature in place. If your board fails to detect it, it is most likely a problem on your side - SD card, card reader, power supply or board itself. Or you are writing the image wrong.

youtube-dl and livestreamer
 
Edit: Also mpv player (may need youtube-dl too to work properly)

Unfortunately we don't have Cubieboard 2, so we can't debug booting issue on this board.
 
This is strange. If board boots from NAND while SD is inserted, then it means that SPL signature was not found on the card or SD failed to initialize.
 
So system booted from NAND detects SD card and detects partition table on it (since /dev/mmcblk0p1 is created)?

Unfortunately we don't have Cubieboard 2, so we can't debug booting issue on this board.
 
This is strange. If board boots from NAND while SD is inserted, then it means that SPL signature was not found on the card or SD failed to initialize.
 
So system booted from NAND detects SD card and detects partition table on it (since /dev/mmcblk0p1 is created)?

youtube-dl and livestreamer
 
Edit: Also mpv player (may need youtube-dl too to work properly)

Patch should look like this: add-can-driver.zip
You should unpack it to userpatches/kernel/sun7i-default/ and then compile kernel with KERNEL_CONFIGURE=yes to activate new kernel options
 
Edit:
Don't forget that you also need to enable CAN in FEX file
[can_para] can_used = 1

Yeah, i talked with MPV people in irc in the meantime and concluded the same. Either the backwards calculation has some bug, the matrix is wrong or we miss some other bit...
I have to check the first one with doing some tests with https://github.com/rellla/snippets/tree/master/sunxi_csc
I'd like to see, that the calculation is right. But first we have to look into the matrices itself. Maybe I'll add a function in vdpau code to print them and see what's different ...
Kind of strange that whole CSC thing...
 
Edit: The function you linked should be definitely the one we have to compare with vdpau calculation routines.

Some files appear to be missing in kernel headers package. This should be fixed in new release.

Please test this swconfig package (don't forget to use absolute path or remove other binary):
https://dl.dropboxusercontent.com/u/5385968/swconfig_15.04-2%7Earmbian5.20%2B1_armhf.deb

Thanks for testing. I'll have to look into mpv code.
And no, it should not break anything on H3, because display2.0 is not using the equalizer...
 
EDIT: Looking into mpv player code, it seems, that they don't scale their contrast and saturation value from 0.00-1.00-10.00 like vdpau spec likes it to have, but only map their -100~+100 to 0.00~1.00
So default is 0, which gets 0.50 in vdpau. According to ftp://download.nvidia.com/XFree86/vdpau/doxygen/html/struct_vdp_procamp.html#a96fd21f127e9b5ba24024f60ae42851dthis is wrong because it should be 1.00
 
Conclusion: Imho no libvdpau-sunxi issue but sth. mpv related

Don't know what sets default saturation in mpv, but I'll add
saturation=100 to config file shipped with Armbian mpv package
 
Edit: if this doesn't cause problems on H3

Initial attempt: https://github.com/zador-blood-stained/fel-mass-storage

Initial attempt: https://github.com/zador-blood-stained/fel-mass-storage

It's a good idea, but it still leaves a question of loading u-boot and kernel/script.bin/initrd initially. If SPL doesn't want to boot from available SD card this won't help much...
 
... unless FEL is used to "bootstrap" the process. Just for experiment I compiled sunxi-fel for Windows and installed libUSB driver in single click with Zadig tool. So we could provide an application/set of scripts for Linux and Windows to do this.

Another Orange device:
 

Added, will be available as a module in the next release.

There was an internal change and git cloning function was replaced. Now you need to specify
KERNELBRANCH="tag:v4.7.3" for tags (and
KERNELBRANCH="branch:master" for branches)