jernej

OpenELEC also crashed on OPi Plus 2E board at first. I tried many things to no avail. I also thought that it was a Mali issue (r4p0 Mali driver). However, the issue is now gone and I'm not sure what caused it and what fixed it. This is the commit which supposedly fixed everything, which doesn't really make sense.
 
BTW: ION is used only for acquiring continous memory region from userspace. CMA, or better said, coherent DMA would be used in drivers.

You should take a look at this kernel config:
CONFIG_ION_SUNXI_RESERVE_LIST="160M@0,256M@0,130M@1,200M@1"
 
CMA values are ignored.
 
BTW, depending what you want to do, values bigger than 256M may not work.

There is always libhybris project which lets you use Android (bionic) libraries on ordinary (glibc) Linux. The catch is that if you intend to use some non standard library, you have to extend libhybris source with wrapper for it (or at least I understand it that way). Oh, did I mention that you also need other Android libraries, on which your lib depends (and dependencies of those libs and so on)? But at least they can be extracted from some Android image.
 
I didn't use it so good luck!

Yes, there are at least two - No HDMI documentation and no or GPL incompatible license for HDMI code in BSP kernel.

Yes, there are at least two - No HDMI documentation and no or GPL incompatible license for HDMI code in BSP kernel.

What do you mean by that? UI happily works with sunxi mali drivers. Did you mean VDPAU gles extensions? In that case my opinion is that Mali GPU is too slow for 4K cropping/scaling/rendering and Display engine (video unit) is much more convenient and capable for this.
 
 
 
SD card and eMMC installation are completely the same in functionality. Install script copies over same U-Boot, same script.bin, same kernel and same filesystem. In fact eMMC is often seen as SD card on chip (a bit simplified).

Dislaimer, I'm computer engineer and at my job I was working on a product which had some current measurement (< 6A) for protection, so my knowledge isn't perfect.
 
Everything depends how smart PMIC on Banana Pro is. You should test if a constant load (e.g. resistor), which would simulate maximum expected load, through time always reports same power. Possible issue I see here is that changing temperature (if load is high) might ruin measurements. I'm not sure if USB traces are designed for currents higher than 500mA. Another possible issue I see here is that you would also measure power loss on the cables and you know that with bad cables it can be significant. Definetly I would try to validate setup first and start small. What do you plan to use for 5W device?

Why don't you look at original Loboris settings then? Nobody here is comfortable to give you instructions how to shorten your board life. After all, a lot of time was spent to convince everyone that 1.6 GHz @ 1.5V hurts the chip.

Yeah, bcmdhd driver has some strange things inside the code. It seems mandatory to have some file specified, but later on it gets replaced with correct FW name based on chip id. If you check driver source, you can see a lot of different FW file names.

Overclocking H3 based boards is an option for users who believe in rationalism and not for users who believe in marketing bullshit. So @tkaiser simply protects this forum from users that would set their boards to 1.6GHz instead of 1.2GHz just because 1.6 is higher than 1.2, and then whine that "my board doesn't work anymore", "armbian is unstable" and "armbian sucks".

Why don't you look at original Loboris settings then? Nobody here is comfortable to give you instructions how to shorten your board life. After all, a lot of time was spent to convince everyone that 1.6 GHz @ 1.5V hurts the chip.

Well, if you use legacy image you have this driver already included and you don't have to do absolutely anything, except fix script.bin Unless you want to have it as a module, but this will give you just additional work without any benefit. Do you by any chance want to transfer this module to mainline kernel?

Yeah, bcmdhd driver has some strange things inside the code. It seems mandatory to have some file specified, but later on it gets replaced with correct FW name based on chip id. If you check driver source, you can see a lot of different FW file names.

Thanks for at least some encouragement While you (tkaiser) are absolutely focused on headless systems, others might be on desktop/graphics. So at least for them this will be interesting for a while. I will join you with maintaining desktop version shortly. If I want to make Kodi working with libvdpau-sunxi, Armbian is much nicer platform to develop on and I can help you with squashing some bugs in the meantime. Currently I'm a bit short on time, but I will contribute for sure.

Not sure if this would help. On H3 U-Boot is actually responsible for bringing up all cores through PSCI interface.

You will still have problems with decoding then. GL doesn't do any video decoding, just rendering. VDPAU rendering much more efficient BTW.

Which audio output do you use? There is a bug in analog output - it says that it supports audio formats which in reality it can't, namely 24 bit audio. If you patch it (check this and this patch), sound output should work normally.

Firmware is missing. Extract https://transfer.sh/h6nda/ap6210.tar.xzto /lib/firmware so you will have /lib/firmware/ap6210 folder. Then unload bcmdhd driver if it is already loaded and load it with following command:
modprobe bcmdhd firmware_path=/lib/firmware/ap6210/bcmdhd.bin nvram_path=/lib/firmware/ap6210/nvram.txt NOTE: Download link will be valid only for 14 days, but until then it will be fixed, I guess.

