u-boot-toradex.git/boot, branch master U-Boot bootloader for Apalis and Colibri modules boot: image-fit.c: check target, not source, for 8-byte alignment when loading FDT 2026-05-08T21:49:27+00:00 Rasmus Villemoes ravi@prevas.dk 2026-05-04T14:44:55+00:00 55b152e6f0204e0b769f66ffd40ad02081f9bff0 A number of our boards no longer boot with v2026.04, ironically as a result of the effort to ensure 8-byte alignment of the dtb passed to the kernel and getting rid of the fdt_high=0xffffffff. The problem exists when the FIT image does specify a (properly aligned) load address to use for the fdt. For example, we have fdt-am335x-boneblack.dtb { description = "Flattened Device Tree blob"; data = /incbin/(...); ... load = <0x88000000>; } Now, with v2026.04 and depending on just exactly where that data ends up, in a good case we see Loading fdt from 0x8a8c6e10 to 0x88000000 Booting using the fdt blob at 0x88000000 Working FDT set to 88000000 Loading Kernel Image to 86008000 WARNING: The 'fdt_high' environment variable is set to ~0. This is known to cause boot failures due to placement of DT at non-8-byte-aligned addresses. This system will likely fail to boot. Unset the 'fdt_high' environment variable and submit a fix upstream. Using Device Tree in place at 88000000, end 8801af2f Working FDT set to 88000000 Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0 and the board boots (though with that ominous warning). However, modifying the .its file a little, e.g. just removing the word "blob" from the description, we end up with Loading fdt from 0x8a8c6e14 to 0x88000000 Booting using the fdt blob at 0x9df94718 Working FDT set to 9df94718 Loading Kernel Image to 86008000 WARNING: The 'fdt_high' environment variable is set to ~0. This is known to cause boot failures due to placement of DT at non-8-byte-aligned addresses. This system will likely fail to boot. Unset the 'fdt_high' environment variable and submit a fix upstream. Failed to reserve memory for fdt at 0x9df94718 FDT creation failed! resetting ... Notice how the "Loading fdt from" line still claims to load the fdt to that 0x88000000 address, but since this "else if" clause looks at the source address (buf) and comes before the "else if (load != data)" clause, we end up doing the "allocate another buffer to use as target" instead of actually copying to 0x88000000, but then the "fdt_high=~0" logic in boot_relocate_fdt() obviously fails to do an lmb-reservation of that area, and the boot fails. When there's no load= property in the fdt node, this should not change anything. But when there is, it is the alignment of that target which is relevant, not the alignment of the fdt blob within the FIT image. With this patch applied, we instead get the expected Loading fdt from 0x8a8c6e14 to 0x88000000 Booting using the fdt blob at 0x88000000 Working FDT set to 88000000 Loading Kernel Image to 86008000 WARNING: The 'fdt_high' environment variable is set to ~0. This is known to cause boot failures due to placement of DT at non-8-byte-aligned addresses. This system will likely fail to boot. Unset the 'fdt_high' environment variable and submit a fix upstream. Using Device Tree in place at 88000000, end 8801af2f Working FDT set to 88000000 Starting kernel ... Signed-off-by: Rasmus Villemoes <ravi@prevas.dk> Fixes: 8fbcc0e0e839 ("boot: Assure FDT is always at 8-byte aligned address") Reviewed-by: Simon Glass <sjg@chromium.org> 
A number of our boards no longer boot with v2026.04, ironically as a
result of the effort to ensure 8-byte alignment of the dtb passed to
the kernel and getting rid of the fdt_high=0xffffffff.

The problem exists when the FIT image does specify a (properly
aligned) load address to use for the fdt. For example, we have

	fdt-am335x-boneblack.dtb {
		description = "Flattened Device Tree blob";
		data = /incbin/(...);
		...
		load = <0x88000000>;
	}

Now, with v2026.04 and depending on just exactly where that data ends
up, in a good case we see

     Loading fdt from 0x8a8c6e10 to 0x88000000
     Booting using the fdt blob at 0x88000000
  Working FDT set to 88000000
     Loading Kernel Image to 86008000
  WARNING:
  The 'fdt_high' environment variable is set to ~0. This is known to cause
  boot failures due to placement of DT at non-8-byte-aligned addresses.
  This system will likely fail to boot. Unset the 'fdt_high' environment
  variable and submit a fix upstream.
     Using Device Tree in place at 88000000, end 8801af2f
  Working FDT set to 88000000
  Starting kernel ...
  [    0.000000] Booting Linux on physical CPU 0x0

