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

On A83T it is very easy to enable DE2. It doesn't have CCU DE register (offset 0x104). I wonder what is different with A64.

jernej

jernej

Posted
  • Author
Posted

@zador,

 

can you put somewhere legacy U-Boot with disabled display so I can download it? Can you easy create mainline u-boot with boot0? I don't have any infrastructure set up currently for such compilations.

jernej

jernej

Posted
  • Author
Posted

Great, I tried both and only on legacy U-Boot without display I managed to enable DE2. So it must be something with U-Boot or ATF. Do you know if scp is running with legacy U-Boot?

jernej

jernej

Posted
  • Author
Posted

Clocks are not the problem, I dumped values from BSP kernel and they didn't work.

 

BTW, how hard is to dump SMC registers (0x01c1e000) from legacy ATF?

zador.blood.stained

zador.blood.stained

Posted
Posted
  On 2/13/2017 at 10:31 PM, jernej said:

BTW, how hard is to dump SMC registers (0x01c1e000) from legacy ATF?

Something like this, I guess

diff --git a/arm-trusted-firmware/plat/sun50iw1p1/sunxi_security.c b/arm-trusted-firmware/plat/sun50iw1p1/sunxi_security.c
index 57e34f4..3d1ff96 100644
--- a/arm-trusted-firmware/plat/sun50iw1p1/sunxi_security.c
+++ b/arm-trusted-firmware/plat/sun50iw1p1/sunxi_security.c
@@ -37,7 +37,7 @@
 #include "sunxi_private.h"
 
 #define SPC_BASE	0x1c23400ULL