Thanks for at least some encouragement While you (tkaiser) are absolutely focused on headless systems, others might be on desktop/graphics. So at least for them this will be interesting for a while. I will join you with maintaining desktop version shortly. If I want to make Kodi working with libvdpau-sunxi, Armbian is much nicer platform to develop on and I can help you with squashing some bugs in the meantime. Currently I'm a bit short on time, but I will contribute for sure.

Thanks for at least some encouragement While you (tkaiser) are absolutely focused on headless systems, others might be on desktop/graphics. So at least for them this will be interesting for a while. I will join you with maintaining desktop version shortly. If I want to make Kodi working with libvdpau-sunxi, Armbian is much nicer platform to develop on and I can help you with squashing some bugs in the meantime. Currently I'm a bit short on time, but I will contribute for sure.

[Ended]   Be active, creative, helpful and you can get a powerful board in return. First give away batch is starting 11.6.2016  
It's not often that you can work on a software project that actually brings joy and helps people. Armbian is one of those project. It is a system that helps one build a kernel or boot images for several ARM development boards. 
 
It's in common interest that we improve level of support and to relieve most active people. Our crew needs an upgrade:
we need more coders, kernel hackers, UX designers to find and solve problems. If you are one of them, join our forum, join project at Github. we need properly built, packed and supported desktop with major functions: video acceleration/fbturbo, libump, mali, etc. we need to put together much better documentation. We need to fine tune MkDocs documentation tools For those who are willing to claim a task or help others to understand "how do I do this in Armbian" we prepared a dozen of boards as a small reward. It's a Xunlong Orange PI+ 2E, which design was improved based on requests from our community. It's H3 based quad core with 2G RAM, 16G eMMC, Gigabit LAN, WIFI and 3x USB.     There might be just enough boards for everyone who are willing to do some public service work. Claim your projects at this topic and each weekend we will discuss and select up to 15 people who will get the board, starting with 11.6., ... until we run out of boards. One will be notified by email and expect an answer within 48 hours, if not, board goes to somebody else.   Boards were donated and will be sent directly from Xunlong Co., Shenzhen, China.     1st batch is going to: Kriston, lanefu, vlad59, martinayotte, jeanrhum, Gravelrash, xcasex, naibmra, Xer0, madilabs, wha, @lex, WereCatf   naibmra - Bulgaria - kernel testing, try hooking to kernelci.org, docs - mid July wha - USA - 50unattended-upgrades, issue #337 - June Kriston - USA - documentation rework - July, August Xer0 - Germany - media build - July, August lanefu - USA - issue tracking improvements between forum and github - 22 June, July madilabs - Martinique - Packaging for desktop video acceleration - June xcasex - Sweden - desktop packaging - July, August jeanrhum - France - documentation and debian packaging - July martinayotte - Canada - maintain/fix DTS entries for some devices such I2C/SPI/W1 - ASAP vlad59 - France - Nanopi M1 testing and documentation Gravelrash - UK - Prepare HOWTO's & package "armbian-gc2035-fswebcam package" - June   2nd batch is going to: dimag0g, R2D2_C3PO, miked, 0x0, sysitos, jmcneill    dimag0g - France -  Packaging of OpenGL wrapper library - end of July R2D2_C3PO - Germany - Improved SD-Card partitioning - end of August miked - Canada - build system recension - end of August 0x0 - Russian Federation - Redesign site and documentation WIP + add some changes to graphics in distro. - end of July sysitos - Germany - replace/rework ramlog for systemd - end of August jmcneill - Canada - (Armbian is helping porting Freebsd)    Users were notified and were requested to provide: project name, due date and their shipping address

You can't. Driver has some generic code but chip dependant code is only for 8189fs. AFAIK, 8189es driver, which you added today, is the latest one.

You can't. Driver has some generic code but chip dependant code is only for 8189fs. AFAIK, 8189es driver, which you added today, is the latest one.

Here is my solution for loading different wifi drivers on different boards. Basically it is just oneshot systemd service which runs a bash script. That script checks script.bin settings currently in use (there is read_fex.c source) and based on wifi settings loads appropriate wifi driver. In case of RTL8189FS it also checks for saved mac address and pass it as an argument or it creates a random one and saves it. Paths should be updated to be more appropriate for Debian.
 
Latest RTL8189FS source is here.

Here is my solution for loading different wifi drivers on different boards. Basically it is just oneshot systemd service which runs a bash script. That script checks script.bin settings currently in use (there is read_fex.c source) and based on wifi settings loads appropriate wifi driver. In case of RTL8189FS it also checks for saved mac address and pass it as an argument or it creates a random one and saves it. Paths should be updated to be more appropriate for Debian.
 
Latest RTL8189FS source is here.