and the board boots (though with that ominous warning). However,
modifying the .its file a little, e.g. just removing the word "blob"
from the description, we end up with

     Loading fdt from 0x8a8c6e14 to 0x88000000
     Booting using the fdt blob at 0x9df94718
  Working FDT set to 9df94718
     Loading Kernel Image to 86008000
  WARNING:
  The 'fdt_high' environment variable is set to ~0. This is known to cause
  boot failures due to placement of DT at non-8-byte-aligned addresses.
  This system will likely fail to boot. Unset the 'fdt_high' environment
  variable and submit a fix upstream.
  Failed to reserve memory for fdt at 0x9df94718
  FDT creation failed!
  resetting ...

Notice how the "Loading fdt from" line still claims to load the fdt to
that 0x88000000 address, but since this "else if" clause looks at the
source address (buf) and comes before the "else if (load != data)"
clause, we end up doing the "allocate another buffer to use as target"
instead of actually copying to 0x88000000, but then the "fdt_high=~0"
logic in boot_relocate_fdt() obviously fails to do an lmb-reservation
of that area, and the boot fails.

When there's no load= property in the fdt node, this should not change
anything. But when there is, it is the alignment of that target which
is relevant, not the alignment of the fdt blob within the FIT
image. With this patch applied, we instead get the expected

     Loading fdt from 0x8a8c6e14 to 0x88000000
     Booting using the fdt blob at 0x88000000
  Working FDT set to 88000000
     Loading Kernel Image to 86008000
  WARNING:
  The 'fdt_high' environment variable is set to ~0. This is known to cause
  boot failures due to placement of DT at non-8-byte-aligned addresses.
  This system will likely fail to boot. Unset the 'fdt_high' environment
  variable and submit a fix upstream.
     Using Device Tree in place at 88000000, end 8801af2f
  Working FDT set to 88000000

  Starting kernel ...

Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Fixes: 8fbcc0e0e839 ("boot: Assure FDT is always at 8-byte aligned address")
Reviewed-by: Simon Glass <sjg@chromium.org>
efi_loader: centralize messaging for efi_init_obj_list 2026-05-01T08:30:03+00:00 Heinrich Schuchardt heinrich.schuchardt@canonical.com 2026-04-20T22:03:21+00:00 82539af483175e076f3727b51e23dff020eeec41 If efi_init_obj_list() fails we cannot use the UEFI sub-system. * Instead of having messages for this everywhere write an error message in efi_init_obj_list(). * Always use (ret != EFI_SUCCESS) when checking the return value of efi_init_obj_list(). * Remove the return code from the error message as it does not help users to understand which initialization went wrong. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> 
If efi_init_obj_list() fails we cannot use the UEFI sub-system.

* Instead of having messages for this everywhere write an error message
  in efi_init_obj_list().
* Always use (ret != EFI_SUCCESS) when checking the return value of
  efi_init_obj_list().
