Jump to content

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

jernej

By jernej
in Advanced users - Development

 Share

Recommended Posts

jernej

jernej

Posted
  • Author
Posted

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.

Link to comment
Share on other sites
Igor

Igor

Posted
Posted
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?

 

Allwinner_H-Series_Roadmap.jpg

Link to comment
Share on other sites
jernej

jernej

Posted
  • Author
Posted

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?

 

Allwinner_H-Series_Roadmap.jpg

 

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

Link to comment
Share on other sites
Igor

Igor

Posted
Posted

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 :)

Link to comment
Share on other sites
jernej

jernej

Posted
  • Author
Posted

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

Link to comment
Share on other sites
jernej

jernej

Posted
  • Author
Posted

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.

Link to comment
Share on other sites
zador.blood.stained

zador.blood.stained

Posted
Posted

@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?

Link to comment
Share on other sites
jernej

jernej

Posted
  • Author
Posted

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.

Link to comment
Share on other sites
jernej

jernej

Posted
  • Author
Posted

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

1
Link to comment
Share on other sites
zador.blood.stained

zador.blood.stained

Posted
Posted

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.

Link to comment
Share on other sites
jernej

jernej

Posted
  • Author
Posted

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.

1
Link to comment
Share on other sites
zador.blood.stained

zador.blood.stained

Posted
Posted

@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";
                };
Link to comment
Share on other sites
jernej

jernej

Posted
  • Author
Posted

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.

Link to comment
Share on other sites
zador.blood.stained

zador.blood.stained

Posted
Posted

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.

Link to comment
Share on other sites
jernej

jernej

Posted
  • Author
Posted

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.

Link to comment
Share on other sites
zador.blood.stained

zador.blood.stained

Posted
Posted

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.

Link to comment
Share on other sites
jernej

jernej

Posted
  • Author
Posted

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.

Link to comment
Share on other sites
zador.blood.stained

zador.blood.stained

Posted
Posted

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)

Link to comment
Share on other sites
zador.blood.stained

zador.blood.stained

Posted
Posted

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.

Link to comment
Share on other sites
jernej

jernej

Posted
  • Author
Posted

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.

Link to comment
Share on other sites
zador.blood.stained

zador.blood.stained

Posted
Posted

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.

Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept