TE0820 Power consumption reduction

[engkan2kit]

Hi,

I'm using the TE0820 4CG 2gb version. I currently using linux with 1 core. Most of the BSP from the reference design is intact. I'm getting around 750mA (3.3V VIN) of current. All available PL IOs are LVCMOS 1.8 where 1.8V VCCIO is supplied also by the 3.3V via a 1.8V regulator
Here's my setup:
1. using the si5334 to generate 100Mhz for the USB3.0
2. not using the SD card and eMMC. But eMMC is enabled.
3. not using Ethernet.
4. using the qSPI for storage (initramfs)
5. dropbear is running as well as rndis and the webdfu.
6. ram speed and cpu speed are the same from board_test design file.

Is there a way to further lower the consumption? Do you have a data on actual consumption of the clock circuit referenced by the USB3.0? Because I'm planning to replace this with a lower power 100Mhz XO in my custom board and just remove the inductors of the VCC of the XO and si5334 in the module.

Thank you.

[JH]

Hi,
zynqmp has a lot of mechanism to modify power consumption. Default a lot things are activated. Reduce fore example DDR bus size(use only half of DDR) and DDR speed and check PMU firmware. Disable also all interfaces which are not use (regenerate FSBL, and linux files).
Sorry I can't help much more on this topic.

Here is a little bit documentation, which maybe also helps:
https://www.xilinx.com/support/documentation/white_papers/wp482-zu-pwr-perf.pdf
https://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdf
--> see PMU part
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841813/Zynq%2BUltraScale%2BMPSoC%2BPower%2BManagement

br
John

[engkan2kit]

Hi JH,

Thanks for your the ideas. I'm trying to reduce to 16bits the effective bandwidth of the DD4 and nothing else is changed. I also checked the TE modified FSBL source code to check if I need to change anything related to DDR4 but there was none so I rebuilt my codes and I'm now not able to boot. The booting got stuck in FSBL. This is what it looks like:
--------------------------------------------------------------------------------
QSPI 32 bit Boot Mode
FlashID=0x20 0xBB 0x20
XFSBL_ERROR_QSPI_LENGTH
Device Copy Failed
Boot Device Initialization failed 0x19
Fsbl Error Status: 0x00002019
Performing FSBL FallBack

FSBL tried to copy files from QSPI but it looks like QSPI is not working now. So I'm guessing that the DDR4 is causing this not working anymore because only the DDR4 property was changed. Is there something I need to do on the PMU FW and FSBL to make this work on the T0820-4EV/4CG or do I need to remove components in the board?

Thank you.

[JH]

Hi,
did you use clean Vitis project or did you simple update(sometime xsa update will not recognise all changes)? You should try to generate completely new Vitis workspace.
What did you change? Only bus width? Or more?
Did you run memory test over Vitis debug console? Does it work?

 I think something else was going wrong as you has changed DDR setting.

br
John



 

[engkan2kit]

Hi,

I'm just patching the fsbl from petalinux. So taking the TE mods apply it to the embeddedsw repo, generate a patch, then, add an fsbl recipe to apply the patch in petalinux project. This is working fine and I can get the si5338 related configs correctly. After setting bus width to half, I compared the changes in the Zynqmp IP and only 3 changes are there after changing the effective bus width to 16. The first 1 is the offsets, the 2nd is the property of bus-width, and the 3rd one is the psu_protection__slaves property where the the range of low DDR range was changed as well.

I'll try to setup a Vitis Workspace to do a memory test over the debug console. I had a Vitis workspace before but the flow takes to long just to generate the FSBL so I had to move it to petalinux.

Thanks.

[JH]

Hi,

I'm just patching the fsbl from petalinux.

I would not recommend this. I've heard from other customer, that FSBL from petalinux works different to FSBL from Vitis, when you add our changes as patch. Source code is the same, but maybe petalinux use other drivers or different compiler order or....

I'll try to setup a Vitis Workspace to do a memory test over the debug console. I had a Vitis workspace before but the flow takes to long just to generate the FSBL so I had to move it to petalinux.

I've some basic notes here:
https://wiki.trenz-electronic.de/display/PD/Vitis
It still not finish and Xilinx gas changed again style a little bit since I've start this documentation for Vitis, but it should help to find basic steps.

br
John

[engkan2kit]

Thanks John.

I used to use Vitis in generating the FSBL but build, compiling it is so slow and it's difficult to automate and change if we want to support different hardware.

I tried to build FSBL from Vitis just now and they have the same problem with the one I built with petalinux. It seems that I may have some other issues. I'll try to run the DRAM and MEM test applications. However I have not done this before with TE0820. Since I can't set TE0820 to JTAG mode (only SD and QSPI), do I need to flash memory test application to QSPI first?

Thanks.

[JH]

