zynqmp: PHY init delay step and timer robustness fixes - #866
Merged
Conversation
…without MMU, avoiding libgcc 128-bit division in the test-app link
Contributor
There was a problem hiding this comment.
Pull request overview
This PR enhances the ZynqMP HAL’s board-configurable PHY init “engine” to support an explicit millisecond delay step (useful for external PHY post-reset settle times), and hardens the timer helpers used by those delays and by benchmarking/update-disk builds.
Changes:
- Add
ZYNQMP_PHY_OP_DELAYto the ZynqMP PHY init step list and execute it viahal_delay_ms(). - Make
hal_timer_ms()robust whenCNTFRQ_EL0is unset by falling back to the known ZynqMP counter frequency. - Rework
hal_get_timer_us()to avoid__uint128_t(and the__udivti3libgcc dependency) and broaden its compilation gate; add CI coverage for the new op and benchmark dependency.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
hal/zynq.h |
Adds the new PHY init op-code definition and documents its arguments. |
hal/zynq.c |
Implements delay-step execution, adds CNTFRQ_EL0==0 fallback for ms timing, and replaces 128-bit us conversion with a link-safe split divide; adjusts build gating for hal_get_timer_us(). |
.github/workflows/test-configs.yml |
Adds a CI job that exercises the full PHY init op set (including the new delay op) and the BOOT_BENCHMARK dependency path. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
danielinux
approved these changes
Aug 21, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Extends the ZynqMP PHY init engine (
WOLFBOOT_ZYNQMP_PHY_INIT) with aZYNQMP_PHY_OP_DELAYstep that inserts a millisecond delay between sequence rows. External PHYs commonly specify a post-reset ready time before MDIO access; a sequence typed at a U-Boot prompt absorbs that in console turnaround, but replayed back-to-back fromhal_initit needs an explicit delay row. Validated on a ZynqMP board with an external dual-port gigabit PHY behind a PL AXI-GPIO reset line. Since the delay routes throughhal_timer_ms(), that function also gains aCNTFRQ_EL0 == 0fallback (matchinghal_get_timer_us()) - without it, an unconfigured counter frequency makeshal_delay_ms()spin forever, since AArch64 UDIV by zero returns 0.Also makes
hal_get_timer_us()link-safe across build variants: the microsecond conversion now uses a split 64-bit divide instead of__uint128_t, which pulled libgcc's__udivti3into links that build without it (seen in a customer test-app link against this HAL), and its gate acceptsWOLFBOOT_UPDATE_DISK/BOOT_BENCHMARKin addition to the MMU/FDT path so the symbol exists in every build that can reference it. A newzynqmp_phy_delay_testCI job builds withBOOT_BENCHMARK=1and a customZYNQMP_PHY_INIT_STEPSlist exercising every op (GPIO, WR, RD, DELAY), covering both changes; the existingzynqmp_phy_testjob continues to build the default PHY init configuration unchanged. Verified with fullconfig/examples/zynqmp.configbuilds (wolfboot.bin, test-app, factory.bin) using the exact CI invocation, plus the default build.