-
+#define SMC_BASE	0x1c1e000ULL
 #define SPC_DECPORT_SET_REG(p) (SPC_BASE + ((p) * 0x10) + 0x8)
 
 /*
@@ -49,6 +49,14 @@
 void sunxi_security_setup(void)
 {
 	int i;
+	uint32_t addr;
+
+	NOTICE("\nDumping SMC registers\n");
+	for (addr = SMC_BASE; addr < SMC_BASE + 0x1FF; addr += 0x10) {
+		tf_printf("%x: ", addr);
+		for (i = 0; i < 4; i++) tf_printf("%x ", mmio_read_32(addr + (i * 4)));
+		tf_printf("\n");
+	}
 
 	NOTICE("Configuring SPC Controller\n");
 
Dumping SMC registers
1c1e000: 1f0f 1 0 0
1c1e010: 0 0 ffffffff 0
1c1e020: 0 0 0 0
1c1e030: 0 0 0 0
1c1e040: 7 0 0 0
1c1e050: 0 0 0 0
1c1e060: 0 0 0 0
1c1e070: 0 0 0 0
1c1e080: 0 0 0 0
1c1e090: 0 0 0 0
1c1e0a0: 0 0 0 0
1c1e0b0: 0 0 0 0
1c1e0c0: 0 0 0 0
1c1e0d0: 0 0 0 0
1c1e0e0: 0 0 0 0
1c1e0f0: 0 0 0 0
1c1e100: 0 0 c000003f 0
1c1e110: 0 0 0 0
1c1e120: 0 0 0 0
1c1e130: 0 0 0 0
1c1e140: 0 0 0 0
1c1e150: 0 0 0 0
1c1e160: 0 0 0 0
1c1e170: 0 0 0 0
1c1e180: 0 0 0 0
1c1e190: 0 0 0 0
1c1e1a0: 0 0 0 0
1c1e1b0: 0 0 0 0
1c1e1c0: 0 0 0 0
1c1e1d0: 0 0 0 0
1c1e1e0: 0 0 0 0
1c1e1f0: 0 0 0 0

Edit: But this is relatively early during the boot process (i.e. before ARISC init), and these values look like the defaults from the datasheet

 

  Reveal hidden contents

 

jernej

jernej

Posted
  • Author
Posted

That 0xc000003f value doesn't seems to be default. Let's see if it changes something.

 

EDIT: Unfortunatelly, not.

zador.blood.stained

zador.blood.stained

Posted
Posted

Hm. With your branch I'm getting

Warning: HDMI PHY init timeout!

(kind of expected), but dumping the registers shows that DE clocks, gates and resets are not enabled and deasserted. Hm.

 

Also I noticed that A64 CCU has an extra register not present in H3, H5 and A83T datasheets - PLL Lock Control Register, and dumping it shows that "New Mode" (bit 28) is enabled in the legacy config (it is disabled by default), and legacy u-boot source has this code dealing with this bit (arch/arm/cpu/armv7/sun50iw1p1/clock.c:603), and the kernel has some weird code dealing with this bit and lock-mode = "new" is set for all PLLs in Pine64 DTs.

 

When you enabled the clocks manually (on mainline), did you check for the PLL lock bits?

 

Edit: I know that you are certain this is not related to the clocks, but for some reason Allwinner had to implement and explicitly enable this "new mode", also u-boot has this code bit:

	pll_new_mode = pll_lock_is_new_mode();

	//scp maybe has been enabled this bit already
	if(!pll_new_mode)
	{
		enable_pll_lock_bit(LOCK_EN_NEW_MODE);
	}
jernej

jernej

Posted
  • Author
Posted

Really? Using sun50i_spl32_defconfig I get following output:

 

  Reveal hidden contents

 

 

And dumping CCU reveals that clocks are configured:

 

  Reveal hidden contents

 

 

Maybe it has something to do with 32 bit mode and that ATF is not running?

 

And yes, I also tried that new mode just to be sure, but nothing changed.

jernej

jernej

Posted
  • Author
Posted

Found it!!!

 

If I put this in composer init, it works!

 

u32* syscon_reg = (u32*) 0x01c00004;

clrbits_le32(syscon_reg, 1 << 24);

1
jernej

jernej

Posted
  • Author
Posted
  On 2/16/2017 at 4:49 PM, zador.blood.stained said:

Hm. Syscon bit 24? Is it documented somewhere?  :blink:

 

Sorry, I was too excited to miss definition of syscon register. Please check above. I found it by searching for known registers which are not described in manual. What exactly that bit does it is mistery for me, but original comment for clearing 24th bit is: "set sram for vedio use, default is boot use", whatever that means.

zador.blood.stained

zador.blood.stained

Posted
Posted
  On 2/16/2017 at 4:53 PM, jernej said:

Sorry, I was too excited to miss definition of syscon register. Please check above. I found it by searching for known registers which are not described in manual. What exactly that bit does it is mistery for me, but original comment for clearing 24th bit is: "set sram for vedio use, default is boot use", whatever that means.

I woner what SRAM does it control. SRAM A2 is used for ATF in @aptitzel's mainline configuration (and also set as secure in ATF), it would be unfortunate if DE or VE uses it too.

jernej

jernej

Posted
  • Author
Posted
  On 2/16/2017 at 4:56 PM, zador.blood.stained said:

I woner what SRAM does it control. SRAM A2 is used for ATF in @aptitzel's mainline configuration (and also set as secure in ATF), it would be unfortunate if DE or VE uses it too.

 

Yesterday or day before there was discussion that ATF in SRAM is not definitive and it could (and probably it will) be moved to DRAM. Please note that also scp (arisc) firmware is located in sram. Currently I don't have time for further testing till late in the evening. Could you test if it clashes with ATF?

jernej

jernej

Posted
  • Author
Posted

Oh, that comment has probably a typo and it should be "set sram for video use, default is boot use"

zador.blood.stained

zador.blood.stained

Posted
Posted
  On 2/16/2017 at 5:04 PM, jernej said:

Oh, that comment has probably a typo and it should be "set sram for video use, default is boot use"

I've seen enough typos in legacy Allwinner code that I understood what "vedio" means quickly  :)

 

  On 2/16/2017 at 5:02 PM, jernej said:

Yesterday or day before there was discussion that ATF in SRAM is not definitive and it could (and probably it will) be moved to DRAM. Please note that also scp (arisc) firmware is located in sram.

Was it a public discussion (i.e. IRC or mailing list)? It's obvious that ATF place is not definitive but SRAM can easily be secured, can work if DRAM is not initialized, and we don't have anything for the arisc core in mainline yet.

 

 

  On 2/16/2017 at 5:02 PM, jernej said:

Currently I don't have time for further testing till late in the evening. Could you test if it clashes with ATF?

No idea how to definitively test this, IMO it's better to add to "Problems to Allwinner" Wiki list

jernej

jernej

Posted
  • Author
Posted
  On 2/16/2017 at 5:09 PM, zador.blood.stained said:

Was it a public discussion (i.e. IRC or mailing list)? It's obvious that ATF place is not definitive but SRAM can easily be secured, can work if DRAM is not initialized, and we don't have anything for the arisc core in mainline yet.

 

Yes, it was IRC, just check yesterday(?) log. SRAM is useful for many things and DRAM can also be secured using SMC or something like that.

 

 

  On 2/16/2017 at 5:09 PM, zador.blood.stained said:

No idea how to definitively test this, IMO it's better to add to "Problems to Allwinner" Wiki list

 

I mean just build standard 64 bit version which is used for Armbian with ATF and mainline kernel - if it boots with video or not.

jernej

jernej

Posted
  • Author
Posted
  On 2/16/2017 at 5:26 PM, zador.blood.stained said:

Is the "sunxi: power: add AXP803 support" patch required for HDMI PHY powering by any chance? I dropped it when I was rebasing the changes for simplicity.

 

That explains. Yes, because HDMI VCC is not powered by default. However, you can also pick ATF patch from apritzel or MoeIcenowy ATF repo which does the same thing. Please note that you should not take both patches or ATF won't boot properly.

zador.blood.stained

zador.blood.stained

Posted
Posted
  On 2/16/2017 at 7:54 PM, jernej said:

That explains. Yes, because HDMI VCC is not powered by default. However, you can also pick ATF patch from apritzel or MoeIcenowy ATF repo which does the same thing. Please note that you should not take both patches or ATF won't boot properly.

I'll probably switch to allwinner-stable ATF branch which includes the necessary patch next time I get to testing and updating Pine64 related stuff. Meanwhile you can rebase and squash your HDMI patches so it's easier to use them later.

zador.blood.stained

zador.blood.stained

Posted
Posted
  On 2/16/2017 at 8:17 PM, jernej said:

Which version should I take for rebase? Latest mainline?

@apritzel's sunxi64-beta branch may be a good choice since you can adjust it for the H5/PC2 right away, though some minor fixes to the build process are required. But I mostly meant squashing A64 support,TV support and fixes into the main patches to have one patch for the clocks, one for the actual driver and one for the defconfigs.

jernej

jernej

Posted
  • Author
Posted

@zador,

 

can you check h3_hdmi_tv_v1 branch? I guess you have that in mind. I will think a bit how to add A64 support in (ifdef hell), but I guess that is really not that important, because code in this form won't be mainlined.

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