Hi,
which Vivado/Vitis version did you use?
I've test it one time on my place and it works.
I've use our 2020.2 design:
https://wiki.trenz-electronic.de/display/PD/TE0820+Test+Board
1. create the project with the selection guide and 2020.2
2. open Block Design and select the ZynqMP IP --> go to memory and change effective dram bus width to 16
3. Generate bitstream -> use console and type TE::hw_build_design -export_prebuilt
4. Start Vitis generation with our scripts: TE::sw_run_vitis -all
use the new generated Hello TE0820 boot.bin from your assembly variant and boot from SD(is faster, QSPI should also work)

br
John

[engkan2kit]

I'm having trouble using the script for 2019.2. I only have 2019.2 installed in my machine. There is an error when creating a project in vivado related to current_design_bd that the block design must be open or created when running a certain command. But it's just still creating the project.

But, anyway, I tried adding debug information in the build of FSBL (still via petalinux). This time I build with my project with the full 32-bit width.

--------------------------------------------------------------------------------
TE0820 TE_XFsbl_HookPsuInit_Custom
Configure PLL: SI5338-B
Si5338 Init Registers Write.
Si5338 Init Complete
PLL Status Register 218:0x8
USB Reset Complete
ETH Reset Complete

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
Xilinx Zynq MP First Stage Boot Loader (TE modified)
Release 2019.2   Oct  4 2021  -  13:34:51
Device Name: XCZU4EV
Reset Mode      :       System Reset
Platform: Silicon (4.0), Cluster ID 0x80000000
Running on A53-0 (64-bit) Processor, Device Name: XCZU4EV

--------------------------------------------------------------------------------
TE0820 TE_XFsbl_BoardInit_Custom

--------------------------------------------------------------------------------
Processor Initialization Done
================= In Stage 2 ============
QSPI 32 bit Boot Mode
QSPI is in Dual Parallel connection
QSPI is using 4 bit bus
FlashID=0x20 0xBB 0x20
MICRON 512M Bits
Multiboot Reg : 0x0
QSPI Reading Src 0x0, Dest FFFF0040, Length EC0
....

This has no problem. but one thing I noticed is that in the half-ram build, the TE0820 TE_XFsbl_HookPsuInit_Custom was not there. In the half-ram, it prints directly to Xilinx Zynq MP First Stage Boot Loader (TE modified).
I checked the code and it's the USE_TE_PSU_FOR_SI_INIT that causes the TE_XFsbl_HookPsuInit_Custom to be ran. Next time I'll force this to be defined from the -D flags during compilation and update you if this fixes my issues.

Thank you very much.

[JH]

Hi,

I'm having trouble using the script for 2019.2. I only have 2019.2 installed in my machine. There is an error when creating a project in vivado related to current_design_bd that the block design must be open or created when running a certain command. But it's just still creating the project.

Can you send me the log file when the scripts failed. It's in the subfolder v_log on the project delivery

This has no problem. but one thing I noticed is that in the half-ram build, the TE0820 TE_XFsbl_HookPsuInit_Custom was not there. In the half-ram, it prints directly to Xilinx Zynq MP First Stage Boot Loader (TE modified).

When you use petalinux, than you must create an patch which includes our changes. But I heard from other customers that this  makes trouble, it seems that petalinux compiler for fsbl works different than vitis/SDK one --> normally it shouldn't. You can try out to patch it, but I would recommend to use Vitis/SDK.

br
John

[engkan2kit]

Hi John,

Thank you for your response. I've attached the logs.


Yes, I've created the patch from the difference between the embeddedsw 2019.2 release and the test_board fsbl 2019.2 version. It works fine on the 32-bit width RAM. I've narrowed down the issue by adding debug messanges. It is caused by the psu_ddr_phybringup_data() in the TE_XFsbl_TPSU_MODIFIED(). The psu_ddr_phybringup_data() returns 0 which means either the DDR PLL did not lock or this statement ((Xil_In32(0xFD080030) & 0x1FFF0000) >>18) is non-zero. These 2 are the only reasons that the psu_ddr_phybringup_data will return 0.

I'll add more debug statements but this time in the psu_init.c both in the psu_init.c in the embeddedsw and the one generated by the xsa during the petalinux-config to make sure I can see which psu_init.c is being used. I can add the modified psu_init.c generated from xsa by doing a copy of this file to the work dir in a do_compile_prepend clause in the fsbl recipe. I'll update this thread on my findings once I get to test this in the hardware.

Thank you very much.

Regards,
Kit

[JH]

HI,
you try to patch petalinux or?

Did you use the correct tag of the git? Xilinx permanently change sources and they are not always compatible.
Which Git Tag Xilinx has used for 19.2:
https://support.xilinx.com/s/article/72950?language=en_US
--> scroll down to FSBL

Or use Vitis to generate fsbl and boot.bin like I do.


Regarding your script error:

Please install 2019.2.1 patch from Xilinx, this should fix this error.


br
John

