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.
Enable OF_UPSTREAM flag for STM32MP2 platforms.
Add fixed-clock ck_flexgen_08 and ck_icn_ls_mcu until STM32MP25
clock driver will be available.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
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.
Signed-off-by: Lionel Debieve <lionel.debieve@foss.st.com>
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>
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.
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
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>
Enable OF_UPSTREAM flag for STM32MP15 platforms, except for
stm32mp15-odyssey,see following patch :
"configs: stm32: introduce stm32mp15-odyssey_defconfig"
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
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>
When using CONFIG_FSL_QSPI_AHB_FULL_MAP the fsl_qspi_default_setup() sets
the BFGENCR register to use the LUT(SEQID_LUT_AHB) before the Look Up Table
is populated.
This result in a situation that after 'sf probe' command any memory
read from qspi using AHB will result in undefined behaviour (hang) untill
first 'sf read' op is executed.
Move the BFGENCR write to fsl_qspi_prepare_lut() to ensure that the setup
is consistent. AHB reads will use the default LUT(index 0) setup by previous
boot stage untill the first read op.
Signed-off-by: Pawel Kochanowski <pkochanowski@sii.pl>
The UART clocks were added around the same time some other clock
updates were happening, so converting clock-osc-24 back to osc_24
was missed on the UART clocks for imx8mm and imx8mn, so update
them here.
Fixes: b4734c9c33 ("clk: imx: Convert clock-osc-* back to osc_*")
Signed-off-by: Adam Ford <aford173@gmail.com>
Reported-by: Christoph Niedermaier <cniedermaier@dh-electronics.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
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>
To avoid duplicate maintenance just include jh7110_common.rst to describe
the usage of the different boot sources.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: E Shattow <e@freeshell.de>
Describe building U-Boot for the board and booting.
Carve out common information for JH7110 boards into an include.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: E Shattow <e@freeshell.de>
We support all JH7110 boards with starfive_visionfive2_defconfig.
The relevant device-tree is selected at runtime based on EEPROM data.
Support setting $fdtfile to the file name of the DeepComputing Framework
motherboard (FML13V01) device-tree.
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>
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>
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>
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: 90602e779d ("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>
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: 0784510f74 ("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>
The number of memory banks in QEMU is not bounded by 1.
In this example we have two banks:
qemu-system-riscv64 \
-machine virt \
-nographic \
-m 8192 \
-smp 8,sockets=2,cores=4,threads=1 \
-numa node,cpus=0-3,mem=4096 \
-numa node,cpus=4-7,mem=4096 \
-kernel u-boot
As we will see RISC-V NUMA systems using U-Boot
we should be able to emulate these.
Use the default value defined in /Kconfig as 4.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Add match N:starfive pattern to visionfive2 board. Now
starfive pattern just related to JH7110 IC.
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Add pinctrl node in device tree and update
in bananapi f3 dts.
Signed-off-by: Huan Zhou <me@per1cycle.org>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
CONFIG_OF_BOARD isn't enabled on SiFive Unleashed and Unmatched, thus
board_fdt_blob_setup is actually dead code on these platforms. Let's
remove it.
Signed-off-by: Yao Zi <ziyao@disroot.org>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
The default version should work for Starfive VisionFive 2.
Signed-off-by: Yao Zi <ziyao@disroot.org>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
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.
Note: This has been reported on [1]
[1] https://source.denx.de/u-boot/custodians/u-boot-dm/-/issues/37
Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
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.
Signed-off-by: Tom Rini <trini@konsulko.com>
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.
Signed-off-by: Hrushikesh Salunke <h-salunke@ti.com>
Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
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.
Signed-off-by: Hrushikesh Salunke <h-salunke@ti.com>
Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
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.
Fixes: 59ad548009 ("pci: Add TI K3 Cadence PCIe Controller")
Signed-off-by: Hrushikesh Salunke <h-salunke@ti.com>
Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
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.
Link: https://lore.kernel.org/r/20250414-firewalls-v1-0-89090085c08b@ti.com
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.
Signed-off-by: Bryan Brattlof <bb@ti.com>
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.
Signed-off-by: Bryan Brattlof <bb@ti.com>
