H2+/H3/H5/A64 Disp2 U-Boot video driver

[jernej]

This driver is only for H3 (for now), so this shouldn't be an issue. Older SoCs like A20 have separate driver. Is there any hard fact like max resolution by datasheet on which we could base the decision?

 

BTW, where is an official statement that H2+ doesn't support 4K? BSP code definetly doesn't limit it. For now, there is only one H2+ board, which has no HDMI output at all.

[Igor]

Is there any hard fact like max resolution by datasheet on which we could base the decision?

 

A20 and A31 should go 2160p at least on paper. I used to have A31 tablet with retina screen.

 

BTW, where is an official statement that H2+ doesn't support 4K? BSP code definetly doesn't limit it. For now, there is only one H2+ board, which has no HDMI output at all. 

 

I saw it only here ... but you know how Allwinner is How they can limit this?

 

[jernej]

A20 and A31 should go 2160p at least on paper. I used to have A31 tablet with retina screen.

 

Do you want to say it is 4K capable? It seems that they have HDMI 1.3, which have this limitations: http://superuser.com/a/119756However, I'm not sure what to check. Frequency? Maybe you can increase framebuffer size in U-Boot like I have done and see what happens.

 

 

I saw it only here ... but you know how Allwinner is How they can limit this?

 

 

To me, this looks like more video encoder limitation (like H264), if you check meaning at other chips.

[Igor]

Months ago I tried few things and IIRC most I got was no error regarding memory reservation, but also no picture. I guess it looks like we won't be able to extract 4k ... but that's also not so much of importance. Better 2k than 0k

[jernej]

Ok, I will try to make something next week.

[jernej]

@Igor,

here is my attempt at limiting resolution for older SoCs: http://sprunge.us/iJBBBe aware that I don't have any such hardware to test it. But because patch is small, I hope it will work.

 

I really couldn't find any HW limitation in datasheets. According to them, all SoCs should support 4K. However, if I remember correctly, they have too little memory bandwith to be capable of something more than FullHD. I think I even heard that even FullHD can be a bit much.

[Igor]

It works! 

 

There was only minor typo -> syntax error.

[jernej]

Great, but while it works, IMO it doesn't have correct concept. Proper way would be to select 1080p or lower resolution, as reported by EDID. I guess current approach will work for 99% displays, because probably all high respolution displays also support 1080p.

[zador.blood.stained]

@jernel

 

Sorry for asking rather than digging into the code, but what data exactly do you need to get from EDID to set up a custom resolution in the legacy kernel? Since u-boot now can read EDID I think it should be relatively easy to pass some numbers to the kernel command line so disp2 driver can set the same display mode as was detected by the u-boot, but what do I need exactly and what can be calculated automatically?

[jernej]

Please check this code:

https://github.com/jernejsk/linux/blob/hdmi_wip/drivers/video/sunxi/disp2/hdmi/hdmi_edid.c#L75-L193

 

Around 15 variables... This means that it would be tedious to do so and it doesn't take into account the fact that monitor can be replaced with another one. Please note that also clocks must be set properly. One way to achieve this is that they are not touched within kernel. IMO, it is better to just leave BSP kernel as it is and concentrate on the mainline.

[zador.blood.stained]

Just a note, I know that it is expected, but your HDMI driver works on H5 too after changing some #defines, so in case OPiPC2 support will be added before your HDMI driver, you can activate it for H5 devices too.

[jernej]

@zador,

 

I just added support for TV out, PAL and NTSC standard. Do you think that it is interesting enough to include in Armbian? Maybe for OPi0?

 

https://github.com/jernejsk/u-boot/tree/h3_hdmi_tv_v1

 

You have to include "CONFIG_VIDEO_COMPOSITE=y" in defconfig. PAL is selected by default and can be overriden by environment variable.

[zador.blood.stained]

I just added support for TV out, PAL and NTSC standard. Do you think that it is interesting enough to include in Armbian? Maybe for OPi0?

 

https://github.com/jernejsk/u-boot/tree/h3_hdmi_tv_v1

 

You have to include "CONFIG_VIDEO_COMPOSITE=y" in defconfig. PAL is selected by default and can be overriden by environment variable.

I'll take a look at it later. Did you test dual video output on any of the "big" boards if it can work with the current code?

I'm assuming it can't be properly enabled and disabled at runtime and there is no connected display detection.

[jernej]

I'll take a look at it later. Did you test dual video output on any of the "big" boards if it can work with the current code?

I'm assuming it can't be properly enabled and disabled at runtime and there is no connected display detection.

 

