This change is same as in commit 78aa00c38e ("sunxi: H616: dram: split
struct dram_para"), but for H6. This is needed in order to extract
common code between H6 and H616 later.
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Constify parameters for two reasons:
- Allow more compile time optimizations
- It will allow later sharing of common code with H616 (when it will be
rearranged some more)
Commit does same kind of changes as commit 457e2cd665 ("sunxi: H616:
dram: const-ify DRAM function parameters")
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
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
