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
To avoid duplicate maintenance just include jh7110_common.rst to describe
the usage of the different boot sources.
Reviewed-by: E Shattow <e@freeshell.de>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Describe building U-Boot for the board and booting.
Carve out common information for JH7110 boards into an include.
Reviewed-by: E Shattow <e@freeshell.de>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
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>
Reviewed-by: E Shattow <e@freeshell.de>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
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>
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.
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.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>
