Add optional ZynqMP PHY init over GEM MDIO

[dgarske]

Adds an opt-in feature (WOLFBOOT_ZYNQMP_PHY_INIT, off by default) that replays a board's U-Boot Ethernet PHY init over the GEM MDIO management interface during hal_init(), so a PHY that U-Boot used to bring up is left in the expected state when wolfBoot replaces U-Boot. It drives only the MDIO management plane (wolfBoot has no network stack) via a small table-driven sequence; the default targets the ZCU102 on-board PHY (TI DP83867 at address 0x0C on GEM3, 0xFF0E0000) and does a diagnostic PHY-ID read. A board supplies its own sequence by keeping its values in a small header selected with one line (CFLAGS_EXTRA+=-DZYNQMP_PHY_INIT_HEADER='"myboard_phy.h"'), where that header #defines any of ZYNQMP_GEM_BASE, ZYNQMP_PHY_ADDR, ZYNQMP_PHY_GPIO_ADDR, ZYNQMP_GEM_MDC_DIV, and the {op, arg0, arg1} step array ZYNQMP_PHY_INIT_STEPS, with anything omitted falling back to the ZCU102 defaults (scalars can also be set directly with -D). Where the PHY sits behind the PL, the boot image must include the FPGA bitstream so the FSBL loads it first, otherwise the transactions are no-ops. Verified on ZynqMP hardware, and hal/zynq.o builds clean with the feature enabled on both the default and header-override paths.

[Copilot]

Pull request overview

Adds an opt-in mechanism for ZynqMP targets to perform early Ethernet PHY register initialization via the Cadence GEM MDIO management interface, allowing wolfBoot to replace the “U-Boot pre-init” role on boards that require it before the OS starts.

Changes:

• Introduces a configurable PHY init step table and minimal GEM MDIO read/write helpers, executed from hal_init() when enabled.
• Documents the feature and adds commented enablement/override examples in ZynqMP config templates.
• Extends CI reusable workflow inputs to allow passing extra CFLAGS, and adds a build job that compiles with the PHY-init flag enabled.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
hal/zynq.h	Adds GEM MDIO/PHY-init configuration macros and default step sequence behind WOLFBOOT_ZYNQMP_PHY_INIT.
hal/zynq.c	Implements the minimal MDIO engine and runs the configurable init sequence during hal_init().
docs/Targets.md	Documents how to enable/configure the optional ZynqMP PHY init feature.
config/examples/zynqmp.config	Adds commented example flags/overrides for enabling PHY init.
config/examples/zynqmp_sdcard.config	Adds commented example flags/overrides for enabling PHY init (sdcard config).
.github/workflows/test-configs.yml	Adds a CI job that builds ZynqMP with WOLFBOOT_ZYNQMP_PHY_INIT enabled.
.github/workflows/test-build-aarch64.yml	Adds an extra-cflags input and appends it into .config during CI builds.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (3)

hal/zynq.c:2132

• The init-step table uses a 16-bit arg1, but ZYNQMP_PHY_OP_GPIO writes arg1 to a 32-bit MMIO register. This truncates any board-provided 32-bit GPIO/PL value and can silently misconfigure the PL-side control register. Use a 32-bit field for arg1 so GPIO writes can carry full register values (MDIO writes can still pass 16-bit values).

    static const struct {
        uint8_t  op;
        uint8_t  arg0;
        uint16_t arg1;
    } steps[] = { ZYNQMP_PHY_INIT_STEPS };

.github/workflows/test-configs.yml:783

• This job sets CFLAGS_EXTRA via make-args using =, which overrides the CFLAGS_EXTRA+=... settings already present in config/examples/zynqmp.config (e.g., DEBUG_ZYNQ and SHA block size). Use += here so the CI build enables the PHY init on top of the config instead of replacing the config's extra flags.

    with:
      arch: aarch64
      config-file: ./config/examples/zynqmp.config
      make-args: CFLAGS_EXTRA=-DWOLFBOOT_ZYNQMP_PHY_INIT

.github/workflows/test-build-aarch64.yml:100

• EXTRA_CFLAGS is referenced here but this reusable workflow does not define an input or env source for it, and callers of uses: workflows cannot reliably pass job-level env. As written, this block is effectively dead and can mislead future changes. Either add a dedicated workflow_call input for extra CFLAGS (and plumb it through), or remove this block and rely on make-args (preferably using CFLAGS_EXTRA+=... when appending).

          cp ${{inputs.config-file}} .config
          if [ -n "$EXTRA_CFLAGS" ]; then
            printf 'CFLAGS_EXTRA+=%s\n' "$EXTRA_CFLAGS" >> .config
          fi