* Remove the return code from the error message as it does not help
  users to understand which initialization went wrong.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Merge patch series "net: migrate NO_NET out of the networking stack choice" 2026-04-27T17:28:25+00:00 Tom Rini trini@konsulko.com 2026-04-27T17:28:25+00:00 96c8b9c4ceb7a144e52b5bbf56ea58512f978bb7 Quentin Schulz <foss+uboot@0leil.net> says: This migrates the net options away from the main Kconfig to net/Kconfig, rename the current NET option to NET_LEGACY to really highlight what it is and hopefully encourage more people to use lwIP, add a new NET menuconfig (but keep NO_NET as an alias to NET=n for now) which then allows us to replace all the "if legacy_stack || lwip_stack" checks with "if net_support" which is easier to read and maintain. The only doubt I have is wrt SYS_RX_ETH_BUFFER which seems to be needed for now even when no network is configured? Likely due to include/net-common.h with PKTBUFSRX? No change in behavior is intended. Only change in defconfig including other defconfigs where NO_NET=y or NET is not set, in which case NO_NET is not set or NET=y should be set in the top defconfig. Similar change required for config fragments. See commit log in patch adding NET menuconfig for details. This was tested based on 70fd0c3bb7c2 ("x86: there is no CONFIG_UBOOT_ROMSIZE_KB_12288"), from within the GitLab CI container trini/u-boot-gitlab-ci-runner:noble-20251013-23Jan2026 and set up similarly as in "build all platforms in a single job" GitLab CI job. #!/usr/bin/env bash set -o pipefail set -eux ARGS="-BvelPEWM --reproducible-builds --step 0" ./tools/buildman/buildman -o ${O} --force-build $ARGS -CE $* ./tools/buildman/buildman -o ${O} $ARGS -Ssd $* O=../build/u-boot/ ../u-boot.sh -b master^..b4/net-kconfig |& tee ../log.txt I can't really decipher the log.txt, but there's no line starting with + which would be an error according to tools/buildman/builder.py help text. Additionally, because I started the script with set -e set and because buildman has an exit code != 0 when it fails to build a board, and I have the summary printed (which is the second buildman call), I believe it means all builds passed. The summary is the following: aarch64: (for 537/537 boards) all +0.0 rodata +0.0 uniphier_v8 : all +1 rodata +1 u-boot: add: 0/0, grow: 1/0 bytes: 1/0 (1) function old new delta data_gz 10640 10641 +1 arm: (for 733/733 boards) all -0.0 rodata -0.0 uniphier_v7 : all -1 rodata -1 u-boot: add: 0/0, grow: 0/-1 bytes: 0/-1 (-1) function old new delta data_gz 11919 11918 -1 opos6uldev : all -3 rodata -3 u-boot: add: 0/0, grow: 0/-1 bytes: 0/-3 (-3) function old new delta data_gz 18778 18775 -3 uniphier_ld4_sld8: all -3 rodata -3 u-boot: add: 0/0, grow: 0/-1 bytes: 0/-3 (-3) function old new delta data_gz 11276 11273 -3 stemmy : all -20 rodata -20 u-boot: add: 0/0, grow: 0/-1 bytes: 0/-20 (-20) function old new delta data_gz 15783 15763 -20 As far as I could tell this data_gz is an automatically generated array when CONFIG_CMD_CONFIG is enabled. It is the compressed .config stored in binary form. Because I'm changing the name of symbols, replacing a menu with a menuconfig, additional text makes it to .config and the "# Networking" section in .config disappears. Here is the diff for the 5 defconfigs listed above, generated with: for f in build/*-m; do diff --unified=0 $f/.config $(dirname $f)/$(basename -a -s '-m' $f)/.config done (-m is the build directory for master, and without the suffix, it's the top commit of this series) """ --- build/opos6uldev-m/.config 2026-04-20 10:53:49.804528526 +0200 +++ build/opos6uldev/.config 2026-04-20 11:03:37.430242767 +0200 @@ -970,4 +969,0 @@ - -# -# Networking -# @@ -975,0 +972 @@ +CONFIG_NET_LEGACY=y --- build/stemmy-m/.config 2026-04-20 11:01:33.653698123 +0200 +++ build/stemmy/.config 2026-04-20 11:04:53.452577311 +0200 @@ -733,4 +732,0 @@ - -# -# Networking -# @@ -738,2 +733,0 @@ -# CONFIG_NET is not set -# CONFIG_NET_LWIP is not set --- build/uniphier_ld4_sld8-m/.config 2026-04-20 11:00:41.605469071 +0200 +++ build/uniphier_ld4_sld8/.config 2026-04-20 11:04:22.226439899 +0200 @@ -997,4 +996,0 @@ - -# -# Networking -# @@ -1002,0 +999 @@ +CONFIG_NET_LEGACY=y --- build/uniphier_v7-m/.config 2026-04-20 10:53:04.019307319 +0200 +++ build/uniphier_v7/.config 2026-04-20 11:03:01.688085486 +0200 @@ -1004,4 +1003,0 @@ - -# -# Networking -# @@ -1009,0 +1006 @@ +CONFIG_NET_LEGACY=y --- build/uniphier_v8-m/.config 2026-04-20 10:43:05.614441175 +0200 +++ build/uniphier_v8/.config 2026-04-20 10:41:03.214852130 +0200 @@ -875,4 +874,0 @@ - -# -# Networking -# @@ -880,0 +877 @@ +CONFIG_NET_LEGACY=y """ This is fine: - Networking menu doesn't exist anymore so "#\n# Networking\n#\n" won't be in .config anymore. - opos6uldev, uniphier_ld4_sld8, uniphier_v7 and uniphier_v8 all have (old) CONFIG_NET enabled, (new) CONFIG_NET will still be set but CONFIG_NET_LEGACY also needs to be defined now to reflect the stack choice (even if default), - stemmy has CONFIG_NO_NET set, which means CONFIG_NET and CONFIG_NET_LWIP are not reachable anymore hence why they don't need to be part of .config, GitLab CI was run on this series (well, not exactly, but it's only changes to the git logs that were made): https://source.denx.de/u-boot/contributors/qschulz/u-boot/-/pipelines/29849 It passes. Link: https://lore.kernel.org/r/20260420-net-kconfig-v1-0-9900002d8e72@cherry.de 
