jernej Posted February 13, 2017 Author Posted February 13, 2017 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 Posted February 13, 2017 Author Posted February 13, 2017 @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.
zador.blood.stained Posted February 13, 2017 Posted February 13, 2017 Legacy with disabled display (for SD): u-boot-with-dtb.zip Mainline with boot0 is more tricky (needs more time), will try to make it tomorrow. 1
zador.blood.stained Posted February 13, 2017 Posted February 13, 2017 You can extract mainline with boot0 from .deb packages: http://apt.armbian.com/pool/main/l/linux-u-boot-pine64-dev/ Probably 5.20 and 5.22 should be with boot0
jernej Posted February 13, 2017 Author Posted February 13, 2017 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?
zador.blood.stained Posted February 13, 2017 Posted February 13, 2017 Do you know if scp is running with legacy U-Boot? Yes, I think it should be running in SRAM judging by boot0img command line.
zador.blood.stained Posted February 13, 2017 Posted February 13, 2017 BTW, I think that peripherals clocks setup code I linked the last time ( in /drivers/clk/...) runs even with disabled display drivers, so you may want to check display related clocks that are configured there.
jernej Posted February 13, 2017 Author Posted February 13, 2017 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 Posted February 14, 2017 Posted February 14, 2017 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 HELLO! BOOT0 is starting! boot0 commit : 045061a8bb2580cb3fa02e301f52a015040c158f boot0 version : 4.0.0 set pll start set pll end rtc[0] value = 0x00000000 rtc[1] value = 0x00000000 rtc[2] value = 0x00000000 rtc[3] value = 0x00000000 rtc[4] value = 0x00000000 rtc[5] value = 0x00000000 DRAM driver version: V1.1 rsb_send_initseq: rsb clk 400Khz -> 3Mhz PMU: AXP81X ddr voltage = 1500 mv DRAM Type = 3 (2:DDR2,3:DDR3,6:LPDDR2,7:LPDDR3) DRAM clk = 672 MHz DRAM zq value: 003b3bbb DRAM single rank full DQ OK DRAM size = 1024 MB DRAM init ok dram size =1024 card boot number = 0, boot0 copy = 0 card no is 0 sdcard 0 line count 4 [mmc]: mmc driver ver 2015-05-08 20:06 [mmc]: sdc0 spd mode error, 2 [mmc]: Wrong media type 0x00000000 [mmc]: ***Try SD card 0*** [mmc]: HSSDR52/SDR25 4 bit [mmc]: 50000000 Hz [mmc]: 3776 MB [mmc]: ***SD/MMC 0 init OK!!!*** sdcard 0 init ok The size of uboot is 000b8000. sum=4d35f4f8 src_sum=4d35f4f8 Succeed in loading uboot from sdmmc flash. boot0: start load other image boot0: Loading BL3-1 Loading file 0 at address 0x40000000,size 0x0000a200 success boot0: Loading scp Loading file 2 at address 0x00040000,size 0x00019a00 success set arisc reset to de-assert state Ready to disable icache. â–’ % to secend Boot. 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 NOTICE: Configuring SPC Controller NOTICE: BL3-1: v1.0(debug):e9fc343 NOTICE: BL3-1: Built : 12:35:47, Feb 14 2017 INFO: BL3-1: Initializing runtime services INFO: BL3-1: Preparing for EL3 exit to normal world INFO: BL3-1: Next image address = 0x4a000000 INFO: BL3-1: Next image spsr = 0x1d3 U-Boot 2014.07-4-pine64-g6e6f75a-dirty (Feb 14 2017 - 12:35:47) Allwinner Technology uboot commit : 6e6f75a9a53001b8629ffe2873ea2a63f28ceb9d rsb: secure monitor exist [ 0.432]pmbus: ready [ 0.435][ARISC] :arisc initialize [ 0.760][ARISC] :arisc_dvfs_cfg_vf_table: support only one vf_table [SCP] :sunxi-arisc driver begin startup 2 [SCP] :arisc_para size:1a8 [SCP] :arisc version: [v0.1.76] [SCP] :sunxi-arisc driver v1.10 is starting [ 0.887][ARISC] :sunxi-arisc driver startup succeeded [ 0.919]PMU: AXP81X [ 0.921]PMU: AXP81X found bat_vol=0, ratio=100 [ 0.928]PMU: dcdc2 1100 [ 0.931]PMU: cpux 1008 Mhz,AXI=336 Mhz PLL6=600 Mhz,AHB1=200 Mhz, APB1=100Mhz AHB2=300Mhz MBus=400Mhz device_type = 3253, onoff=1 dcdc1_vol = 3300, onoff=1 dcdc2_vol = 1100, onoff=1 dcdc6_vol = 1100, onoff=1 aldo1_vol = 2800, onoff=0 aldo2_vol = 1800, onoff=1 aldo3_vol = 3000, onoff=1 dldo1_vol = 3300, onoff=0 dldo2_vol = 3300, onoff=0 dldo3_vol = 2800, onoff=0 dldo4_vol = 3300, onoff=1 eldo1_vol = 1800, onoff=1 eldo2_vol = 1800, onoff=0 eldo3_vol = 1800, onoff=0 fldo1_vol = 1200, onoff=0 fldo2_vol = 1100, onoff=1 gpio0_vol = 3100, onoff=0 vbus not exist no battery, limit to dc run key detect fel key not configed time out key not pressed anymore 0xd DRAM: 1008 MiB fdt addr: 0x76eec500 Relocation Offset is: 35f3e000 In: serial Out: serial Err: serial gic: sec monitor mode workmode = 0,storage type = 1 [ 11.703]MMC: 0 [mmc]: mmc driver ver 2015-06-03 13:50:00 WARNING: Unimplemented Standard Service Call: 0x8000ff05 WARNING: Unimplemented Standard Service Call: 0x8000ff05 WARNING: Unimplemented Standard Service Call: 0x8000ff05 WARNING: Unimplemented Standard Service Call: 0x8000ff05 WARNING: Unimplemented Standard Service Call: 0x8000ff06 WARNING: Unimplemented Standard Service Call: 0x8000ff06 WARNING: Unimplemented Standard Service Call: 0x8000ff06 SUNXI SD/MMC: 0 [mmc]: start mmc_calibrate_delay_unit, don't access device... [mmc]: delay chain cal done, sample: 200(ps) [mmc]: media type 0x0 [mmc]: Wrong media type 0x0 [mmc]: ************Try SD card 0************ [mmc]: host caps: 0x27 [mmc]: MID 02 PSN 9c714047 [mmc]: PNM SA04G -- 0x53-41-30-34-47 [mmc]: PRV 0.4 [mmc]: MDT m-8 y-2009 [mmc]: speed mode : HSSDR52/SDR25 [mmc]: clock : 50000000 Hz [mmc]: bus_width : 4 bit [mmc]: user capacity : 3776 MB [mmc]: ************SD/MMC 0 init OK!!!************ [mmc]: erase_grp_size : 0x1WrBlk*0x200=0x200 Byte [mmc]: secure_feature : 0x0 [mmc]: secure_removal_type : 0x0 [ 11.929]sunxi flash init ok [mmc]: Has init [ 11.965]---drivers/mmc/mmc.c 2733 mmc_init ** Unable to use mmc 0:1 for loading the env ** Using default environment --------fastboot partitions-------- mbr not exist base bootcmd=run mmcbootcmd bootcmd set setargs_mmc key 1 recovery key high 12, low 10 fastboot key high 6, low 4 no misc partition is found to be run cmd=run mmcbootcmd update dtb dram start update dtb dram end WARNING: Unimplemented Standard Service Call: 0x8000ff05 WARNING: Unimplemented Standard Service Call: 0x8000ff05 WARNING: Unimplemented Standard Service Call: 0x8000ff05 WARNING: Unimplemented Standard Service Call: 0x8000ff05 serial is: ffffffffffffffffffff get Pine64 model from DRAM size and used storage DRAM >512M Pine64 model: pine64-plus no battery exist sunxi_bmp_logo_display [ 12.187]inter uboot shell Hit any key to stop autoboot: 0 sunxi#
jernej Posted February 14, 2017 Author Posted February 14, 2017 That 0xc000003f value doesn't seems to be default. Let's see if it changes something. EDIT: Unfortunatelly, not.
zador.blood.stained Posted February 15, 2017 Posted February 15, 2017 @jernej Can you push your WIP u-boot changes for A64 so it's easier to experiment with something that has the clocks setup code?
jernej Posted February 16, 2017 Author Posted February 16, 2017 Here it is: https://github.com/jernejsk/u-boot/commits/a64_hdmi_wip You will currently see only one color on the screen, which changes sometimes, but usually it is green.
zador.blood.stained Posted February 16, 2017 Posted February 16, 2017 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 Posted February 16, 2017 Author Posted February 16, 2017 Really? Using sun50i_spl32_defconfig I get following output: U-Boot SPL 2017.01-rc1-01004-g083d43b50b-dirty (Feb 16 2017 - 01:29:42)DRAM: 2048 MiBTrying to boot from FELU-Boot 2017.01-rc1-01004-g083d43b50b-dirty (Feb 16 2017 - 01:29:42 +0100) Allwinner TechnologyCPU: Allwinner A64 (SUN50I)Model: Pine64+DRAM: 2 GiBMMC: SUNXI SD/MMC: 0, SUNXI SD/MMC: 1Card did not respond to voltage select!*** Warning - MMC init failed, using default environmentHDMI connected: Setting up a 1280x800 hdmi console (overscan 0x0)hdmi enabledIn: serialOut: vgaErr: vgaNet: No ethernet found.starting USB...No controllers found=> And dumping CCU reveals that clocks are configured: => md.l 01c20000 c001c20000: 90001521 00000000 00035514 00000000 !........U......01c20010: 91007e0a 00000000 03006207 00000000 .~.......b......01c20020: 00001000 00000000 90041811 00041811 ................01c20030: 03006207 00000000 03006207 00000000 .b.......b......01c20040: 00000515 03001300 91002301 90003700 .........#...7..01c20050: 00020102 00003190 01000000 00000000 .....1..........01c20060: 00804500 00001811 00000020 00010000 .E...... .......01c20070: 00000000 00000000 00000000 00000000 ................01c20080: 00000001 00000000 8002000e 00000000 ................01c20090: 80000000 00000000 00000000 00000000 ................01c200a0: 00000000 00000000 00000000 00000000 ................01c200b0: 00000000 00000000 00000000 00000000 ................01c200c0: 00000000 00000000 00000000 00000101 ................01c200d0: 00000000 00000000 00000000 00000000 ................01c200e0: 00000000 00000000 00000000 00000000 ................01c200f0: 00000000 80100000 ccca0000 80000000 ................01c20100: 00000000 81000000 00000000 00000000 ................01c20110: 00000000 00000000 00000000 80000003 ................01c20120: 00000000 00000000 00000000 00000000 ................01c20130: 00000000 00000000 00000000 00000000 ................01c20140: 00000000 00000000 00000000 00000000 ................01c20150: 80000000 80000000 00000000 81000002 ................01c20160: 00000000 00000000 00000000 00000000 ................01c20170: 00000000 00000000 00000000 00000000 ................01c20180: 00000000 00000000 00000000 00000000 ................01c20190: 00000000 00000000 00000000 00000000 ................01c201a0: 00000000 00000000 00000000 00000000 ................01c201b0: 80000000 00000000 00000000 00000000 ................01c201c0: 00000000 00000000 00000000 00000000 ................01c201d0: 00000000 00000000 00000000 00000000 ................01c201e0: 00000000 00000000 00000000 00000000 ................01c201f0: 00000000 00000000 00000000 00000000 ................01c20200: 000000ff 000000ff 00000000 00000000 ................01c20210: 00000000 00000000 00000000 10100010 ................01c20220: 08100200 10100000 10100000 10100000 ................01c20230: 81104000 10100010 10100000 10100000 .@..............01c20240: f8100400 10100000 10100000 10010000 ................01c20250: 0a101037 00000000 00000000 00000000 7...............01c20260: 14880008 00000000 00000000 00000000 ................01c20270: 8a002000 00000000 00000000 00000000 . ..............01c20280: 00000000 00000000 00000000 00000000 ................01c20290: 00000000 00000000 00000000 00000000 ................01c202a0: 00000000 00000000 00000000 00000000 ................01c202b0: 00000000 00000000 00000000 00000000 ................01c202c0: 00804500 00001c11 00000000 00000000 .E..............01c202d0: 00000000 00000000 00010000 00000000 ................01c202e0: 00000000 00000000 00000000 00000000 ................01c202f0: 00000007 00000000 00000000 00000000 ................=> 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.
zador.blood.stained Posted February 16, 2017 Posted February 16, 2017 Hm. I used 32bit SPL + 64bit u-boot + ATF. According to the datasheet all peripherials are set as secure by default and ATF sets them as non-secure, so I'm not sure about your test results when you didn't use the ATF.
jernej Posted February 16, 2017 Author Posted February 16, 2017 Found it!!! If I put this in composer init, it works! u32* syscon_reg = (u32*) 0x01c00004; clrbits_le32(syscon_reg, 1 << 24); 1
zador.blood.stained Posted February 16, 2017 Posted February 16, 2017 clrbits_le32(syscon_reg, 1 << 24); Hm. Syscon bit 24? Is it documented somewhere?
jernej Posted February 16, 2017 Author Posted February 16, 2017 Hm. Syscon bit 24? Is it documented somewhere? 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 Posted February 16, 2017 Posted February 16, 2017 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 Posted February 16, 2017 Author Posted February 16, 2017 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 Posted February 16, 2017 Author Posted February 16, 2017 Oh, that comment has probably a typo and it should be "set sram for video use, default is boot use"
zador.blood.stained Posted February 16, 2017 Posted February 16, 2017 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 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. 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 Posted February 16, 2017 Author Posted February 16, 2017 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. 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.
zador.blood.stained Posted February 16, 2017 Posted February 16, 2017 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. Still PHY init timeout on both boards. 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.
jernej Posted February 16, 2017 Author Posted February 16, 2017 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 Posted February 16, 2017 Posted February 16, 2017 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.
jernej Posted February 16, 2017 Author Posted February 16, 2017 Which version should I take for rebase? Latest mainline?
zador.blood.stained Posted February 16, 2017 Posted February 16, 2017 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 Posted February 16, 2017 Author Posted February 16, 2017 Ok, but not today. I will report here when done. 1
jernej Posted February 18, 2017 Author Posted February 18, 2017 @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.
Recommended Posts