Marek Vasut [Thu, 16 Jan 2025 04:03:18 +0000 (05:03 +0100)]
net: fsl_enetc: Introduce enetc_is_ls1028a()
Introduce accurate test for LS1028A compatibility based both on
IS_ENABLED(CONFIG_ARCH_LS1028A) and PCI vendor ID. This is done
in preparation for adding ENETCv4 support, which has a different
PCI vendor ID.
Tom Rini [Sat, 18 Jan 2025 23:13:01 +0000 (17:13 -0600)]
Merge patch series "add the support of sha256_hmac and sha256_hkdf"
Philippe Reynes <philippe.reynes@softathome.com> says:
This serie adds the support of sha256_hmac and sha256_hkdf.
A first version was sent several months ago just before the
integration of mbedtls. This new version is based on mbedtls.
The first patch of this serie add the support of hkdf
using mbedtls.
Philippe Reynes [Thu, 19 Dec 2024 13:05:49 +0000 (14:05 +0100)]
lib: sha256: move common function to sha256_common.c
The function sha256_csum_wd is defined in lib/sha256.c
and in lib/mbedtls/sha256.c. To avoid duplicating this
function (and future function), we move this function
to the file lib/sha256_common.c
Reviewed-by: Raymond Mao <raymond.mao@linaro.org> Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
Philippe Reynes [Thu, 19 Dec 2024 13:05:47 +0000 (14:05 +0100)]
tools: renesas_spkgimage.h: use linux/compiler_attributes.h
The attribute __packed was defined in the file
tools/renesas_spkgimage.h but this attribute is
already defined in linux/compiler_attributes.h.
So we include <linux/compiler_attributes.h.h>
and do not define __packed.
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
Philippe Reynes [Thu, 19 Dec 2024 13:05:46 +0000 (14:05 +0100)]
tools: kwbimage.h: use linux/compiler_attributes.h
The attribute __packed was defined in the file
tools/kwbimage.h but this attribute is already
defined in linux/compiler_attributes.h. So we
include <linux/compiler_attributes.h.h> and
do not define __packed.
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
Tom Rini [Sat, 18 Jan 2025 16:46:23 +0000 (10:46 -0600)]
Merge tag 'efi-2025-04-rc1' of https://source.denx.de/u-boot/custodians/u-boot-efi
Pull request efi-2025-04-rc1
Documentation:
* Correct the defconfig name in the coolpi documentation
UEFI:
* Carve out the biggest part of the RISC-V and ARM linker scripts for EFI
binary into a common include.
* Correct the values of SizeOfCode and SizeOfInitializedData in generated
EFI binaries for RISC-V and ARM.
* Avoid gaps between sections in EFI binaries causing a failure in secure
boot.
* Makefile: let clean remove capsule_in.capsule*.efi-capsule
* Refactor some of the code used for launching EFI binaries.
Tom Rini [Sat, 21 Dec 2024 16:45:52 +0000 (10:45 -0600)]
Gitlab: Add DEFAULT_FAST_ARM64_TAG as well
Upon further consideration, we should have both DEFAULT_FAST_ARM64_TAG
and DEFAULT_ARM64_TAG values available. This will allow us to later run
a matrix of some jobs, such as sandbox, on any arm64 host and still keep
the world build to only fast arm64 hosts.
squashfs: Fix sqfs_inode_size() for xattr related SQFS_LSYMLINK_TYPE
A squashfs filesystem with extended attributes (xattrs) may have
inodes of type SQFS_LSYMLINK_TYPE. This might cause u-boot to fail to
handle the filesystem since it assumes a SYMLINK_TYPE and LSYMLINK_TYPE
inode are the same size. This is wrong, see:
https://github.com/plougher/squashfs-tools/blob/master/squashfs-tools/read_fs.c#L421
Using the mksquashfs '-no-xattrs' argument is probably best, but the
mksquashfs '-xattrs' argument is the default.
This patch fixes squashfs image handling by making sure parsing the
uncompressed inode_table (with sqfs_find_inode) succeeeds. The only change
needed is correctly determining the size of a SQFS_LSYMLINK_TYPE inode.
Signed-off-by: Norbert van Bolhuis <nvbolhuis@gmail.com>
Marek Vasut [Sun, 12 Jan 2025 22:32:38 +0000 (23:32 +0100)]
Makefile: Make sure all linker input objects exist
In case the build system builds a directory with empty Makefile,
one which does not contain any obj-y entries, the build fails to
link due to missing built-in.o .
This happens because of this part of scripts/Makefile.build
81 ifneq ($(strip $(obj-y) $(obj-m) $(obj-) $(subdir-m) $(lib-target)),)
82 builtin-target := $(obj)/built-in.o
83 endif
which does not assign builtin-target in case obj-y is empty. The
built-in target is then not built at all, and built-in.o is not
generated by this part of scripts/Makefile.build
325 ifdef builtin-target
326 quiet_cmd_link_o_target = AR $@
327 # If the list of objects to link is empty, just create an empty built-in.o
...
335 targets += $(builtin-target)
336 endif # builtin-target
This is the correct behavior.
The final link however expects the built-in.o to exist in every directory
included in the build, even in those where the aforementioned code skipped
generation of built-in.o . Make sure the built-in.o does exist for every
directory used in final link simply by doing touch on every built-in.o used
for the link, which will create empty built-in.o in case any built-in.o is
missing.
A possible alternative fix is the always define the builtin-target
and always generate built-in.o .
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Tested-by: Quentin Schulz <quentin.schulz@cherry.de>
Most R-Car Gen3 and Gen4 systems require extalr_clk very early
in the boot process. Currently the extalr_clk { bootph-all } DT
property to indicate this clock should be available early is set
in each SoC U-Boot DT extras file. Deduplicate this assignment to
new common r8a779x-rcar64-u-boot.dtsi file.
Note that R-Car Gen3 R8A77990 E3 and R8A77995 D3 and RZ R8A774C0
do not require extalr_clk early, therefore these SoCs still include
plain r8a779x-u-boot.dtsi in their U-Boot DT extras .
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Marek Vasut [Sun, 12 Jan 2025 22:47:45 +0000 (23:47 +0100)]
arm64: renesas: Rewrite u-boot-elf.srec base address if PIE for R-Car Gen3
The flash_writer tool and previous recovery tools require the SREC load
address to be 0x5000_0000 . The PIE U-Boot build sets the address to 0x0
instead, so override the address back to make u-boot-elf.srec compatible
with the recovery tools.
Tested-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The fields SizeOfCode, SizeOfInitializedData, and SizeOfUninitializedData
are define in the PE-COFF specification [1].
* SizeOfCode must match the size of all .text sections.
* SizeOfInitializedData must match the size of all .data sections.
* SizeOfUninitializedData must match the size of all .bss sections.
We only have one .text and one .data section. SizeOfCode and
SizeOfInitializedData have to be calculated as the difference between
the end and the start of the respective section.
As we don't have any .bss sections in the generated EFI binaries.
SizeOfUninitializedData must remain 0.
Ilias Apalodimas [Thu, 16 Jan 2025 11:39:05 +0000 (12:39 +0100)]
efi_loader: Fix section alignment on EFI binaries
When creating EFI binaries, the alignment of the text section isn't
correctly factored in. As a result trying to load signed EFI binaries
throws an error with:
efi_image_region_add() efi_image_region_add: new region already part of another
Image not authenticated
Running the binary through sbverify has a similar warning
sbverify ./lib/efi_loader/helloworld.efi
warning: gap in section table:
.text : 0x00001000 - 0x00001c00,
.data : 0x00002000 - 0x00002200,
gaps in the section table may result in different checksums
warning: data remaining[7680 vs 12720]: gaps between PE/COFF sections?
.....
If we include the alignment in the text section, the signed binary boots
fine, and the relevant sbverify warning goes away
sbverify ./lib/efi_loader/helloworld.efi
warning: data remaining[8704 vs 12720]: gaps between PE/COFF sections?
.....
We should look into the remaining warning at some point as well
regarding the gaps between PE/COFF sections.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Andy Yan [Mon, 13 Jan 2025 10:56:13 +0000 (18:56 +0800)]
doc: coolpi: Fix the defconfig name
The defconfig name should be: coolpi-cm5-genbook-rk3588_defconfig
Signed-off-by: Andy Yan <andyshrk@163.com> Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
- RISC-V: Add "riscv,isa-extensions" and multi-letter extension parsing
support
- RISC-V: Add default cache line size
- Board: Canaan: Add K230-CanMV support
- Board: VisionFive2: Split out target specific configuration
The function disable_thermal_cpu_nodes() corrupts the cooling-device
property.
For example, booting an i.MX93 devices with only one A55 core (IMX93x1)
with the cooling-device property set to:
[ 1.715189] OF: /thermal-zones/cpu-thermal/cooling-maps/map0: could not find phandle 1083699869
[ 1.723977] thermal_sys: Add a cooling_device property with at least one device
[ 1.731285] thermal thermal_zone0: binding zone cpu-thermal with cdev thermal-devfreq-0 failed:-2
because the cooling-device property in the device tree passed to the
kernel is
The issue is because the wrong variable type is passed to the function
fdt_setprop() called in the function disable_thermal_cpu_nodes(). With
the variable type fixed, the error at boot is gone and the property is
properly set:
Capricorn boards have WDT (WDT_SIEMENS_PMIC) and U-Boot is not configured
to trigger the WDT. Enable the "wdt" command to be able to stop the WDT
from the command line.
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Reviewed-by: Heiko Schocher <hs@denx.de>
Yannic Moog [Fri, 10 Jan 2025 12:35:38 +0000 (13:35 +0100)]
doc: phytec: imx8mm: add OP-TEE documentation
Add instructions on how to build and package OP-TEE for the
phycore-imx8mm based boards. The build instructions are identical for
phyGATE-Tauri-L and phyBOARD-Polis.
Also fix missig '-' for TF-A build instructions.
Yannic Moog [Fri, 10 Jan 2025 12:35:33 +0000 (13:35 +0100)]
arm: imx8m: add OP-TEE node
Add tee node in SoC u-boot device trees. Use a kconfig entry to specify
load and entry addresses for the op-tee image in the respective
defconfig.
Default IMX8M_OPTEE_LOAD_ADDR is supplied. To keep it simple, the same
addresses are used for each SoC as are defined in upstream tf-a
(BL32_BASE) [1].
Peng Fan [Thu, 9 Jan 2025 03:29:18 +0000 (11:29 +0800)]
gpio: adp5585: Update compatible string
i.MX93-11x11-EVK has switched to use upstream device tree, and use
"adi,adp5585". Since i.MX93-11x11-EVK is the only user of this driver,
so it is safe to drop "adp5585".
Junhui Liu [Tue, 14 Jan 2025 16:46:40 +0000 (00:46 +0800)]
riscv: canaan: k230_canmv: Add initial support
Add support for K230 CanMV board with serial console and usb otg
support. It can boot via vendor's u-boot-spl and boot into Linux
via tftp through the onboard RTL8152.
Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Junhui Liu [Tue, 14 Jan 2025 16:46:38 +0000 (00:46 +0800)]
riscv: dts: canaan: Add basic device tree for K230 CanMV board
Add initial dts for K230-CanMV powered by Canaan Kendryte K230 SoC,
which has two RISC-V C908 cores, a big core with vector 1.0 extension
and a small core without vector extension.
This patch is basically comes from Linux Kernel [1] and it assumes
u-boot is running on the big core. Additionally, bootctl and reboot nodes
are added to support sysreset [2] and an clk_dummy node is added to
satisfy dependencies for usb [3].
Currently, u-boot is booted by the vendor's u-boot-spl. To meet the
requirements [4][5] of vendor's u-boot-spl for u-boot, a binman node with
mkimage child node is added here, which will compress u-boot.bin with
gzip and generate an image named "uboot" in the file u-boot-gz.img.
The RISC-V ISA profile RVA23U64 requires extension Zic64b (Cache blocks
must be 64 bytes in size, naturally aligned in the address space).
Some RISC-V platforms do not define the d-cache line size through SYS_CACHE_SHIFT_n.
Set a default value of 64 bytes for such cases.
Signed-off-by: Yu-Chien Peter Lin <peter.lin@sifive.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Update the cpu probing to fallback to "riscv,isa" property if
"riscv,isa-extensions" is not available and modify the riscv CMO code
to use the block size that was probed during cpu setup.
Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Enhance the existing extension probing mechanism by adding support for
more extensions and probing using the "riscv,isa" property. This patch
is ported from the latest upstream linux.
Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
E Shattow [Wed, 1 Jan 2025 06:35:57 +0000 (22:35 -0800)]
riscv: dts: starfive: split out visionfive2 target specific configuration
Split out StarFive VisionFive2 multi-board target specific configuration
into starfive-visionfive2-binman.dtsi in preparation for removal of
jh7110-u-boot and jh7110-common-u-boot in part or whole as sent upstream.
Signed-off-by: E Shattow <e@freeshell.de> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Tom Rini [Wed, 15 Jan 2025 23:34:26 +0000 (17:34 -0600)]
Merge patch series "bootstd: Support recording images"
Simon Glass <sjg@chromium.org> says:
This series provides a way to keep track of the images used in bootstd,
including the type of each image.
At present this is sort-of handled by struct bootflow but in quite an
ad-hoc way. The structure has become quite large and is hard to query.
Future work will be able to reduce its size.
Ultimately the 'bootflow info' command may change to also show images as
a list, but that is left for later, as this series is already fairly
long. So for now, just introduce the concept and adjust bootstd to use
it, with a simple command to list the images.
This series includes various alist enhancements, to make use of this new
data structure a little easier.
[trini: Drop patch 18 and 19 for now due to size considerations]
Simon Glass [Fri, 15 Nov 2024 23:19:13 +0000 (16:19 -0700)]
bootstd: Maintain a list of images
We want to keep track of images which are loaded, or those which could
perhaps be loaded. This will make it easier to manage memory allocation,
as well as permit removal of the EFI set_efi_bootdev() feature.
Add a list of these, attached to the bootflow. For now the list is
empty.
Simon Glass [Fri, 15 Nov 2024 23:19:12 +0000 (16:19 -0700)]
bootstd: Move the bootflow list into an alist
Use an alist for this data structure as it is somewhat simpler to
manage. This means that bootstd holds a simple list of bootflow structs
and can drop it at will, without chasing down lists.
Simon Glass [Fri, 15 Nov 2024 23:19:11 +0000 (16:19 -0700)]
bootstd: Drop the bootdev-specific list of bootflows
This list is only used by two functions, which can be updated to iterate
through the global list. Take this approach, which allows the bootdev
list to be dropped.
Overall this makes the code slightly more complicated, but will allow
moving the bootflow list into an alist
Aparna Patra [Wed, 8 Jan 2025 04:49:39 +0000 (10:19 +0530)]
arm: mach-k3: am62p: Set a53 cpu freq based on speed-grade
The maximum frequency of the A53 CPU on the AM62P depends on the speed
grade of the SoC. This value is hardcoded in the DT for all AM62P
variants, potentially causing specifications to be exceeded. Moreover,
setting a common lower frequency for all variants increases boot time.
To prevent these issues, modify the DT at runtime from the R5 core to
adjust the A53 CPU frequency.
Aparna Patra [Wed, 8 Jan 2025 04:49:38 +0000 (10:19 +0530)]
arm: mach-k3: am62p: Fixup a53 max cpu frequency by speed-grade
AM62P SoC has multiple speed grades. Add function to delete
non-relevant CPU frequency nodes, based on the information
retrieved from hardware registers. Fastest grade's maximum
frequency also depends on PMIC voltage, hence to simplify
implementation use the smaller value.
Aparna Patra [Wed, 8 Jan 2025 04:49:37 +0000 (10:19 +0530)]
arm: mach-k3: am62p: Fixup thermal zone critical points
Read the max temperature for the SoC temperature grade from the hardware
and modify the critical trip nodes on each thermal zone of FDT at
runtime so they are correct with the hardware value for its grade.
Aparna Patra [Wed, 8 Jan 2025 04:49:36 +0000 (10:19 +0530)]
arm: mach-k3: am62p: Fixup CPU core, CAN-FD and Video-codec nodes in fdt
AM62P SOC is available in multiple variants:
-CPU cores (Cortex-A) AM62Px1 (1 core),
AM62Px2 (2 cores), AM62Px4 (4 cores)
-With and without CAN-FD & Video-codec support
Remove the relevant FDT nodes by reading the actual configuration
from the SoC registers, with that change it is possible to have a single
dts/dtb file handling the different variant at runtime.
board: ti: Pull redundant DDR functions to a common location and Fixup DDR size when ECC is enabled
As there are few redundant functions in board/ti/*/evm.c files, pull
them to a common location of access to reuse and include the common file
to access the functions.
Call k3-ddrss driver through fixup_ddr_driver_for_ecc() to fixup the
device tree and resize the available amount of DDR, if ECC is enabled.
Otherwise, fixup the device tree using the regular
fdt_fixup_memory_banks().
Also call dram_init_banksize() after every call to
fixup_ddr_driver_for_ecc() is made so that gd->bd is populated
correctly.
Ensure that fixup_ddr_driver_for_ecc() is agnostic to the number of DDR
controllers present.
Signed-off-by: Santhosh Kumar K <s-k6@ti.com> Signed-off-by: Neha Malcom Francis <n-francis@ti.com> Reviewed-by: Wadim Egorov <w.egorov@phytec.de>
The functionality of enabling Inline ECC is now controlled by
CONFIG_K3_INLINE_ECC. So, remove the support for 'ti,ecc-enable'
property to avoid redundancy and to ensure the Inline ECC feature is
mananged through build-time config.
Signed-off-by: Santhosh Kumar K <s-k6@ti.com> Reviewed-by: Wadim Egorov <w.egorov@phytec.de>
Setup the ECC region's start and range using the device private data,
ddrss->ddr_bank_base[0] and ddrss->ddr_ram_size. Also, move start and
range of ECC regions from 32 bits to 64 bits to accommodate for
DDR greater than or equal to 4GB.
ram: k3-ddrss: Add k3_ddrss_ddr_bank_base_size_calc() to solve 'calculations restricted to 32 bits' issue
As R5 is a 32 bit processor, the RAM banks' base and size calculation
is restricted to 32 bits, which results in wrong values if bank's base
is greater than 32 bits or bank's size is greater than or equal to 4GB.
So, add k3_ddrss_ddr_bank_base_size_calc() to get the base address and
size of RAM's banks from the device tree memory node, and store in a
64 bit device private data which can be used for ECC reserved memory
calculation, Setting ECC range and Fixing up bank size in device tree
when ECC is enabled.
Signed-off-by: Santhosh Kumar K <s-k6@ti.com> Reviewed-by: Wadim Egorov <w.egorov@phytec.de>
Georgi Vlaev [Mon, 6 Jan 2025 09:07:01 +0000 (14:37 +0530)]
ram: k3-ddrss: Use the DDR controller BIST engine for ECC priming
The 1-bit inline ECC support in TI's DDRSS bridge requires
the configured memory regions to be preloaded with a pattern
before use. This is done by the k3-ddrss driver from the
R5 SPL in a 'for' loop. It takes around 10 seconds to fill
2GB of memory, for example. Memset can cut the time in half
and using DMA currently yields a similar result.
The BIST engine of DDR controller provides support for
initializing any memory region with a pattern. This
bypasses the DDRSS bridge, so the required inline ECC
data is not computed and populated in the memory. For
some values like zero, the computed ECC syndrome is also
zero and we can use these values to preload the memory
from the DDR controller, without the assistance of the
bridge.
The registers involved in the process are described in the
'DDR controller registers' topic in [1] AM62 and [2] J721E
reference manuals.
The patch replaces the 'for' loop memory fill function with
the BIST memory initialization procedure. This cuts the time
to preload the 2GB memory from 10 seconds down to 1 second.
The bist preload function uses the lpddr4 APIs in the k3-ddrss,
so this is compatible with devices with both 16-bit LPDDR4 and
32-bit LPDDR4 interfaces (e.g J721E).
The first patch modifies the function documentation style in the
include/fdt_support.h file to comply with kernel-doc requirements.
The second patch modifies the board_fdt_chosen_bootargs() function to
return a const char* type. This change clarifies to the caller that the
returned string should neither be freed nor modified. It aligns with the
existing fdt_setprop() function, which already utilizes a const char*
parameter. This promotes consistency within the codebase and enhances
code safety by preventing unintended modifications to the returned
string.
The third patch addresses the need for flexibility in providing kernel
command line arguments (bootargs) for different kernel images within the
same U-Boot environment. It introduces a read-only (RO) fdt_property
argument to the board_fdt_chosen_bootargs() function, allowing access to
the original chosen/bootargs data. This is crucial for scenarios where
different kernel versions require distinct console setups (e.g., ttyS0
for vendor kernels and ttyAML0 for upstream kernels). By enabling board
developers to either merge or replace the original bootargs, this
patch enhances the configurability of U-Boot for various kernel
images without relying on outdated configurations like CMDLINE_EXTEND.
Dmitry Rokosov [Thu, 19 Dec 2024 21:42:10 +0000 (00:42 +0300)]
common: fdt: hand over original fdt bootargs into board chosen handler
Sometimes, it is necessary to provide an additional bootargs string to
the kernel command line.
We have a real scenario where one U-Boot blob needs to boot several
kernel images: the vendor-patched kernel image and the latest upstream
kernel image. The Amlogic (Meson architecture) tty driver has different
tty suffixes in these kernels: the vendor uses 'ttySx', while the
upstream implementation uses 'ttyAMLx'. The initial console setup is
provided to the kernel using the kernel command line (bootargs). For the
vendor kernel, we should use 'console=ttyS0,115200', while for the
upstream kernel, it must be 'console=ttyAML0,115200'. This means we have
to use different command line strings depending on the kernel version.
To resolve this issue, we cannot use the CMDLINE_EXTEND kernel
configuration because it is considered legacy and is not supported for
the arm64 architecture. CMDLINE_EXTEND is outdated primarily because we
can provide additional command line strings through the
'chosen/bootargs' FDT node. However, U-Boot uses this node to inject the
U-Boot bootargs environment variable content, which results in U-Boot
silently overriding all data in the 'chosen/bootargs' node. While we do
have the board_fdt_chosen_bootargs() board hook to address such issues,
this function lacks any FDT context, such as the original value of the
'chosen/bootargs' node.
This patch introduces a read-only (RO) fdt_property argument to
board_fdt_chosen_bootargs() to share the original 'chosen/bootargs' data
with the board code. Consequently, the board developer can decide how to
handle this information for their board setup: whether to drop it or
merge it with the bootargs environment.
Dmitry Rokosov [Thu, 19 Dec 2024 21:42:09 +0000 (00:42 +0300)]
fdt_support: board_fdt_chosen_bootargs() should return const char*
It should be structured this way to demonstrate to the caller that
freeing the return value is unnecessary and that the caller cannot
modify it.
The function fdt_setprop() includes a parameter with a const char*
prototype, so it is better to use the const qualifier.
Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
projects / thirdparty / u-boot.git / log
