jernej

I just learned on U-Boot HDMI driver example that kernel implementation is not complete. Most importantly, it is missing code for changing PLL_VIDEO clock, which is important code for supporting otherwise non suported resolutions.

Apparently I just fixed Mali issue by setting PHYS_OFFSET cpu_usage_adjust to 0 

Well, it could be that the issue is the same. I fixed my U-Boot driver. It seems that we shouldn't adjust addresses at all. Hm... I should test that also with One or Lite, but currently I don't have such board at hand. Do you?

I managed to write H3 HDMI driver for mainline U-Boot. Source can be found here:
https://github.com/jernejsk/u-boot
 
You should also add CONFIG_VIDEO=y to defconfig for your board.
 
It should work nicely for standard resolutions (720p, 1080p). Other resolutions might work, but some additional work needs to be done. Currently, this can be used for working with U-Boot (instead of serial console) or splash screen.

I pushed possible fix for non standard resolutions and also fixed that Kconfig setting. I will now investigate Plus2E issue.

I managed to write H3 HDMI driver for mainline U-Boot. Source can be found here:
https://github.com/jernejsk/u-boot
 
You should also add CONFIG_VIDEO=y to defconfig for your board.
 
It should work nicely for standard resolutions (720p, 1080p). Other resolutions might work, but some additional work needs to be done. Currently, this can be used for working with U-Boot (instead of serial console) or splash screen.

I managed to write H3 HDMI driver for mainline U-Boot. Source can be found here:
https://github.com/jernejsk/u-boot
 
You should also add CONFIG_VIDEO=y to defconfig for your board.
 
It should work nicely for standard resolutions (720p, 1080p). Other resolutions might work, but some additional work needs to be done. Currently, this can be used for working with U-Boot (instead of serial console) or splash screen.

I managed to write H3 HDMI driver for mainline U-Boot. Source can be found here:
https://github.com/jernejsk/u-boot
 
You should also add CONFIG_VIDEO=y to defconfig for your board.
 
It should work nicely for standard resolutions (720p, 1080p). Other resolutions might work, but some additional work needs to be done. Currently, this can be used for working with U-Boot (instead of serial console) or splash screen.

I tested it again with marking "m" at #2272 CONFIG_RC_CORE and "y" at #1871 CONFIG_I2C_MUX=y. It does seems to work well as expected.
I opened a pull request, you can check it out here if you like:
https://github.com/igorpecovnik/lib/pull/523
 
Thank you for your great help buddy !

Sorry, yes, there is an output, monitor reports 1280x1024 in its menu, so looks like framebuffer size is the only issue.

If you make a test image for one of the boards listed in my signature, I can test it on a TV which has lower native resolution.

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.