| Age | Commit message (Collapse) | Author |
|---|
|
Anshul Dalal <[email protected]> says:
Some minor fixes to K3's env to avoid using hardcoded addresses but
instead move to Kconfig symbols.
Link: https://lore.kernel.org/r/[email protected]
|
|
The load addresses for DFU download binaries were hardcoded for K3
devices which required redefinition of such env for boards that deviated
from the expected K3 memory map (such as AM6254atl EMV).
This patch replaces the hardcoded addresses with their corresponding
Kconfig options making the k3_dfu.env more general.
Signed-off-by: Anshul Dalal <[email protected]>
|
|
In the TI's K3 bootflow of tiboot3.bin -> tispl.bin -> u-boot.img:
(R5 SPL) (A53 SPL)
We currently provide a common dfu_alt_info_ram for both R5 SPL and A53
SPL which is not intuitive in a regular bootflow where each binary
should only request it's immediate next stage.
This patch updates dfu_alt_info_ram such that the R5 SPL would only
request for tispl.bin and A53 SPL would only request u-boot.img.
Signed-off-by: Anshul Dalal <[email protected]>
|
|
With commit 17ceb774a185 ("rpi_arm64: Enable MBEDTLS/LWIP/WGET and
WGET_HTTPS"), we can drop the tests for switching from the legacy stack
to lwIP.
Signed-off-by: Tom Rini <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-raspberrypi
Updates for RPi for 2026.07-rc4:
- mmc: bcmstb: Fix non-removable check in bcm2712 init
- mmc: bcm2835_sdhci: Parse generic MMC device tree properties
- rpi_arm64: Enable MBEDTLS/LWIP/WGET and WGET_HTTPS
- video: arm: rpi: Add brcm,bcm2712-hdmi0 compatible
|
|
sdhci_brcmstb_init_2712() reads host->mmc->host_caps to decide whether
to force card-detect for a non-removable eMMC, or to route the CD signal
for a removable SD card. At the time this function runs from
sdhci_bcmstb_probe(), however, host->mmc->host_caps is still zero, that
field is only populated later by the MMC uclass, after the driver's
probe returns. mmc_of_parse() has already filled plat->cfg.host_caps
from the device tree by this point, so check that field instead.
Without the fix, every BCM2712 SDHCI instance takes the else branch and
writes SDIO_CFG_SD_PIN_SEL = SDIO_CFG_SD_PIN_SEL_CARD (0x02), including
the non-removable eMMC on boards such as CM5 on Home Assistant Yellow.
The SDIO_CFG block lies outside the SDHCI core's reset scope, so this
value persists across SDHCI_RESET_ALL into the next stage. On the
BCM2712, having SD_PIN_SEL set to "SD" when the Linux kernel performs
its first set_power(MMC_POWER_UP) write racily prevents the SDHCI
POWER_ON bit from latching (see [1] for the whole backstory) - the
voltage bits stick but POWER_ON drops - which wedges the first CMD0 the
full 10 s software timeout. On Home Assistant Yellow this manifested as
a ~20 s eMMC probe delay on roughly one in two Linux boots when U-Boot
was the previous stage. Booting directly from the Pi firmware (no U-Boot
in between) left SD_PIN_SEL at its default and did not exhibit the race.
Reading plat->cfg.host_caps lets init_2712 see the "non-removable"
property and take the correct branch, leaving SD_PIN_SEL untouched for
the eMMC.
[1] https://github.com/home-assistant/operating-system/pull/3700#issuecomment-4430229511
Fixes: 10127cdbab64 ("mmc: bcmstb: Add support for bcm2712 SD controller")
Signed-off-by: Jan Čermák <[email protected]>
Reviewed-by: Ivan T. Ivanov <[email protected]>
|
|
nvme_init() allocates prp_pool after configuring the admin queue,
but some later error paths return without freeing it.
Free prp_pool before freeing the queue array in the failure paths
after nvme_setup_io_queues() and namespace ID buffer allocation.
This fixes a memory leak during NVMe initialization failures.
Signed-off-by: Prashant Kamble <[email protected]>
Reviewed-by: Neil Armstrong <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Neil Armstrong <[email protected]>
|
|
nvme_create_queue() may issue Delete CQ or Delete SQ
commands even when the corresponding queue creation
failed.
Avoid sending delete commands for queues that were never
successfully created.
Signed-off-by: Prashant Kamble <[email protected]>
Reviewed-by: Neil Armstrong <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Neil Armstrong <[email protected]>
|
|
When the identify buffer crosses a page boundary, PRP2 is used
and dma_addr is advanced to the second page:
dma_addr += (page_size - offset);
The subsequent invalidate_dcache_range() calls then use the
modified dma_addr instead of the original buffer start address.
As a result, the beginning of the identify buffer is not
invalidated and the invalidation range extends past the end of
the buffer.
Fix this by preserving the original DMA buffer address for cache
invalidation.
Suggested-by: Neil Armstrong <[email protected]>
Signed-off-by: Prashant Kamble <[email protected]>
Reviewed-by: Neil Armstrong <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Neil Armstrong <[email protected]>
|
|
Boot on am33xx without CONFIG_USB will currently fail, as we error-out
of arch_misc_init() if no UCLASS_MISC device is found. This requirement
was introduced in commit 3aec2648698d ("am33xx: board: probe misc
drivers to register musb devices").
Instead, only attempt the UCLASS_MISC init if we would expect the MUSB
TI device to be present. Add a comment to explain why we're doing the
device lookup (which we immediately discard).
Fixes: 3aec2648698d ("am33xx: board: probe misc drivers to register musb devices")
Signed-off-by: Jeremy Kerr <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
Avoid using ps_prompt having a NULL pointer. For that, use the same
approach as in uboot_cli_readline().
Suggested-by: Simon Glass <[email protected]>
Signed-off-by: Adam Lackorzynski <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
The FAT time format stores seconds/2 in bits 4:0. The expression
'tm.tm_sec > 1' is a boolean comparison (yields 0 or 1) where a
right-shift 'tm.tm_sec >> 1' was intended. As a result every
file timestamp written by U-Boot has its seconds field set to
either 0 or 1, depending on whether tm_sec is greater than 1.
Also fix the indentation of the tm_hour line.
Fixes: ba23c378c544 ("fs: fat: fill creation and change date")
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Daniel Golle <[email protected]> says:
This series adds dm-verity support to U-Boot's FIT image infrastructure.
It is the first logical subset of the larger OpenWrt boot method series
posted as an RFC in February 2026 [1], extracted here for independent
review and merging.
OpenWrt's firmware model embeds a read-only squashfs or erofs root
filesystem directly inside a uImage.FIT container as a FILESYSTEM-type
loadable FIT image. At boot the kernel maps this sub-image directly from
the underlying block device via the fitblk driver (/dev/fit0, /dev/fit1,
...), the goal is that the bootloader never even copies it to RAM.
dm-verity enables the kernel to verify the integrity of those mapped
filesystems at read time, with a Merkle hash tree stored contiguously in
the same sub-image just after the data. Two kernel command-line
parameters are required:
dm-mod.create= -- the device-mapper target table for the verity device
dm-mod.waitfor= -- a comma-separated list of block devices to wait for
before dm-init sets up the targets (needed when fitblk
probes late, e.g. because it depends on NVMEM
calibration data)
The FIT dm-verity node schema was upstreamed into the flat-image-tree
specification [2], which this implementation tries to follow exactly.
The runtime feature is guarded behind CONFIG_FIT_VERITY. If not
enabled the resulting binary size remains unchanged. If enabled the
binary size increases by about 3kB.
[1] previous submissions:
RFC: https://www.mail-archive.com/[email protected]/msg565945.html
v1: https://www.mail-archive.com/[email protected]/msg569472.html
v2: https://www.mail-archive.com/[email protected]/msg570599.html
v3: https://www.mail-archive.com/[email protected]/msg573223.html
v4: https://www.mail-archive.com/[email protected]/msg574000.html
[2] flat-image-tree dm-verity node spec:
https://github.com/open-source-firmware/flat-image-tree/commit/795fd5fd7f0121d0cb03efb1900aafc61c704771
Link: https://lore.kernel.org/r/[email protected]
|
|
Add FIT_VERITY_NODENAME and the complete set of FIT_VERITY_*_PROP
constants for the dm-verity child node of filesystem-type images, plus
the five optional boolean error-handling property names aligned with the
flat-image-tree specification.
Signed-off-by: Daniel Golle <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
Enable FIT_VERITY in the sandbox configs that build a full U-Boot
binary so CI may exercise the new dm-verity unit test
(test/boot/fit_verity.c) and the mkimage pytest
(test/py/tests/test_fit_verity.py) introduced earlier in this series.
The SPL/VPL/noinst variants only load U-Boot proper, never an OS, so
dm-verity is meaningless there and is not enabled.
Suggested-by: Tom Rini <[email protected]>
Signed-off-by: Daniel Golle <[email protected]>
|
|
Add test/py/tests/test_fit_verity.py covering:
- mkimage writes correct dm-verity properties for matched and
mismatched block sizes (4096/4096 and 4096/1024);
- veritysetup verify re-checks the digest against the .itb's
external data section;
- mkimage rejects dm-verity images built without -E.
All tests are skipped if veritysetup is not installed on the host.
Signed-off-by: Daniel Golle <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Add test/boot/fit_verity.c with four tests that construct FIT blobs
in memory and exercise fit_verity_build_cmdline().
Signed-off-by: Daniel Golle <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Add documentation for CONFIG_FIT_VERITY which allows U-Boot to
construct dm-mod.create= and dm-mod.waitfor= kernel command-line
parameters from dm-verity metadata embedded in FIT filesystem
sub-images.
The new document covers the relationship between FIT loadable indices
and the /dev/fitN block devices that the Linux uImage.FIT block driver
creates, provides a complete .its example with a dm-verity-protected
SquashFS root filesystem, describes all required and optional dm-verity
subnode properties and explains how mkimage generates the verity
metadata automatically.
dm-verity is only supported for external-data FIT images (mkimage -E);
mkimage aborts with an error if the flag is omitted.
Signed-off-by: Daniel Golle <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
When mkimage encounters a dm-verity subnode inside a component image
node it now automatically invokes veritysetup(8) with --no-superblock
to generate the Merkle hash tree, screen-scrapes the Root hash and Salt
from the tool output, and writes the computed properties back into the
FIT blob.
The user only needs to specify algorithm, data-block-size, and
hash-block-size in the ITS; mkimage fills in digest, salt,
num-data-blocks, and hash-start-block. Because --no-superblock is
used, hash-start-block equals num-data-blocks with no off-by-one.
The image data property is replaced with the expanded content (original
data followed directly by the hash tree) so that subsequent hash and
signature subnodes operate on the complete image.
fit_image_add_verification_data() is restructured into two passes:
dm-verity first (may grow data), then hashes and signatures.
Signed-off-by: Daniel Golle <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Make hexdump.h work in host-tool builds by using 'uint8_t' instead
of 'u8', and including either user-space libc <ctype.h> for host-tools
or <linux/ctype.h> when building U-Boot itself.
Signed-off-by: Daniel Golle <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Add fit_verity_build_cmdline(): when a FILESYSTEM loadable carries a
dm-verity subnode, construct the dm-mod.create= kernel cmdline parameter
from the verity metadata (block-size, data-blocks, algo, root-hash,
salt) and append it to bootargs.
Also add dm-mod.waitfor=/dev/fit0[,/dev/fitN] for each dm-verity device
so the kernel waits for the underlying FIT block device to appear before
setting up device-mapper targets. This is needed when the block driver
probes late, e.g. because it depends on NVMEM calibration data.
The dm-verity target references /dev/fitN where N is the loadable's
index in the configuration -- matching the order Linux's FIT block
driver assigns block devices. hash-start-block is read directly from
the FIT dm-verity node; mkimage ensures its value equals num-data-blocks
by invoking veritysetup with --no-superblock.
Signed-off-by: Daniel Golle <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-stm
CI: https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/30256
- Add support dynamic A/B bank bootup for STM32MP15
- Increase SYS_MALLOC_F_LEN for stm32mp15_defconfig to fix boot with optee-4.10.0
- Enable Arm SMC watchdog for STM32MP1
- Update part number for TM32MP251/3 SoC's family
|
|
update part number for STM32MP251/3 for last cut revision.
Signed-off-by: Patrice Chotard <[email protected]>
Reviewed-by: Patrick Delaunay <[email protected]>
|
|
For this configuration, the watchdog (iwdg1) is secured and managed by
OP-TEE. Add an watchdog node with arm,smc-wdt compatible, and disable
iwdg2 node which is then no more used.
Signed-off-by: Yann Gautier <[email protected]>
Reviewed-by: Patrice Chotard <[email protected]>
|
|
No watchdog was enabled for STM32MP13 platform. Add the required flags to
support it. As done for STM32MP15 (in SCMI config) and STM32MP2x, we use
the Arm SMC watchdog. The required nodes were already present in Linux
imported DT files (stm32mp13.dtsi & stm32mp135f-dk.dts).
To enable this SMC watchdog on other platforms based on STM32MP13, check
that both the following flags are enabled in the dedicated config file:
CONFIG_WDT=y
CONFIG_WDT_ARM_SMC=y
And that there is a node in Linux board DT that enables the feature, as
it is done in stm32mp135f-dk.dts:
&arm_wdt {
timeout-sec = <32>;
status = "okay";
};
Signed-off-by: Patrick Delaunay <[email protected]>
Signed-off-by: Yann Gautier <[email protected]>
Reviewed-by: Patrice Chotard <[email protected]>
|
|
Enable the arm watchdog over SMC driver. This allows using a secure
watchdog, based on IWDG1 peripheral and managed by OP-TEE.
The driver will be probed if a watchdog node with "arm,smc-wdt"
compatible is enabled.
Signed-off-by: Lionel Debieve <[email protected]>
Signed-off-by: Yann Gautier <[email protected]>
Reviewed-by: Patrice Chotard <[email protected]>
|
|
Using stm32mp15_defconfig with stm32mp157c-dk2-scmi.dtsi device tree
with optee-4.10.0, we got:
U-Boot 2026.07-rc2-00052-g215496fec59b (May 18 2026 - 15:05:34 +0200)
CPU: STM32MP157CAC Rev.B
Model: STMicroelectronics STM32MP157C-DK2 SCMI Discovery Board
Board: stm32mp1 in trusted mode (st,stm32mp157c-dk2-scmi)
alloc space exhausted ptr 80060 limit 80000
optee optee: PTA_BSEC invoke failed TEE err: 0, err:fffffff4
alloc space exhausted ptr 80040 limit 80000
alloc space exhausted ptr 80020 limit 80000
DRAM: alloc space exhausted ptr 80040 limit 80000
RAM init failed: -12
initcall_run_f(): initcall dram_init() failed
CONFIG_SYS_MALLOC_F_LEN need to be increased to fix this issue
Reported-by: Yann Gautier <[email protected]>
Signed-off-by: Patrice Chotard <[email protected]>
Reviewed-by: Patrick Delaunay <[email protected]>
|
|
Factorize FWU multi-bank support code common to STM32MP1 and
STM32MP2 platforms into a dedicated shared source file.
No functional change intended.
Signed-off-by: Dario Binacchi <[email protected]>
Reviewed-by: Patrice Chotard <[email protected]>
|
|
Following commit 4300f9f4c5d7 ("board: st: stm32mp25: support dynamic
A/B bank bootup"), this patch enables automatic detection of the active
A/B bank on STM32MP15 platforms by retrieving partition GUIDs from FWU
metadata.
This ensures the system correctly identifies the bootable partitions
even in multi-bank scenarios, falling back to a standard bootable flag
scan if the UUIDs are missing.
To enable A/B bank bootup on STM32MP15 boards, add the following Kconfig
options to the stm32mp15[_basic]_defconfig:
CONFIG_FWU_MULTI_BANK_UPDATE=y
CONFIG_FWU_MDATA=y
CONFIG_FWU_NUM_BANKS=2
CONFIG_FWU_NUM_IMAGES_PER_BANK=3
CONFIG_CMD_FWU_METADATA=y
CONFIG_FWU_MDATA_V2=y
Signed-off-by: Dario Binacchi <[email protected]>
Reviewed-by: Patrice Chotard <[email protected]>
|
|
The bcm2835 SDHCI driver sets up the MMC host configuration via
sdhci_setup_cfg(), but does not parse generic MMC device tree
properties.
As a result, properties such as bus-width are ignored. On Raspberry Pi
Compute Module 4, the eMMC node describes an 8-bit bus, but U-Boot
initialized the device as 4-bit.
Call mmc_of_parse() before sdhci_setup_cfg() so that generic MMC
properties are folded into the host configuration before the MMC core
selects the bus width.
Before this change, mmc info reported:
Bus Speed: 52000000
Bus Width: 4-bit
After this change, mmc info reports:
Bus Speed: 52000000
Bus Width: 8-bit
Tested on Raspberry Pi Compute Module 4 with onboard eMMC.
Signed-off-by: Liel Harel <[email protected]>
Reviewed-by: Peter Robinson <[email protected]>
Tested-by: Peter Robinson <[email protected]> # on the CM4 as well
|
|
Enable LWIP and HTTPS on the Raspberry Pi arm64 platform to be able to
use it in the boot process.
Signed-off-by: Peter Robinson <[email protected]>
Reviewed-by: Matthias Brugger <[email protected]>
|
|
The 'brcm,bcm2712-hdmi0' compatible string is used on RPi5.
There appears to be no change that impacts early boot output
on the display controller so add the RPi5 compatible string.
Signed-off-by: Peter Robinson <[email protected]>
Reviewed-by: Matthias Brugger <[email protected]>
|
|
This series from James Hilliard <[email protected]> converts the
static flags list for the environment to be configured via Kconfig and
updates the documentation.
Link: https://lore.kernel.org/r/[email protected]
|
|
The remaining configuration settings section is legacy README content.
Its details belong in Kconfig help or the rST documentation.
Remove the section instead of keeping partial stale configuration
documentation in README.
Suggested-by: Tom Rini <[email protected]>
Signed-off-by: James Hilliard <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Environment callbacks can already be configured from Kconfig with
CONFIG_ENV_CALLBACK_LIST_STATIC, but static environment flags still
require board headers to define CFG_ENV_FLAGS_LIST_STATIC.
Add CONFIG_ENV_FLAGS_LIST_STATIC and use it as the only board-provided
static environment flags list. Convert the remaining default-config users
from CFG_ENV_FLAGS_LIST_STATIC to defconfig settings and drop the legacy
header macro from ENV_FLAGS_LIST_STATIC.
Move the environment flags format documentation out of README and into
the developer environment documentation. Include the format in the
Kconfig help as well.
This lets boards configure writeable-list policy and type validation
from defconfig without adding a config header solely for env flags.
This preserves the behavior of default configs. Header-only cases that
were inactive in upstream defconfigs are not converted into defconfig
entries: iot2050 can add its list when enabling ENV_WRITEABLE_LIST, and
smegw01 can add mmcdev:dw support if the unlocked SYS_BOOT_LOCKED=n
configuration is needed.
Signed-off-by: James Hilliard <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Alexander Sverdlin <[email protected]>
Reviewed-by: Walter Schweizer <[email protected]>
|
|
Aristo Chen <[email protected]> says:
This series ends with replacing the verbose fdt_next_node() + ndepth
idiom in boot/image-fit.c with fdt_for_each_subnode(), bringing the
file in line with boot/image-fit-sig.c. Six of the seven sites in
image-fit.c predate the macro by 2-6 years; the seventh was
copy-pasted from a neighbour in 2015 just after the macro landed.
The old idiom is legacy, not a deliberate technical choice.
Converting straight to the macro turned out to need a prerequisite,
which is patch 1. fit_print_contents() reads the default-config
property using the loop variable left over after iterating /images
children. With /images defined first in the source (the conventional
layout) libfdt's walker happens to leave that variable pointing at
/configurations and the read works. With /configurations defined
first the read returns NULL and the "Default Configuration" line is
silently omitted. fdt_for_each_subnode()'s post-loop value is
unconditionally a negative error code, so a naive conversion would
have made the missing line the unconditional behaviour. Patch 1
reads the property from confs_noffset directly and removes the
layout dependency.
Patch 2 adds a regression test for the configs-before-images
layout, which had no coverage.
Patch 3 is the mechanical conversion at all seven sites,
equivalence-preserving as described in the per-patch message.
Link: https://lore.kernel.org/r/[email protected]
|
|
Replace the verbose fdt_next_node() + ndepth pattern with the
fdt_for_each_subnode() macro at all seven sites in boot/image-fit.c
where the loop only ever processes direct children. The macro is
already defined in <linux/libfdt.h> and used in boot/image-fit-sig.c,
so this brings image-fit.c in line with the rest of the FIT code.
The conversions are equivalence-preserving:
- fit_get_subimage_count(): the depth-1 filter and the macro are
both restricted to direct children.
- fit_conf_print(): the parameter is named noffset, so the loop
now uses sub_noffset to keep the parent reference stable.
- fit_print_contents(): the count reset that lived inside the for
initialiser is moved out as an explicit assignment before each
loop, so the second loop still starts from zero.
- fit_image_print(): straightforward replacement.
- fit_all_image_verify(): same shape as the print loops, with the
count reset moved out as an explicit assignment before the loop.
- fit_conf_find_compat(): the body's "if (ndepth > 1) continue"
guard is redundant once the macro is in use, and is dropped.
No behaviour changes outside of these mechanical reductions. Local
ndepth declarations that are no longer referenced are removed.
Signed-off-by: Aristo Chen <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Add a test that builds a FIT whose /configurations node is defined
before /images in the source, runs iminfo, and asserts that the
"Default Configuration: '<name>'" line appears in the output.
Before the fix in the preceding commit ("boot/fit: read default-config
property from the configurations node"), fit_print_contents() read the
default-config property using the loop variable left over from iterating
/images children. With /images defined first that variable accidentally
pointed at /configurations and the line printed correctly; with
/configurations defined first the read returned NULL and the line was
silently omitted. The new test exercises the latter layout, which had
no coverage.
iminfo and the fit_print_contents() path had no test coverage at all
before this commit.
Signed-off-by: Aristo Chen <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
In fit_print_contents() the default configuration's unit name is read by
calling fdt_getprop() with noffset rather than confs_noffset. Today this
happens to work by coincidence: the preceding loop walks /images using
fdt_next_node(), and when iteration leaves the subtree libfdt returns
the offset of the next sibling in DFS order, which by FIT layout
convention is /configurations. The depth counter then drops below zero
and the loop exits with noffset still pointing at /configurations.
This relies on /images and /configurations being adjacent siblings and
on the implementation detail of fdt_next_node()'s post-exhaustion
return value. It also blocks a follow-up conversion to
fdt_for_each_subnode(), whose post-loop loop variable is a negative
error code rather than a valid offset.
Use confs_noffset directly, which the comment immediately above the
call already names as the source.
Signed-off-by: Aristo Chen <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Sync include/ec_commands.h from upstream commit 4f3d17aa34
("skywalker: set SLEEP_TIMEOUT_MS to 50 seconds"). The new file makes
two build assumptions that do not hold for U-Boot.
It hides '<stdint.h>' from __KERNEL__ builds, leaving UINT16_MAX
(used by EC_RES_MAX) undefined for U-Boot; widen the gate to
'!defined(__KERNEL__) || defined(__UBOOT__)'
It gates '<linux/limits.h>' on '#ifdef __KERNEL__'; the matching
'#else' branch defines BIT()/BIT_ULL()/GENMASK()/GENMASK_ULL()
locally, assuming kernel headers provide those macros otherwise.
U-Boot defines __KERNEL__ too but has no <linux/limits.h>. Nest a
'!defined(__UBOOT__)' check around the include so the __UBOOT__ path
stays in the __KERNEL__ branch (no local BIT/GENMASK defines), which
avoids redefinition warnings against U-Boot's linux/bitops.h. Pull
in linux/bitops.h up front for U-Boot so the file's own BIT() and
GENMASK() uses still resolve.
Adapt callers to two interface changes. The 'ec_current_image' enum
tag is now 'ec_image' (EC_IMAGE_* constants unchanged); rename it in
affected files to match. The VBNV-context interface was dropped
upstream, but it still used in lab Chromebooks; keep those constants and
structs in cros_ec.h
Likewise, MEC_EMI_BASE and MEC_EMI_SIZE are a U-Boot-local addition to
ec_commands.h that the upstream sync removes; preserve them in cros_ec.h
next to the VBNV block, and switch the only consumer
(arch/x86/cpu/apollolake/cpu_spl.c) to include cros_ec.h
Signed-off-by: Simon Glass <[email protected]>
|
|
If the LED is in the ON state, it is briefly set to OFF
then to ON immediately due to falling-through in the default
case.
This commit ensures that no fall-through occurs and thus
a LED initially in the ON state is turned off before blinking.
Signed-off-by: Francois Berder <[email protected]>
Fixes: 9e3d83301e4f ("led: toggle LED on initial SW blink")
Acked-by: Quentin Schulz <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
gpio status -a does not have labels: the existing path walks
the per-bank requested label table.
Issue: The boards that populate the standard gpio-line-names
property in their device tree end up with anonymous entries,
which is not logic with the purpose of having those names in the DT.
No impact with boards that does not set gpio-line-names.
Signed-off-by: Vincent Jardin <[email protected]>
|
|
test_fs/test_erofs.py and test_fs/test_squashfs/sqfs_common.py both
defined a generate_file() helper that writes a file of a given size
filled with 'x'. The two functions were functionally identical and
differed only in parameter names and docstrings.
Move the helper into the existing test/py/utils.py module, which is
the established home for generic test utilities (md5sum_file,
PersistentRandomFile, attempt_to_open_file). Update both call sites
to use it.
Signed-off-by: Aristo Chen <[email protected]>
Reviewed-by: [email protected]
Reviewed-by: Simon Glass <[email protected]>
|
|
Prepare v2026.07-rc3
|
|
Signed-off-by: Tom Rini <[email protected]>
|
|
A file like rm-cfg.yaml accidentally left in the source tree root
shadows the board-specific copy. binman builds the wrong YAML, the
resulting rm-cfg.bin may match a different SoC, and we end up with
the following error:
k3_system_controller sysctrler: k3_sysctrler_start:
Boot Notification response failed. ret = -110
Move the board directory ahead of the srctree root so that the
most-specific match wins.
Signed-off-by: Wadim Egorov <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-microblaze
AMD/Xilinx/FPGA changes for v2026.07-rc3
versal/fpga:
- Fix unaligned buffer handling
versal2:
- Fix buffer overflow in SOC name array
|
|
Resync all defconfig files using qconfig.py
Signed-off-by: Tom Rini <[email protected]>
|
|
Our official domain is now u-boot-project.org, so update all in-tree
references to use the correct domain.
Reviewed-by: Tony Dinh <[email protected]>
Reviewed-by: Peter Robinson <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
Anshul Dalal <[email protected]> says:
This patch series fixes firewall exceptions observed on AM62 family of
devices due to speculative accesses made by the A53 core to secure DDR
regions.
Link: https://lore.kernel.org/r/[email protected]
|
