The ahab_commit command allows the user to commit into the SECO fuses
that control the SRK key revocation information. This is used to Revoke
compromised SRK keys.
To use ahab_commit, the boot container must be built with an SRK
revocation bit mask that is not 0x0. For the SPSDK provided by NXP, this
means setting the 'srk_revoke_mask' option in the config file used to
sign the boot container. The 'ahab_commit 0x10' can then be used to commit
the SRK revocation information into the SECO fuses.
Signed-off-by: John Ripple <john.ripple@keysight.com>
The config "GIC_V3" seems to be typo, and currently "GICV3" remains
disabled. This should be removed until needed.
Fixes: 5cd4a355e0 ("board: synquacer: Add DeveloperBox 96boards EE support")
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Enable CONFIG_SPL_SYS_MMCSD_RAW_MODE and set the offset address to
boot from raw addresses instead of a FAT partition.
Signed-off-by: Daniel Schultz <d.schultz@phytec.de>
Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
Acked-by: Anshul Dalal <anshuld@ti.com>
Enable CONFIG_SPL_SYS_MMCSD_RAW_MODE and set the offset address to
boot from raw addresses instead of a FAT partition.
Signed-off-by: Daniel Schultz <d.schultz@phytec.de>
Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
Acked-by: Anshul Dalal <anshuld@ti.com>
Kunihiko Hayashi <hayashi.kunihiko@socionext.com> says:
In the qemu-sbsa configuration, the GICv3 definition is disabled due to
a typo. After fixing the typo, GICv3 is enabled, however, the GIC register
base address definitions are missing, resulting in a build failure.
This series enables GICv3 and resolves this build error.
Confirming that U-Boot successfully starts up in QEMU SBSA environment
after the fix.
Link: https://lore.kernel.org/r/20250910092327.279749-1-hayashi.kunihiko@socionext.com
The config "GIC_V3" seems to be typo, and currently "GICV3" remains
disabled. Since "GIC_V3_ITS" is enabled in qemu-sbsa, "GICV3" should
also be enabled.
Fixes: 6d722894fd ("board: emulation: Add QEMU sbsa support")
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
If GICV3 is enabled, GICD_BASE and GICR_BASE are needed at
arch/arm/cpu/armv8/start.S.
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Some of the functions in this file do not follow the normal style. Fix
this so that things are more consistent.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Add SYS_CPU automatic inclusion jh7110-u-boot.dtsi to item of config list
DEVICE_TREE_INCLUDES as starfive-visionfive2-u-boot.dtsi and rename file.
Signed-off-by: E Shattow <e@freeshell.de>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Drop visionfive2 per-board -u-boot.dtsi stubs and instead rely on
automatic inclusion of jh7110-u-boot.dtsi
Signed-off-by: E Shattow <e@freeshell.de>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Sync automatic dtsi inclusion overrides for JH7110 CPU with upstream
"riscv: dts: starfive: jh7110: bootph-pre-ram hinting needed by boot
loader" from upstream Linux conor/riscv-dt-for-next commit 8181cc2f3f21
Signed-off-by: E Shattow <e@freeshell.de>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Prune jh7110-common-u-boot.dtsi (clocks, qspi flash, eeprom, and
bootph-pre-ram hints now upstream since devicetree-rebasing v6.16).
In preparation for removal of per-dts jh7110-*-u-boot.dtsi replace include
by next dependency jh7110-u-boot.dtsi in automatic dtsi inclusion order.
Signed-off-by: E Shattow <e@freeshell.de>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
mchp_gpio_get_value() should return int instead of bool, and some casts
are needed.
Signed-off-by: Eoin Dickson <eoin.dickson@microchip.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Include the use of the process dtbo functionality added in the MPFS
system controller driver.
Signed-off-by: Jamie Gibbons <jamie.gibbons@microchip.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Include functions to use the system controller to read the device tree
overlays which supports auto update functionality.
Signed-off-by: Jamie Gibbons <jamie.gibbons@microchip.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
With the upcoming additions of new MPFS boards, separate common
documentation to allow this to be reused appropriately and avoid
duplication.
Signed-off-by: Jamie Gibbons <jamie.gibbons@microchip.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Add an alternative implementation that use Zalrsc extension only for
HART lottery and SMP locking to support SMP on cores without "Zaamo"
extension available. The Zaamo implementation is still prioritized if
both of them are available, since it takes fewer instructions.
Signed-off-by: Yao Zi <ziyao@disroot.org>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
This board supports neither Zaamo nor Zalrsc extension, thus we want to
build it without "a" specified in the ISA string passed to compiler in
case of misused A-extension instructions. With RISCV_ISA_ZAAMO and
RISCV_ISA_ZALRSC Kconfig options introduced, we must explicitly disable
both of them to achieve this.
Signed-off-by: Yao Zi <ziyao@disroot.org>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Ratified on Apr. 2024, the original RISC-V "A" extension is now split
into two separate extensions, "Zaamo" for atomic operations and "Zalrsc"
for load-reserved/store-conditional instructions.
For now, we've already seen real-world designs implement the Zalrsc
extension only[2]. As U-Boot mainly runs with only one HART, we could
easily support these designs by not using AMO instructions in the
hard-written assembly if necessary, for which this patch introduces two
new Kconfig options to indicate the availability of "Zaamo" and "Zalrsc".
Note that even with this patch, "A" extension is specified in the ISA
string passed to the compiler as long as one of "Zaamo" or "Zalrsc" is
available, since they're only recognized with a quite recent version of
GCC/Clang. The compiler usually doesn't automatically generate atomic
instructions unless the source explicitly instructs it to do so, thus
this should be safe.
Link: d94c64c63e # [1]
Link: https://lore.kernel.org/u-boot/20250729162035.209849-9-uros.stajic@htecgroup.com/ # [2]
Signed-off-by: Yao Zi <ziyao@disroot.org>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
The dev_err() is used incorrectly and we don't need the driver
to state probe success.
Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
If the u-boot.itb read from SD-card is invalid, fdt_check_header() may be
called with a NULL pointer.
This was observed on an StarFive VisionFive Lite when trying to revover the
board via UART.
Add a missing check in the starfive board code.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: E Shattow <e@freeshell.de>
Remove the fdt_high environment variable, as a value of all ones
indicates using the FDT in place. This setting is incorrect for the
current board.
Signed-off-by: Randolph Lin <randolph@andestech.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Imply OF_UPSTREAM in platform Kconfig option and adapt existing boards
to use the correct upstream devicetree paths.
Signed-off-by: Yao Zi <ziyao@disroot.org>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
It's common that UARTs are bound and probed before U-Boot relocation, in
which case the UART's pincontroller and pinconfig must be probed first.
Let's apply DM_FLAG_PRE_RELOC to the driver, allow it to bind before
relocation.
Signed-off-by: Yao Zi <ziyao@disroot.org>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
It's common that UARTs are bound and probed before U-Boot relocation,
in which case the clocks of UART and UART's pincontroller must be
registered first. Let's apply DM_FLAG_PRE_RELOC to the driver, allowing
it to bind before relocation.
Signed-off-by: Yao Zi <ziyao@disroot.org>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
For TH1520, we want clock and pinctrl drivers to bind before relocation
along with the UART which makes use of them, since upstream devicetree
specifies pinctrl properties for the UART.
This requires a large malloc pool before relocation, let's enlarge it.
Signed-off-by: Yao Zi <ziyao@disroot.org>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
The ARM64 kernel Image size with LOCKDEP enabled is now around 80 MiB, which
makes it unbootable due to "Image too large: increase CONFIG_SYS_BOOTM_LEN".
Increase the image size limit to 128 MiB to future proof the limit.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The MediaTek MT7987/MT7988 SoCs features a built-in 2.5Gb PHY
connected to GMAC1. The PHY supports 10/100/1000/2500 Mbps
full-duplex only.
The PHY requires one or two firmware files. Firmware for MT7988 has
already been added to upstream: mediatek/mt7988/i2p5ge-phy-pmb.bin.
MT7987 has two firmware files which will be add to upstream later:
i2p5ge-phy-pmb.bin and i2p5ge-phy-DSPBitTb.bin.
Environment variable can be set for firmware data loading:
mt7987_i2p5ge_load_pmb_firmware for i2p5ge-phy-pmb.bin
mt7987_i2p5ge_load_dspbit_firmware for i2p5ge-phy-DSPBitTb.bin
mt7988_i2p5ge_load_pmb_firmware for i2p5ge-phy-pmb.bin
This driver allows dedicated weak functions to be overridden by
board to provide the firmware data:
mt7987_i2p5ge_get_fw() for MT7987
mt7988_i2p5ge_get_fw() for MT7988
To enable the PHY, add the following not to device tree:
ð1 {
status = "okay";
phy-mode = "xgmii";
phy-handle = <&phy15>;
phy15: ethernet-phy@15 {
compatible = "ethernet-phy-ieee802.3-c45";
reg = <15>;
phy-mode = "xgmii";
};
};
Signed-off-by: Sky Huang <SkyLake.Huang@mediatek.com>
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
Associate PHY device with its device node specified by phy-handle
property. This makes it possible for PHY drivers to read dedicated
information to configure the PHY device.
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
It's important to return the actual firmware data size as some
firmware files may have no checksum and need the size as the only
way for firmware validation check.
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
Octo Memory Manager driver (OMM) manages:
- the muxing between 2 OSPI busses and 2 output ports.
There are 4 possible muxing configurations:
- direct mode (no multiplexing): OSPI1 output is on port 1 and OSPI2
output is on port 2
- OSPI1 and OSPI2 are multiplexed over the same output port 1
- swapped mode (no multiplexing), OSPI1 output is on port 2,
OSPI2 output is on port 1
- OSPI1 and OSPI2 are multiplexed over the same output port 2
- the split of the memory area shared between the 2 OSPI instances.
- chip select selection override.
- the time between 2 transactions in multiplexed mode.
- check firewall access.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Fix RIFSC semaphores acquisition by not returning an error when the
current CID already possess the semaphore. Also fix an incorrect mask
for the CID value in the SEMCR register.
Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com>
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