[engkan2kit]

Hi John,

I patched the fsbl in my petalinux project using the release 2019.2 of embeddedsw (tag: xilinx-v2019.2). I checked the diff and only the files with the TE mods are there so it's fine. The psu_ddr_phybringup_data issue is making sense since I half the Ram on the TE0820-4EV and there might be issues in bringing it up.

I did try vitis a few days ago and it resulted in the same issue that's why I'm back to petalinux since this is more convenient for me (I don have to pass files around and all are being built with just petalinux-build).
I can't use the debugger of vitis on the TE0820 for the fsbl right since I can't boot from jtag? I can debug this quickly if I can boot from JTAG.

Thank you very much.

[JH]

Hi,

I can't use the debugger of vitis on the TE0820 for the fsbl right since I can't boot from jtag? I can debug this quickly if I can boot from JTAG.

you can.
Problem on debugging FSBL is that you must disable some optimization, otherwise you see only assembler code.
You must do this changes (point 4): https://wiki.trenz-electronic.de/display/PD/MPSoC+Debug
And you should disable xilinx PS init script on debugger configuration and enable resets --> PS init script is script version of fsbl configuration, so you didn't see what's happens when this script fails.

Next problem is that this works only up do Vivado 2018.3 (last time I could do this with our modifications), with 19.x Xilinx has extend FSBL new FSBL together with our changes will not longer fit to OCM. So you must use default fsbl and try to debug. --> This should be OK for TE0820 as long as you didn't use SI5338 for GTR CLKs.

br
John

[engkan2kit]

Hi,

I excluded the NAND, SD, SECURE, features in the FSBL builds via defines since I don't use them so it still fit in the OCM. By the way, I also tried to use the default FSBL with the debug messages and it errors with XFSBL_PSU_INIT_FAILED which I can find in the XFsbl_HookPsuInit in the default fsbl. So I guess there is something wrong with the psu_init.c after halving the data width which is why psu_ddr_phybringup_data is failing. Halving the data width should be working since the DDR4 configuration used in TE0820 is cascading.

Regards,
Kit

[JH]

The question is why it was working on my place. I've reduced effective bus width and regenerate the files. that's all. Hello World app was booting with fsbl.
br
John

[JH]

Hi, when you use petalinux, did you generate the project from scretch? XSA import will not change memory size since some versions, maybe this is your problem.

br
John

[engkan2kit]

Hi,
which Vivado/Vitis version did you use?
I've test it one time on my place and it works.
I've use our 2020.2 design:
https://wiki.trenz-electronic.de/display/PD/TE0820+Test+Board
1. create the project with the selection guide and 2020.2
2. open Block Design and select the ZynqMP IP --> go to memory and change effective dram bus width to 16
3. Generate bitstream -> use console and type TE::hw_build_design -export_prebuilt
4. Start Vitis generation with our scripts: TE::sw_run_vitis -all
use the new generated Hello TE0820 boot.bin from your assembly variant and boot from SD(is faster, QSPI should also work)

br
John

Hi John,

Sorry I got busy with other stuff so I just tried your instructions. This time I'm using a TE0820-04-3AE21FA on a TE0701-06 Carrier. I followed your instructions and use the TE scripts. I'm still using VIVADO and Vitis 2019.2.1.

It's the same. I still stuck in FSBL. Still in the "TE0820 TE_XFsbl_BoardInit_Custom". I tried both u-boot and the hello-world that were generated by the scripts.

Regards,
Kit

[engkan2kit]

Hi JH,

It was able to work with 2020.2 tools. Even with FSBL generated from petalinux 2020.2. It seems that the issue is from vivado 2019.2/2019.2.1. I tried to compare the psu_init.c in the XSAs generated by both versions of vivado and found that they both have different setting for DDR_PHY_GPR1 register.

psu_init.c from 2019.2: PSU_Mask_Write(DDR_PHY_GPR1_OFFSET, 0xFFFFFFFFU, 0x000000E0U);
vs

psu_init.c from 2020.2: PSU_Mask_Write(DDR_PHY_GPR1_OFFSET, 0xFFFFFFFFU, 0x000000E3U);


Both were configured to use 16-bit data bus width. I can't locate this register in the documentation so I don't have more details. But yeah, this might solve my problem so I will just move my project files to 2020.2.


Thank you very much for your help.

Regards,
Kit

[JH]

Hi,
good to hear that you has find an solution for you.

We didn't changed DDR setup between 19.x and 20.x so I think this must be some improvements from xilinx...

PS:Xilinx offers complete register reference here: https://www.xilinx.com/html_docs/registers/ug1087/ug1087-zynq-ultrascale-registers.html
Sometimes it helps to find out what's register configuration means (but I didn't find anything to DDR_PHY_GPR1_OFFSET on a fast check, but there a lot register for DDR_PHY, so maybe try to find something over the offset value?)

br
John