[dgarske]

Description

Previously the M-mode HSS replacement could only load its boot image from an SD card. This adds eMMC and SC QSPI as additional boot source options.

What it adds

• config/examples/polarfire_mpfs250_m_emmc.config - image from eMMC
• config/examples/polarfire_mpfs250_m_qspi_ddr.config - image from SC QSPI, A/B slots sized for a Linux FIT
• hal/mpfs250.c - eMMC pad selection, plus CI jobs and the docs/PolarFire.md tables
• src/sdhci.c - the first eMMC CMD1 voltage query had no retry, while the ready poll right after it retries, so a device still powering up failed the whole init. An eMMC booted only every second attempt.
• hal/hal.c - the weak hal_get_dts_address() was gated on MMU alone, so a WOLFBOOT_FDT target without MMU that relies on the weak default would not link.

Fixes that only surface once wolfBoot replaces HSS

• src/update_ram.c - the FIT block was gated on MMU, which RISC-V M-mode never defines, so a QSPI build parsed no FIT. src/update_disk.c already used MMU || WOLFBOOT_FDT; include/hal.h and hal_get_dts_address() now match it.
• hal/mpfs250.c - qspi_flash_read() did not service the watchdog, so an image larger than one watchdog window reset the chip mid-read.
• hal/mpfs250.c - the MMC reached the OS clock-gated and in soft reset, since sdhci_platform_init() is compiled only for disk builds, and the kernel's first access to it hung the bus.

Testing

Validated on an MPFS250TS Video Kit. A signed Linux FIT loads from SC QSPI into LPDDR4 in boot mode 2, and from eMMC in boot mode 1, each verifying and reaching a login prompt, with Linux bringing the eMMC up at HS200. The SD configuration was re-verified on the same hardware.