[Buildroot] [PATCH v1 2/2] configs/zynqmp_zcu106_defconfig: transition to tarballs

Neal Frager nealf at xilinx.com
Wed May 11 11:06:53 UTC 2022


Hi Peter,


 > On 5/4/22 08:49, Peter Korsgaard wrote:
 >>>>>>> "Neal" == Neal Frager <neal.frager at amd.com> writes:
 >> > This patch migrates configs/zynqmp_zcu106_defconfig to tarballs  >> for TF-A, u-boot and Linux.
 >> > This patch has zero change in code running on the device.
 >> > The goal is to improve build speed and align with the zynq_xxx_defconfigs.
 >> > Signed-off-by: Neal Frager <neal.frager at amd.com>  >> Committed, thanks.
 >> Notice: I'm still seeing noisy warnings from the kernel during boot,  >> did  >> you hear back from Michal abot that?
 >> [    4.384715] zynqmp-display fd4a0000.display: vtc bridge property
 >> not present
 >> [    4.393156] ------------[ cut here ]------------
 >> [    4.397776] More than allowed devices are using the vpll_int, which is forbidden


 > This is caused by not proper psu_init which setup PLLs incorrectly.

> I just noticed a different issue, reboots from Linux are not working, as the PMU hangs with an exception accessing the TCM as the RPU is powered down by default (ENABLE_UNUSED_RPU_PWR_DWN defaults to 1).

> Resets from U-Boot works, but that is presumably because the RPU is still running there.

> Doing a build on the PMU firmware with the PM log level set to 4 I see during Linux boot:

> APU> InitFinalize
> rpu0 active->forced off
> ipi_rpu0 1->0
> tcm0b 2->0
> tcm0a 2->0
> vcu 1->0
> gpu 1->0
> ipi_rpu1 1->0

> And then when rebooting:

> [   15.705425] reboot: Restarting system
> APU> SystemShutdown(1, 2)
> Err: #1 l2$ state#2
> Error in change state for l2$
> Err: #1 ocm0 state#2
> Error in change state for ocm0
> Err: #1 ocm1 state#2
> Error in change state for ocm1
> Err: #1 ocm2 state#2
> Error in change state for ocm2
> Err: #1 ocm3 state#2
> Error in change state for ocm3
> rpu 0->1
> Received exception
> MSR: 0x200, EAR: 0xFFE00000, EDR: 0x0, ESR: 0x4C4

> This is not great :/ Are you seeing the same? On a custom board running an old 2019.1 based PMU I don't see it, but after updating the PMU I do since the exception was silently ignored before v2020.2:

> https://github.com/Xilinx/embeddedsw/commit/b2bc5ed0e63ad1abbf2a3bc28dbf3c185b7092e4

> Any ideas about how to fix this (besides using a custom pmufw with ENABLE_UNUSED_RPU_PWR_DWN turned off)?

I have duplicated your issue with my zcu106 board.  I had not tested command line rebooting until now.

My next step is to test out the petalinux 2022.1 pre-built binaries to see if the issue is there as well.

If the issue does not exist on petalinux, I will look closely at the build options to see if there is anything different from what we do with Luca's zynqmp-pmufw-builder.

We may also want to check psu_init differences between the fsbl and spl as well.

Best regards,
Neal Frager
AMD



More information about the buildroot mailing list