Quentin Schulz <foss+uboot@0leil.net> says:

This migrates the net options away from the main Kconfig to net/Kconfig,
rename the current NET option to NET_LEGACY to really highlight what it
is and hopefully encourage more people to use lwIP, add a new NET
menuconfig (but keep NO_NET as an alias to NET=n for now) which then
allows us to replace all the "if legacy_stack || lwip_stack" checks with
"if net_support" which is easier to read and maintain.

The only doubt I have is wrt SYS_RX_ETH_BUFFER which seems to be needed
for now even when no network is configured? Likely due to
include/net-common.h with PKTBUFSRX?

No change in behavior is intended. Only change in defconfig including
other defconfigs where NO_NET=y or NET is not set, in which case NO_NET
is not set or NET=y should be set in the top defconfig. Similar change
required for config fragments. See commit log in patch adding NET
menuconfig for details.

This was tested based on 70fd0c3bb7c2 ("x86: there is no
CONFIG_UBOOT_ROMSIZE_KB_12288"), from within the GitLab CI container
trini/u-boot-gitlab-ci-runner:noble-20251013-23Jan2026 and set up
similarly as in "build all platforms in a single job" GitLab CI job.

 #!/usr/bin/env bash
 set -o pipefail
 set -eux

 ARGS="-BvelPEWM --reproducible-builds --step 0"
 ./tools/buildman/buildman -o ${O} --force-build $ARGS -CE $*
 ./tools/buildman/buildman -o ${O} $ARGS -Ssd $*

O=../build/u-boot/ ../u-boot.sh -b master^..b4/net-kconfig |& tee ../log.txt

I can't really decipher the log.txt, but there's no line starting with
+ which would be an error according to tools/buildman/builder.py help
text. Additionally, because I started the script with set -e set and
because buildman has an exit code != 0 when it fails to build a board,
and I have the summary printed (which is the second buildman call), I
believe it means all builds passed.

The summary is the following:
   aarch64: (for 537/537 boards) all +0.0 rodata +0.0
            uniphier_v8    : all +1 rodata +1
               u-boot: add: 0/0, grow: 1/0 bytes: 1/0 (1)
                 function                                   old     new   delta
                 data_gz                                  10640   10641      +1
       arm: (for 733/733 boards) all -0.0 rodata -0.0
            uniphier_v7    : all -1 rodata -1
               u-boot: add: 0/0, grow: 0/-1 bytes: 0/-1 (-1)
                 function                                   old     new   delta
                 data_gz                                  11919   11918      -1
            opos6uldev     : all -3 rodata -3
               u-boot: add: 0/0, grow: 0/-1 bytes: 0/-3 (-3)
                 function                                   old     new   delta
                 data_gz                                  18778   18775      -3
            uniphier_ld4_sld8: all -3 rodata -3
               u-boot: add: 0/0, grow: 0/-1 bytes: 0/-3 (-3)
                 function                                   old     new   delta
                 data_gz                                  11276   11273      -3
            stemmy         : all -20 rodata -20
               u-boot: add: 0/0, grow: 0/-1 bytes: 0/-20 (-20)
                 function                                   old     new   delta
                 data_gz                                  15783   15763     -20

As far as I could tell this data_gz is an automatically generated array
when CONFIG_CMD_CONFIG is enabled. It is the compressed .config stored
in binary form. Because I'm changing the name of symbols, replacing a
menu with a menuconfig, additional text makes it to .config and the
"# Networking" section in .config disappears.

Here is the diff for the 5 defconfigs listed above, generated with:

for f in build/*-m; do
	diff --unified=0 $f/.config $(dirname $f)/$(basename -a -s '-m' $f)/.config
done

(-m is the build directory for master, and without the suffix, it's the
top commit of this series)

"""
 --- build/opos6uldev-m/.config	2026-04-20 10:53:49.804528526 +0200
 +++ build/opos6uldev/.config	2026-04-20 11:03:37.430242767 +0200
 @@ -970,4 +969,0 @@
 -
 -#
 -# Networking
 -#
 @@ -975,0 +972 @@
 +CONFIG_NET_LEGACY=y
 --- build/stemmy-m/.config	2026-04-20 11:01:33.653698123 +0200
 +++ build/stemmy/.config	2026-04-20 11:04:53.452577311 +0200
 @@ -733,4 +732,0 @@
 -
 -#
 -# Networking
 -#
 @@ -738,2 +733,0 @@
 -# CONFIG_NET is not set
 -# CONFIG_NET_LWIP is not set
 --- build/uniphier_ld4_sld8-m/.config	2026-04-20 11:00:41.605469071 +0200
 +++ build/uniphier_ld4_sld8/.config	2026-04-20 11:04:22.226439899 +0200
 @@ -997,4 +996,0 @@
 -
 -#
 -# Networking
 -#
 @@ -1002,0 +999 @@
 +CONFIG_NET_LEGACY=y
 --- build/uniphier_v7-m/.config	2026-04-20 10:53:04.019307319 +0200
 +++ build/uniphier_v7/.config	2026-04-20 11:03:01.688085486 +0200
 @@ -1004,4 +1003,0 @@
 -
 -#
 -# Networking
 -#
 @@ -1009,0 +1006 @@
 +CONFIG_NET_LEGACY=y
 --- build/uniphier_v8-m/.config	2026-04-20 10:43:05.614441175 +0200
 +++ build/uniphier_v8/.config	2026-04-20 10:41:03.214852130 +0200
 @@ -875,4 +874,0 @@
 -
 -#
 -# Networking
 -#
 @@ -880,0 +877 @@
 +CONFIG_NET_LEGACY=y
"""

This is fine:
- Networking menu doesn't exist anymore so "#\n# Networking\n#\n" won't
  be in .config anymore.
- opos6uldev, uniphier_ld4_sld8, uniphier_v7 and uniphier_v8 all have
  (old) CONFIG_NET enabled, (new) CONFIG_NET will still be set but
  CONFIG_NET_LEGACY also needs to be defined now to reflect the stack
  choice (even if default),
- stemmy has CONFIG_NO_NET set, which means CONFIG_NET and
  CONFIG_NET_LWIP are not reachable anymore hence why they don't need to
  be part of .config,

GitLab CI was run on this series (well, not exactly, but it's only
changes to the git logs that were made):
https://source.denx.de/u-boot/contributors/qschulz/u-boot/-/pipelines/29849

It passes.

Link: https://lore.kernel.org/r/20260420-net-kconfig-v1-0-9900002d8e72@cherry.de
boot: remove NO_NET use 2026-04-27T17:26:40+00:00 Quentin Schulz quentin.schulz@cherry.de 2026-04-20T11:36:12+00:00 b06c5ef4ddf051b0da8276d2a00ee3df037cbf2f NO_NET is now a transitional symbol which may eventually be removed. Its meaning is the opposite of the new meaning of NET (that is, any networking stack). Update the symbol dependency by using NET instead of !NO_NET. Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Peter Robinson <pbrobinson@gmail.com> Reviewed-by: Tom Rini <trini@konsulko.com> 
NO_NET is now a transitional symbol which may eventually be removed. Its
meaning is the opposite of the new meaning of NET (that is, any
networking stack).

Update the symbol dependency by using NET instead of !NO_NET.

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
boot/fit: fix misleading comment 2026-04-21T21:56:43+00:00 Julien Stephan jstephan@baylibre.com 2026-04-09T13:15:43+00:00 86122451b5b987a41a149e385f09d8335348bebe When load address is specified but set to 0, we ignore it and load in place instead. The current comment is misleading, so update it. Signed-off-by: Julien Stephan <jstephan@baylibre.com> 
When load address is specified but set to 0, we ignore it and load in
place instead. The current comment is misleading, so update it.

Signed-off-by: Julien Stephan <jstephan@baylibre.com>
bootstd: efi: Handle prior-stage FDT in network path 2026-04-17T06:09:41+00:00 Simon Glass sjg@chromium.org 2026-04-05T11:34:32+00:00 ee4bcfc65971730dc2fe137877e620f19a2f8e93 When CONFIG_OF_HAS_PRIOR_STAGE is enabled and fdtfile is not set, efi_get_distro_fdt_name() returns -EALREADY to indicate the prior-stage FDT should be used. The block-device EFI path handles this by setting BOOTFLOWF_USE_PRIOR_FDT, but the network path treats it as an error, causing the bootflow to stay in 'base' state with a -EALREADY error. This also means fdt_addr_r is required even when no FDT download is needed, giving a spurious -EINVAL error. Fix this by calling efi_get_distro_fdt_name() before checking fdt_addr_r, and handling -EALREADY by setting BOOTFLOWF_USE_PRIOR_FDT to skip the FDT download, matching the block-device behaviour. THere is no test for this at present, since sandbox does not enable CONFIG_OF_HAS_PRIOR_STAGE and lacks infra for network-based EFI boot. Signed-off-by: Simon Glass <sjg@chromium.org> 
When CONFIG_OF_HAS_PRIOR_STAGE is enabled and fdtfile is not set,
efi_get_distro_fdt_name() returns -EALREADY to indicate the prior-stage
FDT should be used. The block-device EFI path handles this by setting
BOOTFLOWF_USE_PRIOR_FDT, but the network path treats it as an error,
causing the bootflow to stay in 'base' state with a -EALREADY error.

This also means fdt_addr_r is required even when no FDT download is
needed, giving a spurious  -EINVAL error.

Fix this by calling efi_get_distro_fdt_name() before checking
fdt_addr_r, and handling -EALREADY by setting BOOTFLOWF_USE_PRIOR_FDT
to skip the FDT download, matching the block-device behaviour.

THere is no test for this at present, since sandbox does not enable
CONFIG_OF_HAS_PRIOR_STAGE and lacks infra for network-based EFI boot.

Signed-off-by: Simon Glass <sjg@chromium.org>
lmb: boot: Update dependencies within BOOT_DEFAULTS_CMDS 2026-04-07T17:32:29+00:00 Tom Rini trini@konsulko.com 2026-03-23T19:52:47+00:00 a6594e82bb93bc14d97ca16440f6387fa3e0c111 The CMD_BOOT[IZ] symbols have a dependency on LMB, correctly, currently. Make sure that in BOOT_DEFAULTS_CMDS we only select these commands if LMB is enabled. Signed-off-by: Tom Rini <trini@konsulko.com> 
The CMD_BOOT[IZ] symbols have a dependency on LMB, correctly,
currently. Make sure that in BOOT_DEFAULTS_CMDS we only select these
commands if LMB is enabled.

Signed-off-by: Tom Rini <trini@konsulko.com>
Merge branch 'next' 2026-04-06T18:16:57+00:00 Tom Rini trini@konsulko.com 2026-04-06T18:16:57+00:00 93f84ee022a8401421cdaab84fe7d106d83fdb4a 






boot: Add DM_RTC as a dependency to CEDIT
2026-04-03T19:42:49+00:00

Tom Rini
trini@konsulko.com

2026-03-20T20:53:43+00:00

70b5afb90579b7c1f5c9ce894f8536c051ff8f73

The CEDIT functionality, due to the cmos functions, depends directly on
DM_RTC being enabled in order to provide that API. Express this in
Kconfig as well.

Signed-off-by: Tom Rini <trini@konsulko.com>





The CEDIT functionality, due to the cmos functions, depends directly on
DM_RTC being enabled in order to provide that API. Express this in
Kconfig as well.

Signed-off-by: Tom Rini <trini@konsulko.com>







lmb: Correct dependency around CMD_BOOT[IMZ]
2026-04-03T19:42:49+00:00

Tom Rini
trini@konsulko.com

2026-03-20T20:53:40+00:00

5116481a7e604bf0985417f30d1a6fcbc89067b5

The calls around lmb functions for these commands are not specific to
SYS_BOOT_RAMDISK_HIGH but rather part of the general loading portion of
the command itself currently. Move this dependency to the right spot.

Signed-off-by: Tom Rini <trini@konsulko.com>





The calls around lmb functions for these commands are not specific to
SYS_BOOT_RAMDISK_HIGH but rather part of the general loading portion of
the command itself currently. Move this dependency to the right spot.

Signed-off-by: Tom Rini <trini@konsulko.com>