Skip to content

sw_apps: zynqmp_fsbl: Mark both RPU cores as used when running in loc… - #386

Open
fr89k wants to merge 1 commit into
Xilinx:masterfrom
fr89k:bugfix/rpu1_got_disabled_in_lockstep_mode
Open

sw_apps: zynqmp_fsbl: Mark both RPU cores as used when running in loc…#386
fr89k wants to merge 1 commit into
Xilinx:masterfrom
fr89k:bugfix/rpu1_got_disabled_in_lockstep_mode

Conversation

@fr89k

@fr89k fr89k commented Aug 4, 2026

Copy link
Copy Markdown

Problem

When the FSBL loads a partition destined for the RPU in lockstep mode (XIH_PH_ATTRB_DEST_CPU_R5_L), XFsbl_MarkUsedRPUCores() only set the RPU0 usage bit in XFSBL_R5_USAGE_STATUS_REG, because the lockstep case fell through to the same handling as XIH_PH_ATTRB_DEST_CPU_R5_0.

The PMU firmware uses this register to decide which RPU cores it may power down. With ENABLE_UNUSED_RPU_PWR_DWN enabled, PmForceDownUnusableRpuCores() runs as soon as any master calls pm_init_finalize — for example the Linux ZynqMP power driver during boot. Since the RPU1 usage bit was never set, pmufw treated RPU1 as unused and released its power-island, clock, and master requirements, even though in lockstep mode both cores execute the application together. As a result, RPU1 was disabled underneath a running lockstep application.

Fix

Give XIH_PH_ATTRB_DEST_CPU_R5_L its own case in XFsbl_MarkUsedRPUCores() that sets both the RPU0 and RPU1 usage bits, so pmufw keeps both cores alive.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant