E Shattow [Sun, 27 Apr 2025 06:02:52 +0000 (23:02 -0700)]
board: starfive: visionfive2: Order board detection logic to match config
Fixup previous merge resolution of this series. Intent is to ease code
readability and logic to match ordering in CONFIG_OF_LIST
- Remove "starfive/" string math
- Remove redundant local cache of calls to get_*_from_eeprom()
- Match name before EEPROM product_id in board_fit_config_name_match()
- Remove single-consumer FDTFILE_* defines
- Do not set fdtfile for visionfive-2-* when unknown model revision
Fixes: 5a0a93a76848 ("Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-riscv") Signed-off-by: E Shattow <e@freeshell.de>
Tom Rini [Fri, 25 Apr 2025 19:11:40 +0000 (13:11 -0600)]
Merge tag 'efi-2025-07-rc1-3' of https://source.denx.de/u-boot/custodians/u-boot-efi
Pull request efi-2025-07-rc1-3
Documentation:
* add documentation for the DeepComputing FML13V01
* fix typos
UEFI:
* build with HII configuration protocol
* print image load address in StartImage
Boards:
* qemu-riscv raise CONFIG_NR_DRAM_BANKS
* add support for the DeepComputing FML13V01 board via
starfive_visionfive2_defconfig
* add UNIT_TESTS to big-endian Malta boards
configs: add jh7110-deepcomputing-fml13v01 to VF2 defconfig
The DeepComputing Framework motherboard is a JH7110 device support by the
upstream kernel. Add its device-tree to the list of device-trees to be
included into the starfive_visionfive_defconfig.
Reviewed-by: Sumit Garg <sumit.garg@linaro.org> Reviewed-by: Hal Feng <hal.feng@starfivetech.com> Reviewed-by: Matthias Brugger <mbrugger@suse.com> Reviewed-by: E Shattow <e@freeshell.de> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
This series is updating STM32MP25 machine/board support:
_ update cmd_stm32key.
_ update cmd_stm32prog.
_ update STM32MP25 configs.
_ add leds and buttons support.
_ add boot_mode support (USB/PXE/MMC/NOR/NAND).
_ add bootcmd support.
_ enable MMC support.
Currently, it misses clock,reset and regulator support for STM32MP25
which will be added in a next step due to dependencies with OP-TEE.
For example, due to OP-TEE dependencies, all MMC support is ready
but not functional.
END
Series-version: 2
Series-changes: 2
- Enable DISTRO_DEFAULT and BOOTCOMMAND flags
Patrick Delaunay [Wed, 20 Mar 2024 14:51:08 +0000 (15:51 +0100)]
arm: stm32mp: add helper function stm32mp_is_closed()
Add the helper function stm32mp_is_closed() to check the "closed" state in
product life cycle, when product secrets have been provisioned into the
device, by "secure secret provisioning" tools (SSP) for example.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
arm: stm32mp: disable console for UART serial boot
For UART serial boot, the console need to be deactivated to avoid issue
with tools STM32CubeProgrammer.
This patch adds also the missing dependency for CMD_STM32PROG_SERIAL,
to allow the silent and disable console. This avoid to add is on
board level for STM32MP15 (with TARGET_ST_STM32MP15X or
TARGET_ST_STM32MP13X)
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Patrick Delaunay [Fri, 21 Oct 2022 15:37:28 +0000 (17:37 +0200)]
board: st: stm32mp2: change bootcmd for ST boards
For nor0 boot for the STMicroelectronics boards, the bootfs
is found in SD-Card = mmc0 for nor0 boot.
Introduce a new file configuration file stm32mp25_st_common.h
to manage this specific behavior for the STMicroelectronics
boards; change the boot order for nor0 boot and don't use
the default DISTRO order define in BOOT_TARGET_DEVICES:
mmc1, ubifs, mmc0, mmc2.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Signed-off-by: Patrice CHOTARD <patrice.chotard@foss.st.com>
configs: stm32mp25: add support of NAND and NOR boot
Add support of UBI boot and activate the needed
configuration for U-Boot environment in UBI volume for
NAND or in a MTD partition for NOR device, SPI Flash:
ENV_OFFSET, ENV_OFFSET_REDUND, ENV_SECT_SIZE is
aligned with the default MTD partition on NOR device
of the STMicroelectronics boards.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Use the boot instance to select the correct mmc device identifier,
this patch only to save the environment on eMMC = MMC(1) on
STMicroelectronics boards.
Set the CONFIG_SYS_MMC_ENV_DEV to -1 to select the mmc boot instance
by default.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
ARM: stm32mp: add RIFSC system bus driver for STM32MP25
This driver is checking the access rights of the different
peripherals connected to the RIFSC bus. If access is denied,
the associated device is not binded.
Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Cover-letter:
Enable OF_UPSTREAM for STM32 and STi platforms
This series is enabling OF_UPSTREAM flag for STM32 MCU's, MPU's and
STi platforms.
For some boards, some defconfig and DT update are needed to keep the
same functional level.
The major impact concerns MPU's platform with introduction of STM32
System Bus.
END
Series-version: 2
Series-changes: 2
- Replace LOG_CATEGORY UCLASS_SIMPLE_BUS by UCLASS_NOP in both
/arch/arm/mach-stm32mp/stm32mp2/rifsc.c and
/arch/arm/mach-stm32mp/stm32mp1/etzpc.c.
- Update board/st/stm32mp1/MAINTAINERS.
- Fix DSI clock ssetting.
ARM: dts: stm32: add ETZPC as a system bus for STM32MP1x boards
The STM32 System Bus is an internal bus on which devices are connected.
ETZPC is a peripheral overseeing the firewall bus that configures
and control access to the peripherals connected on it.
For more information on which peripheral is securable, please read
the STM32MP13 or STM32MP15 reference manual.
ARM: stm32mp: add ETZPC system bus driver for STM32MP1
This driver is checking the access rights of the different
peripherals connected to the ETZPC bus. If access is denied,
the associated device is not bound.
Signed-off-by: Lionel Debieve <lionel.debieve@foss.st.com> Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
DSI is the peripheral clock, while DSI_K is an internal kernel clock.
Even though they get the same register and same bit set to be gated,
resulting in the same behavior.
U-Boot DT for stm32mp157c-odyssey is richer than the kernel DT one.
None of the stm32mp157c-odyssey's contributors answered to my request
to update kernel DT and i didn't have this board to test.
The simpler is to add a dedicated stm32mp15-odyssey_defconfig with
OF_UPSTREAM flag unset.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
ARM: dts: stm32: convert stm23f7 boards to OF_UPSTREAM
Enable OF_UPSTREAM flag for STM32F7 platforms.
Use upstream device tree for DSI and LTDC nodes,
As now in upstream DT, in panel@0 node, power-supply property is
present, which is a fixed-regulator, add DM_REGULATOR_FIXED flag
for stm32f769-disco boards.
Set also DEFAULT_FDT_FILE in defconfigs and use it in stm32f746-disco.h
to indicate which FDT file to load (All STM32F7 boards are using this
file).
If something is missing, it must be added in upstream device tree
in linux kernel ("px_clk" for DSI by example).
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
E Shattow [Tue, 22 Apr 2025 06:49:17 +0000 (23:49 -0700)]
board: starfive: visionfive2: Order board detection logic to match config
Refactor inside-out EEPROM-checking logic to better match the board-seeking
callback and ordered list of targets from starfive_visionfive2_config since
the JH7110 OF_UPSTREAM migration.
Signed-off-by: E Shattow <e@freeshell.de> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
configs: add jh7110-deepcomputing-fml13v01 to VF2 defconfig
The DeepComputing Framework motherboard is a JH7110 device support by the
upstream kernel. Add its device-tree to the list of device-trees to be
included into the starfive_visionfive_defconfig.
Reviewed-by: Sumit Garg <sumit.garg@linaro.org> Reviewed-by: Hal Feng <hal.feng@starfivetech.com> Reviewed-by: Matthias Brugger <mbrugger@suse.com> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: E Shattow <e@freeshell.de>
Yao Zi [Wed, 16 Apr 2025 16:25:33 +0000 (16:25 +0000)]
riscv: Provide __image_copy_{start_end} symbols in linkerscript
Binman looks for __image_copy_start to determine the base address of an
entry if elf-base-sym isn't specified, which is missing in RISC-V port.
This causes binman skips RISC-V SPL entries without filling addresses
into its .binman_sym_table section.
This patch defines __image_copy_start in linkerscript of both SPL and
proper U-Boot to ensure binman_sym functions correctly with the default
binman.dtsi. The paired symbol, __image_copy_end, is introduced as well
for completeness.
Signed-off-by: Yao Zi <ziyao@disroot.org> Reviewed-by: Simon Glass <sjg@chromium.org>
Yao Zi [Wed, 16 Apr 2025 16:25:32 +0000 (16:25 +0000)]
riscv: dts: starfive: Prevent binman from relocating symbols in SPL
SPL and proper U-Boot are split into two images with default binman
configuration of StarFive VisionFive 2, thus proper U-Boot symbols
cannot be found in the SPL image. This fixes errors like
Section '/binman/spl-img': Symbol '_binman_u_boot_any_prop_size'
in entry '/binman/spl-img/mkimage/u-boot-spl/u-boot-spl-nodtb':
Entry 'u-boot-any' not found in list (u-boot-spl-nodtb,
u-boot-spl-dtb,u-boot-spl,mkimage,spl-img)
Fixes: 90602e779d3 ("riscv: dts: starfive: generate u-boot-spl.bin.normal.out") Suggested-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Yao Zi <ziyao@disroot.org>
Yao Zi [Wed, 16 Apr 2025 16:25:31 +0000 (16:25 +0000)]
riscv: dts: binman.dtsi: Switch to u-boot-nodtb entry for proper U-Boot
Switch to u-boot-nodtb entry which precisely represents a proper U-Boot
and could be matched with u_boot_any. This allows RISC-V ports that make
use of binman to be built without disabling SPL_BINMAN_UBOOT_SYMBOLS
explicitly, which is set to y by default.
Fixes: 0784510f741 ("riscv: sifive: unleashed: Switch to use binman to generate u-boot.itb") Suggested-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Yao Zi <ziyao@disroot.org> Reviewed-by: Simon Glass <sjg@chromium.org>
Yao Zi [Fri, 7 Mar 2025 13:13:41 +0000 (13:13 +0000)]
riscv: lib: Add a default implementation of board_fdt_blob_setup
It's common for S-Mode proper U-Boot to retrieve a FDT blob along with
taking control from SBI firmware. Add a weak version of
board_fdt_blob_setup to make use of it by default, avoiding copy-pasting
similar functions among boards.
Signed-off-by: Yao Zi <ziyao@disroot.org> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Recent Ubuntu versions (24.04+) disallow pip by default when
installing packages. The recommended approach is to use a virtual
environment (venv) instead.
Because of this, "make pip" is failing on such versions.
To prepare CI container migration to Ubuntu 24.04, use a venv in the
make_pip script.
Tom Rini [Tue, 15 Apr 2025 18:10:26 +0000 (12:10 -0600)]
python: Use and refer to the venv module rather than virtualenv
Using some form of sandbox with Python modules is a long standing best
practice with the language. There are a number of ways to have a Python
sandbox be created. At this point in time, it seems the Python community
is moving towards using the "venv" module provided with Python rather
than a separate tool. To match that we make the following changes:
- Refer to a "Python sandbox" rather than virtualenv in comments, etc.
- Install the python3-venv module in our container and not virtualenv.
- In our CI files, invoke "python -m venv" rather than "virtualenv".
- In documentation, tell users to install python3-venv and not
virtualenv.
Tom Rini [Thu, 24 Apr 2025 16:46:17 +0000 (10:46 -0600)]
Merge patch series "Add PCIe support for TI AM64 SoC"
Hrushikesh Salunke <h-salunke@ti.com> says:
TI's AM64 SoC has a single instance of Cadence PCIe Controller. This
series enables support for PCIe in AM64 SoC and to configure it in
Root-Complex mode of operation.
configs: am64x_evm_a53_defconfig: Enable configs for PCIe support
TI's AM64 SoC has single instance of PCIe Controller namely PCIe0 which
is Cadence PCIe Controller. To support PCIe functionality with PCIe0
instance in Root-Complex mode enable corresponding configs. Also enable
configs to support NVMe over PCIe.
pci: pcie_cdns_ti: Enable PCIe root-complex mode in AM64 SoC
TI's AM64 SoC has single instance of PCIe Controller namely PCIe0 which
is Cadence PCIe Controller. Add support to configure PCIe0 in Root-
Complex mode of operation.
Driver uses macro SZ_4G to configure inbound base address register.
The macro is used without including the header file in which it is
defined. Fix this.
Tom Rini [Thu, 24 Apr 2025 16:45:41 +0000 (10:45 -0600)]
Merge patch series "arm: mach-k3: remove some firewalls left over by ROM"
Bryan Brattlof <bb@ti.com> says:
This small series is here to remove some firewalls setup by ROM during
their boot and clean things up for Linux later on. Ideally this would be
a simple call to remove_fwl_configs() however the location of the
firewall is problematic (could potentially crash the core) when we're
currently executing from the memory region protected by the firewall.
So we need to introduce a function which allows us to disable specific
firewall regions and skip others to ensure boot stability.
arm: mach-k3: am625: remove any firewalls ROM has configured for HSRAM
ROM will configure a firewall to only allow HSRAM to be touched by the
R5 core. Any outside entity like DMA or the A53s will not have access to
this region. This can be problematic when U-Boot, running on the A53,
loads firmware that runs out of this region.
To simplify things remove the firewall here and let the remote core
firmware place a new firewall themselves if they wish for the memory
region.
arm: mach-k3: support disabling a single firewall region
During boot some firewall regions could contain the R5's code which if
we change the firewalls settings will crash the core. To get around this
issue, define a new function which allows us to specify specific regions
we want unlocked.
Add TI_COMMON_CMD_OPTIONS config options to Sitara K3 boards at
a53 stage since we rely on most of the commands implied for testing
and debugging purposes. Since all commands are now enabled by
default, remove the redundant CMD_* options in the a53 defconfigs.
Also add MMC_REG & MMC_SPEED_MODE_SET useful commands to
TI_COMMON_CMD_OPTIONS.
This patch adds am654_sdhci_set_control_reg to am654_sdhci.
This is required to fix UHS_MODE_SELECT for TI K3 boards.
If any of HIGH_SPEED_ENA, V1P8_SIGNAL_ENA, UHS_MODE_SELECT
are set, then data will be launched on the pos-edge of the
clock.
Since K3 SoCs did not meet timing requirements for High Speed
SDR mode at rising clock edge, none of these three should be
set, therefore limit UHS_MODE_SELECT to only be set for modes
above MMC_HS_52.
This fixes MMC write issue on am64x evm at mode High Speed
SDR.
High Speed enable bit switches data launch from the falling
clock edge (half cycle timing) to the rising clock edge (full
cycle timing). For all SD UHS modes, data launch must happen
at the rising clock edge, so set HIGH_SPEED_ENA for SDR12 and
SDR25 modes. For all HS modes, data launch must happen at the
falling clock edge, so do not set HIGH_SPEED_ENA for MMC_HS_52.
This patch adds MMC_HS_52 to the timing data structure.
Previously, this bus mode tap settings were not populated and
were instead populated for MMC_HS which is a different bus mode
up to 26MHz. Since we intended these settings according to the
device data sheet[0] for MMC_HS_52 up to 52MHz, populate MMC_HS
tap settings for MMC_HS_52.
While we are here, fix typo in ti,itap-del-sel-mms-hs.
Adding quirk to disable STIG mode since cadence controller has
issue for read/write using the STIG mode. STIG mode is enabled
by default since 2023.04 for small read/write(<8bytes).
Updated STIG mode reading from dev_get_driver_data by assigning
to platdata struct before read quirks variable.
The STIG mode is disabled for normal read case and enabled
for QSPI Jedec ID read/write since it requires STIG read/write.
Porting from linux implementation
https://lore.kernel.org/all/20241204063338.296959-1-niravkumar
.l.rabara@intel.com/T/
Signed-off-by: Boon Khai Ng <boon.khai.ng@altera.com> Reviewed-by: Tien Fong Chee <tien.fong.chee@altera.com>
Daniel Schultz [Tue, 15 Apr 2025 15:12:41 +0000 (08:12 -0700)]
mach-k3: common_fdt: Move carveout struct
Labels are not allowed before declarations. Move the carveout struct
at the beginning and only update 'end' at this point.
This will fix following error:
arch/arm/mach-k3/common_fdt.c: In function 'fdt_fixup_reserved':
arch/arm/mach-k3/common_fdt.c:156:2: error: a label can only be part of a statement and a declaration is not a statement
156 | struct fdt_memory carveout = {
| ^~~~~~
make[1]: *** [scripts/Makefile.build:256: arch/arm/mach-k3/common_fdt.o] Error 1
make: *** [Makefile:1919: arch/arm/mach-k3] Error 2
This makes spl_mmc_boot_mode consistent across am62x, 62a and 62p.
If MMCSD_MODE_EMMCBOOT is returned, FS boot fails since it checks for FS
on the hardware partitions, not the UDA. So to allow FS boot from EMMC,
the function should return MMCSD_MODE_FS instead which allows us to read
from FS on the UDA.
configs: set SPL_TEXT_BASE by default for k3 platforms
SPL_TEXT_BASE is used as the load address for the main domain SPL on k3
platforms.
Since the config value is the same for every board, this patch sets the
value 0x80080000 as default for all 64-bit ARCH_K3, 0x43c00000 as
default for the R5 cores and deletes the instances of SPL_TEXT_BASE in
individual defconfigs.
Signed-off-by: Anshul Dalal <anshuld@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>