Basically I tested it only on OPi2 and there it works nicely. If HDMI screen is connected, then HDMI is used, otherwise TV out is enabled. The only possible drawback I see is that TV out detection is not implemented and it unconditionaly enables it if HDMI is not connected. This is the same behaviour as in video driver for older chips.

 

Small note, I updated the driver and simplefb node in DT for TV out must have a different name "de0-lcd1-tve0". Reason for that is that TV out has different clocks, which get disabled at shutdown - DE2, TCON1 and TVE0.

 

Now, I will try to make it work on A64.

[zador.blood.stained]

Now, I will try to make it work on A64.

"It" = HDMI out I hope? 

[jernej]

"It" = HDMI out I hope? 

 

Of course, A64 doesn't have TV out AFAIK. I meant sunxi_display2.c

[zador.blood.stained]

@jernej

So will this be correct? What TCON clocks (Edit - TCON bus clocks) should be listed for TVE - 0, 1 or both?

                simplefb_hdmi: framebuffer@0 {
                        compatible = "allwinner,simple-framebuffer",
                                     "simple-framebuffer";
                        allwinner,pipeline = "de0-lcd0-hdmi";
                        clocks = <&ccu CLK_BUS_TCON0>, <&ccu CLK_BUS_DE>,
                                 <&ccu CLK_BUS_HDMI>, <&ccu CLK_DE>,
                                 <&ccu CLK_TCON0>, <&ccu CLK_HDMI>;
                        status = "disabled";
                };

                simplefb_tv: framebuffer@1 {
                        compatible = "allwinner,simple-framebuffer",
                                     "simple-framebuffer";
                        allwinner,pipeline = "de0-lcd1-tve0";
                        clocks = <&ccu CLK_BUS_TCON0>, <&ccu CLK_BUS_DE>,
                                 <&ccu CLK_BUS_TVE>, <&ccu CLK_DE>,
                                 <&ccu CLK_TCON0>, <&ccu CLK_TVE>;
                        status = "disabled";
                };

[jernej]

simplefb_tv should have tcon1 clocks listed.

 

H3/H5 display pipeline:

     TCON0 - HDMI
    /
DE2
    \
     TCON1 - TV

DE2 has in reallity two display engines, one is a bit more capable than the other, but both can be used by any output. Yesterday I managed to get cloned output, for example. Same framebuffer (resolution dictated by HDMI) was displayed on both outputs, TV had scaled down image. But of course, also two completely separate displays are possible. Do you think that any of these two combinations is interesting for someone?

 

BTW, neither me or Icenowy managed to fix A64 version. Something weird is going on, so it will have to wait a bit.

[zador.blood.stained]

DE2 has in reallity two display engines, one is a bit more capable than the other, but both can be used by any output. Yesterday I managed to get cloned output, for example. Same framebuffer (resolution dictated by HDMI) was displayed on both outputs, TV had scaled down image. But of course, also two completely separate displays are possible. Do you think that any of these two combinations is interesting for someone?

Yes, I think that would be interesting, but the question is - does u-boot have the required framework to allow this type of configuration (if we are still talking about u-boot/simplefb driver and not future DRM one)

 

BTW, neither me or Icenowy managed to fix A64 version. Something weird is going on, so it will have to wait a bit.

Hm. I looked at it too. I'm not an expert, but I suspect that SMC/SPC may have something to do with this, or there are extra clocks, gates or resets. Also it has to be noted that legacy u-boot initializes DE2 too, so it would be interesting to see what changes if it is compiled and loaded with DE2 support disabled.

[jernej]

Yes, I think that would be interesting, but the question is - does u-boot have the required framework to allow this type of configuration (if we are still talking about u-boot/simplefb driver and not future DRM one)

 

Actually, simplefb is not part of U-Boot framework, at least not in sunxi_display2.c, so I can instantiate whatever combination and add any DT node I want. Only question remains how to signal which combination is wanted. Unfortunatelly, this driver is loaded early, so only pre-existing (stored) env variables would work. Yesterday I find a way how to instantiate "driver model" drivers without a need to be referenced in DT (currently only way towards mainlining the driver). This framework AFAIK supports multiple screens, but not simplefb. However, if UEFI is enabled, similar functionality as simplefb can be achieved trough it. And yes, I took a look at DRM driver. I guess TV out driver should be achivable in near future.

 

 

I'm not an expert, but I suspect that SMC/SPC may have something to do with this, or there are extra clocks, gates or resets. Also it has to be noted that legacy u-boot initializes DE2 too, so it would be interesting to see what changes if it is compiled and loaded with DE2 support disabled.

 

