Ilias Apalodimas <ilias.apalodimas@linaro.org> says:
Instructions that lead ito an exception in the hypervisor can't modify two
CPU registers at once for the ARM ISA.
These instructions cannot be emulated by KVM as they do not produce
syndrome information data that KVM can use to infer the destination
register, the faulting address, whether it was a load or store, or
if it's a 32 or 64 bit general-purpose register.
As a result an external abort is injected from QEMU, via ext_dabt_pending.
Link: https://lore.kernel.org/r/20250618065828.1312146-1-ilias.apalodimas@linaro.org
A following patch is replacing our IO accessors with
do { ... } while(0) ones in order to make them usable with KVM.
That leads to an error eventually looking like this:
arch/arm/include/asm/io.h:62:9: error: expected expression before 'do'
62 | do { \
| ^~
arch/arm/include/asm/io.h:211:41: note: in expansion of macro '__raw_writel'
211 | #define out_arch(type,endian,a,v) __raw_write##type(cpu_to_##endian(v),a)
| ^~~~~~~~~~~
arch/arm/include/asm/io.h:223:25: note: in expansion of macro 'out_arch'
223 | #define out_be32(a,v) out_arch(l,be32,a,v)
| ^~~~~~~~
drivers/spi/fsl_dspi.c:127:17: note: in expansion of macro 'out_be32'
127 | out_be32(addr, val) : out_le32(addr, val);
| ^~~~~~~~
So adjust the current macros and code to be compatible with the upcoming
change.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Heinrich Schuchardt <heinrich.schuchardt@canonical.com> says:
To implement the EFI_SYSTEM_TABLE_POINTER we need 4 MiB aligned
memory.
On the sandbox LMB uses addresses relative to the start of a page aligned
RAM buffer allocated with mmap(). This leads to a mismatch of alignment
between EFI which uses pointers and LMB which uses phys_addr_t.
Ensure that the RAM buffer used for LMB is 4 MiB aligned.
Provide a unit test for efi_alloc_aligned_pages() verifying this alignment.
Do not overwrite RAM size in dram_init().
Link: https://lore.kernel.org/r/20250608075428.32631-1-heinrich.schuchardt@canonical.com
To implement the EFI_SYSTEM_TABLE_POINTER we need 4 MiB aligned
memory.
On the sandbox LMB uses addresses relative to the start of a page aligned
RAM buffer allocated with mmap(). This leads to a mismatch of alignment
between EFI which uses pointers and LMB which uses phys_addr_t.
Ensure that the RAM buffer used for LMB is 4 MiB aligned.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Sughosh Ganu <sughosh.ganu@linaro.org> says:
The LMB module has a bunch for API's which are used for allocating
memory. There are a couple of API's for requesting memory, and two
more for reserving regions of memory. Replace these different API's
with a single one, lmb_alloc_mem(). The type of allocation to be made
is specified through one of the parameters to the function.
Additionally, the two API's for reserving regions of memory,
lmb_reserve() and lmb_alloc_addr() are the same with one
difference. One can reserve any memory region with lmb_reserve(),
while lmb_alloc_addr() actually checks that the memory region being
requested is part of the LMB memory map. Reserving memory that is not
part of the LMB memory map is pretty futile -- the allocation
functions do not allocate memory which has not been added to the LMB
memory map.
This series also removes the functionality allowing for reserving
memory regions outside the LMB memory map. Any request for reserving a
region of memory outside the LMB memory map now returns an -EINVAL
error.
Certain places in the common code using the LMB API's were not
checking the return value of the functions. Checks have been added for
them. There are some calls being made from the architecture/platform
specific code which too do not check the return value. Those have been
kept the same, as I do not have the platform with me to check if it
causes any issues on those platforms.
In addition, there is a patch which refactors code in
lmb_overlaps_region() and lmb_can_reserve_region() so that both
functionalities can be put in a single function, lmb_overlap_checks().
Finally, a new patch has been added which checks the return value of
the lmb allocation function before copying the device-tree to the
allocated address.
Link: https://lore.kernel.org/r/20250617104346.1379981-1-sughosh.ganu@linaro.org
[trini: Rework arch/arm/mach-snapdragon/board.c merge]
Signed-off-by: Tom Rini <trini@konsulko.com>
There is no need to have two separate API's for freeing up memory. Use
a single API lmb_free() to achieve this.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
There currently are two API's for requesting memory from the LMB
module, lmb_alloc() and lmb_alloc_base(). The function which does the
actual allocation is the same. Use the earlier introduced API
lmb_alloc_mem() for both types of allocation requests.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
There currently are multiple allocation API's in the LMB module. There
are a couple of API's for allocating memory(lmb_alloc() and
lmb_alloc_base()), and then there are two for requesting a reservation
for a particular memory region (lmb_reserve() and
lmb_alloc_addr()). Introduce a single API lmb_alloc_mem() which will
cater to all types of allocation requests and replace lmb_reserve()
and lmb_alloc_addr() with the new API.
Moreover, the lmb_reserve() API is pretty similar to the
lmb_alloc_addr() API, with the one difference being that the
lmb_reserve() API allows for reserving any address passed to it --
the address need not be part of the LMB memory map. The
lmb_alloc_addr() does check that the address being requested is
actually part of the LMB memory map.
There is no need to support reserving memory regions which are outside
the LMB memory map. Remove the lmb_reserve() API functionality and use
the functionality provided by lmb_alloc_addr() instead. The
lmb_alloc_addr() will check if the requested address is part of the
LMB memory map and return an error if not.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
The symbol TOOLS_IMAGE_PRE_LOAD doesn't depend on TOOLS_LIBCRYPTO.
If we choose to build tools without openssl, rsa_verify_openssl()
will attempt to call the unavailable openssl library functions.
Fixes: 942c8c8e66 ("rsa: Add rsa_verify_openssl() to use openssl for host builds")
Signed-off-by: Shiji Yang <yangshiji66@outlook.com>
Rename the variable and add ENV_ prefix, so that all configuration
options which are related to environment would have an CONFIG_ENV_
prefix. No functional change.
Also rename USE_DEFAULT_ENV_FILE to USE_ENV_DEFAULT_ENV_TEXT_FILE .
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Rename the variable and add ENV_ prefix, so that all configuration
options which are related to environment would have an CONFIG_ENV_
prefix. No functional change.
Use ENV_MMC_EMMC_HW_PARTITION to clarify this is the eMMC hardware
partition selector, not a software partition table entry selector.
Retain the ENV_MMC_ prefix to make it easier to search for all the
SD/MMC related ENV options. Update the help text accordingly.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Rename the variable and add ENV_ prefix, so that all configuration
options which are related to environment would have an CONFIG_ENV_
prefix. No functional change.
Use ENV_MMC_DEVICE_INDEX to clarify this is the SD/MMC device
index, a number, as enumerated by U-Boot. Update the help text
accordingly.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Rename the variable and add ENV_ prefix, so that all configuration
options which are related to environment would have an CONFIG_ENV_
prefix. No functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Rename the variable and add ENV_ prefix, so that all configuration
options which are related to environment would have an CONFIG_ENV_
prefix. No functional change.
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
First set of u-boot-at91 features for the 2025.10 cycle:
This feature set includes the addition of new sam9x7 SoC and a new board
named sam9x7-curiosity. There is also new support for sam9x60 compatible
at91 watchdog.
Instead of using defines for the RAM size and base address, retrieve these
information from the devicetree.
This aligns with the sama5d27_som1_ek board in commit 73c1589f02
("board: sama5d27_som1_ek: Get dram size and base from device tree").
While at it, remove a spurious '/* SPL */' comment.
Signed-off-by: Fabio Estevam <festevam@denx.de>
Introduce response and request structs to receive and request
information regarding DM version, etc from TI SCI.
Signed-off-by: Moteen Shah <m-shah@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Introduce response and request structs for receiving information
regarding FW/SOC capability from DM. The received capability can
further be used to call certain API's based on the feature supoorted
by the DM firmware.
Signed-off-by: Moteen Shah <m-shah@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Rasmus Villemoes <ravi@prevas.dk> says:
While looking through list.h, I saw that the regular list_* helpers
(and one of the hlist_* ones) still contain the prefetch() that was
removed in linux 14 years ago. It doesn't do anything, but makes the
macros harder to read, so get rid of it, and the fallback, no-op
definition that they relied on. That requires removing a few uses
outside list.h as well.
checkpatch warns about some whitespace issues in list.h, but as I've
copied whole kerneldoc+#define blocks directly from the linux kernel,
I think it's better to just accept that so that we don't introduce
needless diffs. The "macro argument reuse" arguments should also be
ignored, as e.g. the "member" arguments are obviously always just bare
identifiers, and the "pos" arguments must be assigned to multiple
times.
Link: https://lore.kernel.org/r/20250507121246.518691-1-ravi@prevas.dk
None of the list helpers use prefetch() anymore, and no C code relies
on getting this definition from list.h. In any case, such an arch/cpu
specific thing does not belong in a header that just consists of cpp
helper macros.
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
The use of prefetch() in these list helpers was dropped back in 2011
in linux (e66eed651fd1 ("list: remove prefetching from regular list
iterators")). No arch in U-Boot defines any actual prefetch(), and as
the referenced commit says, it's usually not a win anyway.
Whole-sale sync of list.h is not really feasible, but we can
synchronize the macros containing a prefetch() with their linux
implementations as of v6.15-rc5, also importing the various helpers
needed, e.g. list_is_head() and list_next_entry().
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Sync bitfield.h header with Linux 6.15 version. Mainly is to permit the
introduction of FIELD_PREP_CONST. The bug.h header changed to
build_bug.h doesn't cause any regression as we also ship split header
similar to how it's done with in Linux.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
E Shattow <e@freeshell.de> says:
Make consistent use of lowercase hexadecimal prefix '0x' throughout U-Boot.
There are a few remaining uses of uppercase 'X' to denote hexadecimal prefix
or placeholder in documentation and error messages.
External devicetree-rebasing dts/upstream and the generated code of
xilinx/zynq are ignored for the series.
Link: https://lore.kernel.org/r/20250606224558.1117422-1-e@freeshell.de
This function is currently a misnomer at times as we have cases where it
passes arguments to the image. In preparation for making that be a more
common case rename this function to jump_to_image(...). In order to do
this, rename jump_to_image in board_init_r(...) to jumper so that we do
not have a conflict.
Signed-off-by: Simon Glass <sjg@chromium.org>
[trini: Reword the commit message, adding missing cases of
jump_to_image_no_args()]
Signed-off-by: Tom Rini <trini@konsulko.com>
Quentin Schulz <foss+uboot@0leil.net> says:
Out of all the dev_read_*_default functions, only two do not properly
use the type as argument and return type: dev_read_u32_default and
dev_read_s32_default. They both use int instead of u32/s32.
Considering that it's generally not guaranteed that an int is 4 bytes
but also for consistency sake, let's have them use the expected type.
Note that I have not tested this, just stumbled upon that inconsistency
by chance.
Link: https://lore.kernel.org/r/20250528-dev_read_x32_default-v1-0-6ab1734dd7a2@cherry.de
dev_read_s32_default is for getting an s32 from a Device Tree property
and allows to take a default value if that property is missing.
Considering it calls ofnode_read_u32_default which takes a u32 and
returns a u32, it should do the same instead of using an int, especially
considering that int size is typically architecture-specific, as opposed
to s32/u32.
s32 and u32 being the same size, dev_read_s32* functions calling
ofnode_read_u32_default shouldn't be an issue (at the type level at
least) as the information will be stored appropriately in 4B regardless
of the sign.
This incidentally matches all other dev_read_*_default functions.
Fixes: a1b17e4f4c ("dm: core: Add a function to read into a unsigned int")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
dev_read_u32_default is for getting a u32 from a Device Tree property
and allows to take a default value if that property is missing.
Considering it calls ofnode_read_u32_default which takes a u32 and
returns a u32, it should do the same instead of using an int, especially
considering that int size is typically architecture-specific, as opposed
to u32.
This incidentally matches all other dev_read_*_default functions (except
dev_read_s32_default which will be tackled in the next commit).
Fixes: 47a0fd3bad ("dm: core: Implement live tree 'read' functions")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add support for generating STM32 Image V2.0, which is used by STM32MP13xx.
The image header layout is similar to STM32MP15xx STM32 Image V1.0, but is
different enough to justify duplicate functions to generate the v2 image.
This code at least attempts to align the V1 and V2 image handling where
possible.
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
Add SPL support and clock tree init to STM32MP13 RCC driver. This
consists of two parts, make SCMI into an optional dependency and
add clock tree initialization. The SCMI dependency is made optional
first by registering the few core clock provided by SCMI clock as
fixed clock, and second by letting the clock core parse out the
clock configuration from SoC registers. The clock initialization
code is derived from STM32MP15xx clock tree initialization code,
which is almost identical, except for the use of new PLL2000 for
PLL1 on STM32MP13xx .
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
Implement STM32MP25 reset drivers using stm32-core-reset API.
This reset stm32-reset-core API and will be able to use DT binding
index started from 0.
This patch also moves legacy reset into stm32 directory reset.
Signed-off-by: Gabriel Fernandez <gabriel.fernandez@foss.st.com>
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Add a new config CONFIG_CLK_AUTO_ID to support a unique clk id
for all the clock providers, managed by clk uclass, when the clock
reference arg[0] is the same.
When the CONFIG is activated, the clock id is limited to the lower
CLK_ID_SZ = 24 bits in default clock xlate function
and the sequence number + 1 of the clk provider device is
added for the 8 higher bits.
We use sequence number + 1 to avoid the "dummy" clock id = 0,
used for invalid clock when CCF is activated.
When this config is activated, the new function clk_get_id()
should be used to get back the internal reference to clock
for the each clock provider.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Lukasz Majewski <lukma@denx.de>
Cc: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Since clock protocol 2.0, SCMI specification add an option field
"clock_enable_delay" to CLOCK_ATTRIBUTES command.
scmi_read_resp_from_smt() will return an error ("Buffer too small") as
the message length coming from the SCMI server is not the same as expected.
So implement a condition to SCMI clock protocol version to change the
length of the expected message.
Signed-off-by: Valentin Caron <valentin.caron@foss.st.com>
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Lukasz Majewski <lukma@denx.de>
Cc: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Add Retronix R-Car V4H Sparrow Hawk board based on Renesas R-Car V4H ES3.0
(R8A779G3) SoC. This is a single-board computer with single gigabit ethernet,
DSI-to-eDP bridge, DSI and two CSI2 interfaces, audio codec, two CANFD ports,
micro SD card slot, USB PD supply, USB 3.0 ports, M.2 Key-M slot for NVMe SSD,
debug UART and JTAG.
DT is imported from Linux next commit:
a719915e76f2 ("arm64: dts: renesas: r8a779g3: Add Retronix R-Car V4H Sparrow Hawk board support")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
