jernej

I checked code quickly and while it is true, that it has mostly uninterested things, it contains some interested bits. Newest 3.4.39 BSP kernel, which could also be compiled for H3. I will make a diff to see if there is anything important, but I guess not. Other interested thing is different mali framebuffer driver. Instead UMP it is using dmabuf. Probably it is not interesting for Armbian, becuase it doesn't support X11. I guess that now it can be officially added to linux-sunxi collection of userspace mali drivers.

To be honest: while testing with A64 a few hundred hours (unattended of course) I might have connected a display to the Pine64+ I had here maybe one or two times. IIRC I tried out whether the HDMI-to-DVI fixes known from A83T and H3 also match with A64 BSP kernel.
 
So I'm definitely the wrong person to ask for display issues. But I highly appreciate that you look into. It can't be overestimated what you've done for H3 already. Do you have access to A64 hardware already?

It is in the repo, it will be available with new release.

Ok, I checked few things and this should work:
 
1. edit platform/platform_ops.c and remove lines from 34 to 39 so the function will just return 0.
2. deselect all platforms in Makefile
3. compile with:
make KSRC=/lib/modules/$(uname -r)/build ARCH=arm

Igor,
 
I finished and tested autoloading patch with opi2 and bpim2+. I think it is safe to assume that we no longer need to wory about wifi drivers, at least until new version of bcmdhd module shows up.
 
bcmdhd WOW patch:
https://github.com/jernejsk/OpenELEC-OPi2/blob/e148c9b4d685ca3987364177d9c7db519c6345a0/projects/H3/patches/linux/linux-202-bcmdhd-add-wow-selection.patch
 
wifi auto power on & load patch:
https://github.com/jernejsk/OpenELEC-OPi2/blob/e148c9b4d685ca3987364177d9c7db519c6345a0/projects/H3/patches/linux/linux-203-rf_pm-auto-power-on.patch

Igor,
 
I finished and tested autoloading patch with opi2 and bpim2+. I think it is safe to assume that we no longer need to wory about wifi drivers, at least until new version of bcmdhd module shows up.
 
bcmdhd WOW patch:
https://github.com/jernejsk/OpenELEC-OPi2/blob/e148c9b4d685ca3987364177d9c7db519c6345a0/projects/H3/patches/linux/linux-202-bcmdhd-add-wow-selection.patch
 
wifi auto power on & load patch:
https://github.com/jernejsk/OpenELEC-OPi2/blob/e148c9b4d685ca3987364177d9c7db519c6345a0/projects/H3/patches/linux/linux-203-rf_pm-auto-power-on.patch

You can wait for tomorrow. I will try to patch rf_pm driver in a way, that this won't be necessary. This behaviour would be identical to that on mainline kernel - there is a node for wifi power in device tree. If it is present, wifi chip is powered and scanned for driver.

Final solution implemented:
 
I found even newer driver, which I had to modify to work with sun8i kernel. Good thing here is that has even better system for nvram autoselection - based on chip id. Now it is possible to have one driver for multiple chips/boards. Tested on BananaPi M2+. I also fixed crashes, so it should cleanly unload and reload. Solution was found in Amlogic version of the driver - not to power down when it tells you. That means that the chip will stay powered after driver is unload, but this could be fixed by issuing:
echo "000" > /proc/driver/wifi-pm/power Updated driver:
https://github.com/jernejsk/OpenELEC-OPi2/blob/ccd4132dbfc5a6de0962b63ae68d55cce527c791/projects/H3/patches/linux/linux-201-update-bcmdhd-driver.patch
 
Driver config file for nvram autoselection:
https://github.com/jernejsk/wlan-firmware/blob/34d66e85f8c6ce5b0291bc4aa0cc5c0dd88d659d/firmware/brcm/config.txt
 
Tested on BananaPi M2+ and OpenELEC, I'm waiting for X2 report. Should work exactly the same on Armbian. With this fix, there is no reason anymore to have manual wifi driver loading. For that purpose systemd or similar script could be enabled/disabled.

@Igor or whoever maintains this device,
 
there is a nice method how to autoload correct wifi (sdio) driver on sun8i instead of manually specifying it at build/runtime. This behaves just the same as USB driver autoloading. If you execute
echo "123" > /proc/driver/wifi-pm/power then the kernel will scan sdio bus and automatically load appropriate driver. I tested that with all common wifi drivers (8189es, 8189fs, bcmdhd) and it works.
 
There is a catch, as usual. BananaPi M2+ and Beelink X2 use same driver, bcmdhd, but they use different FWs and nvram files. If you put FW files in same folder then problem is solved for firmware part. The problem stays for nvram file. Quick fix would be that at build time you overwrite nvram file with correct one because user must download appropriate image anyway. Universal approach, which is already implemented by the driver, is to make a config file with translation between mac range and nvram file name. I sent e-mail to AMPAK about mac addresses, but I don't really expect the answer.

@Igor or whoever maintains this device,
 
there is a nice method how to autoload correct wifi (sdio) driver on sun8i instead of manually specifying it at build/runtime. This behaves just the same as USB driver autoloading. If you execute
echo "123" > /proc/driver/wifi-pm/power then the kernel will scan sdio bus and automatically load appropriate driver. I tested that with all common wifi drivers (8189es, 8189fs, bcmdhd) and it works.
 
There is a catch, as usual. BananaPi M2+ and Beelink X2 use same driver, bcmdhd, but they use different FWs and nvram files. If you put FW files in same folder then problem is solved for firmware part. The problem stays for nvram file. Quick fix would be that at build time you overwrite nvram file with correct one because user must download appropriate image anyway. Universal approach, which is already implemented by the driver, is to make a config file with translation between mac range and nvram file name. I sent e-mail to AMPAK about mac addresses, but I don't really expect the answer.

I created a patch for a wifi driver which makes mac generating unnecessary and eliminates the problem you experienced:
https://github.com/jernejsk/OpenELEC-OPi2/blob/785fc6c4f88c2cc3e01244069ffb50663c50ffb3/projects/H3/patches/linux/linux-200-wifi-mac-fix.patch
 
Allwinner function is used which generates wifi mac based on sid data. It differs only in one bit compared to ethernet mac but it is enough.
 
@Igor,
you can apply it if you think it is useful... It will certainly simplify build script a bit.

BTW: Had a short laugh: http://vpneveryone.ddns.net/vpn.blackbox/opi-ipsec-vpn-server.htm

Yes, everyone else has same issue. And no, currently there is no great solution, only workarounds, like playing video in separate application, IIRC.

As without serial console, I tried to integrate load mmc ... into the Armbian boot script. Didn't work also with ext4load or putting it in separate lines   but ...   with the information of your posting how to access partitions I just copied the contents of the Openelec boot script into the Armbian one: setenv bootm_boot_mode sec setenv bootargs console=ttyS0,115200 boot=/dev/mmcblk0p3 disk=/dev/mmcblk0p2 consoleblank=0 fatload mmc 0:3 0x43000000 script.bin fatload mmc 0:3 0x42000000 KERNEL bootm 0x42000000 And this did work :-) :-) :-)
  Thanks for providing the "hint"!   I had this nearly before, but with those two files on the Armbian partition and it didn't work.   I'll write a how-to, as I guess others are interested in this "dual boot" also.

I went through CMA allocation memory reservation for CMA code and I couldn't find any issue, which, of course, doesn't mean that it is ok.
 
 
 
This source: https://github.com/jernejsk/linux
Those patches: https://github.com/jernejsk/OpenELEC-OPi2/tree/openelec-7.0/projects/H3/patches/linux
 
EDIT: Clarification about CMA.

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