I tried to find the difference, but I couldn't. SPC seems to be disabled on legacy U-Boot, unless if I saw only non-secure version - all zeros. I played with it anyway, but I didn't have any luck. Icenowy will probably meet some Allwinner engineer which should hopefully solve the mistery.

[zador.blood.stained]

I tried to find the difference, but I couldn't. SPC seems to be disabled on legacy U-Boot, unless if I saw only non-secure version - all zeros. I played with it anyway, but I didn't have any luck. Icenowy will probably meet some Allwinner engineer which should hopefully solve the mistery.

At the same time "all zeros" may mean that non-secure access is not allowed to these registers. But since ATF has UART output support, it's not that hard to debug secure/non-secure related stuff if you have FEL boot environment ready.

[zador.blood.stained]

Also it shouldn't be "all zeros" in the SPC controller registers since at least RSB and one of SRAM are secured in @apritzel's ATF branch, so it's clearly a non-secure access problem in this case.

[jernej]

Care to elaborate what is needed to debug ATF? Do I need special build of U-Boot or ATF or both? Did you already check that? Funny is that DE2 is the only component from TCON, DE2, HDMI and TV that can be secured and it is the only which doesn't work. Maybe a coincidence, but I think it is not.

[zador.blood.stained]

Care to elaborate what is needed to debug ATF? Do I need special build of U-Boot or ATF or both? Did you already check that? Funny is that DE2 is the only component from TCON, DE2, HDMI and TV that can be secured and it is the only which doesn't work. Maybe a coincidence, but I think it is not.

This should not be an ATF issue (otherwise H5/OPi PC2 DE wouldn't work), but you can check if it is secure access related by adding some code - mmio_write_32() to enable DE2 clocks, then mmio_write_32() to DE2 registers and mmio_read_32() it back to check if it sticks, and output the result on UART (with something like NOTICE() I assume)

[zador.blood.stained]

I just compiled the legacy u-boot with display support disabled

 

 

diff --git a/include/configs/sun50iw1p1.h b/include/configs/sun50iw1p1.h
index ccbad4a..abe78cd 100644
--- a/include/configs/sun50iw1p1.h
+++ b/include/configs/sun50iw1p1.h
@@ -413,8 +413,8 @@
 #define CONFIG_ANDROID_BOOT_IMAGE      /*image is android boot image*/
 #define CONFIG_USBD_HS
 #define BOARD_LATE_INIT		      /* init the fastboot partitions */
-#define CONFIG_SUNXI_DISPLAY
-#define CONFIG_VIDEO_SUNXI_V3
+//#define CONFIG_SUNXI_DISPLAY
+//#define CONFIG_VIDEO_SUNXI_V3
 //#define CONFIG_SYS_DCACHE_OFF
 
 // Make it actually useful.

 

 

And the result is interesting - dumping memory from 0x01000000 shows only zeroes and writing to it doesn't stick, so something wrapped with these 2 #ifdef's does the proper display init magic

 

Edit: Looks like this part is responsible for the clocks: https://github.com/longsleep/u-boot-pine64/blob/pine64-hacks/drivers/video_sunxi/sunxi_v3/disp_sys_intf.c#L357-L842

 

And it's interesting that DE is referred to as "disp v3" and not "disp v2" in u-boot sources.

[jernej]

I don't have access to my HW over the weekend, but you can make following two experiments:

 

1. With disabled display on legacy U-Boot, deassert reset, enable gates and configure clocks with mw.l u-boot command and check if you can write in DE2 memory.

2. If above works, combine mainline U-Boot with legacy boot0 (SPL replacement) and see if after enabling DE2, writes in this region are possible.

[zador.blood.stained]

2. If above works, combine mainline U-Boot with legacy boot0 (SPL replacement) and see if after enabling DE2, writes in this region are possible.

Any specific reason for using the boot0? We now use @apritzel's SPL with FIT support for mainline H5 and A64 configurations.

[jernej]

I mean just for test, because it initializes hw slightly different, so it might have something which is important for DE. If it has, inspection of it's code might reveal the reason.

[zador.blood.stained]

I made some small tests and looks like the code I linked earlier is not executed at all.

In fact looks like clocks are set up here: https://github.com/longsleep/u-boot-pine64/blob/pine64-hacks/drivers/clk/clk_sun50iw1.c

And then touched again (reparented) here: https://github.com/longsleep/u-boot-pine64/blob/pine64-hacks/drivers/video/sunxi/disp2/disp/dev_disp.c#L354

 

Unfortunately I was busy with other stuff and didn't test reading/writing DE registers from ATF yet.

[jernej]

Take your time, I will try to make it work on A83T, just to see if it has similar problems. If it has, I think it should be easier to find the issue there.