jernej

Where did you get that ideas? If you are ok with Allwinner provided (BSP) kernel (3.4.113), all things should work. Granted, Mali bug was fixed only two days ago and didn't yet come into stable release. HDMI under BSP kernel supports only standard resolutions, but that should not matter for most users. 1080p or 720p resolutions cover most screens. There were never an issue with ethernet on BSP kernel, AFAIK. Things are different on mainline (4.9) kernel. Most things are WIP but most HW units work if you are ok with experimental drivers. HDMI is still special story. At first it will support only standard resolutions, same as in BSP kernel. However, I wrote U-Boot HDMI driver, which seems to properly support almost any resolution. So there is room for improvement, but it will take some time. What NAND? You mean onboard eMMC, right? eMMC has basically same interface as SD card and it is supported a long time. What throttling do you reffering? If you mean CPU throttling, then this was one of the first thing fixed and refined multiple times later. I think it is as good as it could get. You already get your answer, but I will repeat it here. It was fixed two days ago and it should hit stable in next update.

Yes, that would make sense since I reused their code. There such solution would be actually useful, since HW is not capable of 4K. But U-Boot code is simple in regards of EDID parsing. I will check if this would be easy to implement. Can you please somehow extract edid info from your 4K display? This should be easy with BSP kernel, just search for edid file in /sys

It is fully supported by Armbian, just write Armbian image to a SD card and you are good to go.

I'm too stubborn to let it go just like that HW is capable. Maybe I will implement something like that until issue is fully explored.

This is kind of issue I got when Display Engine was misconfigured. That got me thinking. I think J. F. Moine mentioned that only video channel has capability to support such resolution. Framebuffer in BSP kernel is on the UI channel, supposedly to minimize power consumption. I need some time to extend U-Boot code for testing this hypothesis, but you could test this patch easily http://sprunge.us/bScgfor BSP kernel. According to U-Boot output, you should set 3840x2160 @ 30 Hz resolution.

Can you check if 4K mode is supported by this patch http://sprunge.us/OZdF? I would like serial output.

Christos, I will look into this next week. Igor is right, 1024@768 is a fall back resolution. For some reason, there is a communication problem with monitor. Maybe I should add more debug output to see what could be wrong. Strangely enough, it is marked as DVI. Does it have any audio output like speakers or at least 3.5 mm jack socket? Usually it is placed near other connectors. Igor, I will take a look for possible reasons why 4K resolution doesn't work. But I don't have such display. Would you be able to test it?

U-Boot now contains experimental HDMI driver, which seems to work pretty nicely, according to your report. It can set proper resolution automatically. However, BSP kernel can't do that, but it is weird that 1080p doesn't work. EDIT: just to clarify things. Are you using DVI to HDMI cable by some chance (as reported by U-Boot)? If you do, please enable CTS compatibility in script.bin.

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.

Can you please test also on 1280x1024 display? Please provide serial output of U-Boot.

Oh, sorry. I mixed up who wrote what.

So you are saying that GPLv3 is not open source license?

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 pushed possible fix for non standard resolutions and also fixed that Kconfig setting. I will now investigate Plus2E issue.

Thanks for testing! Probably framebuffer memory is reserved in wrong part of the RAM, shouldn't be hard to fix. I guess that latest U-Boot RC version has changes in Kconfig. Code in repo works as it is.

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.

Ahm, did you modprobe tv.ko? Be aware that tv out driver is compiled as a module. So you must at least add it to a list of modules to load at boot. I forgot which file that is.

I can confirm that there are only two outputs on H3, one HDMI and one TV out. I'm still not sure that there can have different outputs at the same time.

SDK is not yet available. BTW, OPi Zero Android image is uploaded to orangepi.org download page, but it seems that it is actually PC Plus image. Anyway, I don't see a point having Android on Zero (no apparent video output, unless if you solder it). Additionaly, it doesn't include wifi driver nor wifi firmware blob.

BTW, OrangePi boards have inverted Left and Right audio channels.

[disp_init] disp_mode = 1 screen1_output_type = 2 screen1_output_mode = 11 [tv_para] tv_used = 1 Mode 11 means PAL and 14 means NTSC

Flash is actually connected to SPI, which should be way faster than I2C. Also amount of it is enough only for U-Boot. I guess many of developers (me included) will pursue this way.

Yes, but only if there is BROM signature. If there is not, it should ignore that device.

I guess there is no legitimate reason left to have sunxi-gpio driver. Does anyone feel any different? Allwinner already removed it.

I'm 100% sure that arithmetic is correct. Check https://github.com/igorpecovnik/linux/blob/sun8i/drivers/pinctrl/pinctrl-sunxi.h#L23and https://github.com/igorpecovnik/linux/blob/sun8i/arch/arm/mach-sunxi/include/mach/pinctrl.h#L19 You will get busy for sure if pins are claimed by some other driver, in this case uart, if fex has "uart_used = 1" for uart2.