We will want to use this same logic in another place within iter_inc(),
so split it out into its own function.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Add a few comments about global bootmeths and first_glob_method
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
Today, only a few platforms enable SPL_LOAD_FIT_FULL, and all enable
SPL_LOAD_FIT. As can be seen in usage, the FULL symbol is a superset of
the first symbol, not an alternative. Update Kconfig entries based on
this and simplify the only code which checks for either being set.
Signed-off-by: Tom Rini <trini@konsulko.com>
If there is no more active slot found in find_active_slot(), like when
all slots in BOOT_ORDER have a count of 0, the counters are reset to their
default value CONFIG_BOOTMETH_RAUC_DEFAULT_TRIES. The BOOT_ORDER is _not_
changed, which is logically correct (especially for the case when there is
only one (active) slot set, e.g. BOOT_ORDER only contains 'B', probably due
to RAUC option prevent-late-fallback being set). Resetting the counters of
inactive slots also does not harm here, and is fine as a generic solution.
But the log_info statement in this scenario
INFO: Resetting boot order and all slot tries
is incorrect. Change this to
INFO: Resetting all slot tries to 3
with the 3 being inserted by CONFIG_BOOTMETH_RAUC_DEFAULT_TRIES.
Signed-off-by: Andreas Pretzsch <apr@cn-eng.de>
Reviewed-by: Martin Schwan <m.schwan@phytec.de>
Only PowerPC and LS1021A platforms can make use of RAMBOOT_PBL. Add the
dependencies to the symbol.
Signed-off-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
We have a large number of library symbols that should not be prompted
for by the user really but rather selected by the platform (or SoC) as
needed. To start with however, make these depend on !COMPILE_TEST.
Signed-off-by: Tom Rini <trini@konsulko.com>
This reverts commit 9fe2e4b46458f9c4ec6b8115ebf18b4b26fe6127.
Commit 9fe2e4b46458 ("fdt: Make sure there is no stale initrd left")
introduces a regression in case when U-Boot transfers control to an EFI
app which acts as a subsequent bootloading program. Such an app might
try to set "linux,initrd-start" and "linux,initrd-end" fdt properties,
but by that time those properties are already removed by the code added
in the mentioned commit.
Particularly, the issue was observed on the E850-96 board where GBL EFI
app [1] can't run Android successfully anymore. More specifically, the
kernel can't see the ramdisk and panics with next messages:
/dev/root: Can't open blockdev
VFS: Cannot open root device "" or unknown-block(0,0): error -6
Please append a correct "root=" boot option; ...
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(0,0)
fdt_initrd() function (where initrd dts properties are removed) is
called two times:
1. First it's called by EFI boot manager (e.g. as a part of U-Boot
Standard Boot mechanism) when it's installing FDT:
fdt_initrd
image_setup_libfdt
efi_install_fdt
efi_bootmgr_run
efi_mgr_boot
It's already enough for EFI app to malfunction. But then it's also
called second time:
2. From the EFI app, via EFI DT fixup protocol:
fdt_initrd
image_setup_libfdt
efi_dt_fixup
struct efi_dt_fixup_protocol efi_dt_fixup_prot = {
.fixup = efi_dt_fixup
};
See [2] for specific GBL code which sets those fdt properties and then
runs DT fixup protocol callback.
This issue was discussed [3], but no action was taken since then. Revert
this patch for now, until a proper solution can be found.
[1] https://source.android.com/docs/core/architecture/bootloader/generic-bootloader/gbl-dev
[2] https://android.googlesource.com/platform/bootable/libbootloader/+/refs/heads/gbl-mainline/gbl/libgbl/src/android_boot/mod.rs#208
[3] https://lists.denx.de/pipermail/u-boot/2025-July/593879.html
Fixes: 9fe2e4b46458 ("fdt: Make sure there is no stale initrd left")
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
The android boot header is page aligned but the current code made the
assumption that the header was always smaller than the current header
format.
When the page_size is defined as 2048, as this is the case with the
cuttlefish target, the current code sets the end of the header in the
middle of it as the v3 and v4 headers are respectively 2112 and 2128
bytes long.
Fix that by aligning to page_size
Fixes: 1115027d2f75 ("android: boot: update android_image_get_data to support v3, v4")
Signed-off-by: Guillaume Ranquet <ranquet.guillaume@gmail.com>
The ARM64 kernel Image size with LOCKDEP enabled is now around 80 MiB, which
makes it unbootable due to "Image too large: increase CONFIG_SYS_BOOTM_LEN".
Increase the image size limit to 128 MiB to future proof the limit.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
At this time there are still major Linux distributions which by default
boot using LEGACY_IMAGE_FORMAT type scripts. Add this option to
DISTRO_DEFAULTS to ensure these platforms can still boot.
Fixes: d780965927d4 ("Drop the special am335x_boneblack_vboot target")
Reported-by: Sascha Silbe <sascha-pgp@silbe.org>
Tested-By: Sascha Silbe <sascha-pgp@silbe.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
Since the bootmeth "rauc" is not a global boot method, do not select the
corresponding BOOTMETH_GLOBAL option.
Signed-off-by: Martin Schwan <m.schwan@phytec.de>
Martin Schwan <m.schwan@phytec.de> says:
This series fixes a segfault, that would occur at the end of scanning a
device, which does not contain the required partition layout scheme for
a RAUC system.
With this series, a "bootflow scan" should now correctly scan the
specified devices with boot method "rauc" without crashing on invalid
partition schemes.
Link: https://lore.kernel.org/r/20250813-wip-bootmeth-rauc-priv-free-v1-0-1ef928169469@phytec.de
The private data struct can be freed when loading the boot script, as we
don't need the slot information anymore at this point.
Signed-off-by: Martin Schwan <m.schwan@phytec.de>
Tested-by: Wadim Egorov <w.egorov@phytec.de>
Move freeing a distro_rauc_priv struct to a new, separate function for
better reuse.
Signed-off-by: Martin Schwan <m.schwan@phytec.de>
Tested-by: Wadim Egorov <w.egorov@phytec.de>
Don't null bootflow->bootmeth_priv, as the private struct is freed later
on by the bootflow.
Signed-off-by: Martin Schwan <m.schwan@phytec.de>
Tested-by: Wadim Egorov <w.egorov@phytec.de>
Fix a segfault when cleaning up the slots from the private struct. This
fault was generated by accessing a member of a null pointer.
Signed-off-by: Martin Schwan <m.schwan@phytec.de>
Tested-by: Wadim Egorov <w.egorov@phytec.de>
The bootmeth rauc should scan all partitions, in particular whole
devices, and not be a global method. There may exist multiple RAUC
systems on different devices and they should all be detected. This also
fixes a bug, where both a global bootflow and one using an actual,
complete device would be detected at the same time, when scanning for
valid bootflows.
Signed-off-by: Martin Schwan <m.schwan@phytec.de>
Tested-by: Wadim Egorov <w.egorov@phytec.de>
This changes the default value to the most commonly used one among
existing defconfigs.
Signed-off-by: Martin Herren <sputnik@on-the-web.ch>
Acked-by: Michal Simek <michal.simek@amd.com> # xilinx_mbv
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
uclass_find_next_device always returns 0, so instead make it a void and
update calling sites.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Only scan for the existence of all required partitions of a RAUC system,
instead of searching for boot script files in all of them.
Previously, it might have occurred, that a slot did not contain required
files and RAUC already marked the corresponding slot as bad (not
suitable for booting). In that case, scanning for a non-existence boot
script would result in an error (and thus not booting anything), which
was different behavior compared to the legacy RAUC boot.
Signed-off-by: Martin Schwan <m.schwan@phytec.de>
Fix a potential segmentation fault, by not accessing the member of a
null pointer to a private slot's name field.
Signed-off-by: Martin Schwan <m.schwan@phytec.de>
Fix a potential memory leak, by checking the return value of realloc
first, before assigning it to the private list of slots.
Signed-off-by: Martin Schwan <m.schwan@phytec.de>
The local variable method_flags is only assigned to in some of the
code paths leaving it possibly uninitialised at first use.
Initialise method_flags at declaration to ensure that it cannot be
used uninitialised. Also remove now redundant assignments.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
When printing the contents of an lbaint_t variable we need to use LBAF
to print it in order to get the correct format type depending on 32 or
64bit-ness. Furthermore, printed message should not be split as that
makes finding them harder, so bring this back to a single line.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Link: https://lore.kernel.org/r/20250702010603.19354-1-trini@konsulko.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
João Paulo Gonçalves <jpaulo.silvagoncalves@gmail.com> says:
In some use cases, board-specific device tree changes must not be overwritten
by system fixups. Although U-Boot provides ft_board_setup_ex() for this
purpose, it is currently only used on TI Keystone. This series makes
ft_board_setup_ex() a generic option, allowing its use by other architectures
and boards.
Additionally, considering that Toradex Verdin-AM62P hardware lifetime
guarantees are based on a 105°C junction temperature (while TI AM62Px supports
up to 125°C), this series implements necessary changes within TI K3 AM62P and
Toradex board code. These changes include exporting common fixup device Tree
functions used in TI K3 for board-code access and also fixup for AM62P thermal
zones to correctly reflect the number of CPU nodes according to the SoC part
number.
Link: https://lore.kernel.org/r/20250623-am62p-fdt-fixup-trip-points-v1-0-12355eb6a72f@toradex.com
In some use cases, board-specific device tree changes must not be
overwritten by system fixups. Although U-Boot provides
ft_board_setup_ex() for this purpose, it is currently only used on TI
Keystone. Make ft_board_setup_ex() to be a generic option, allowing its
use by other architectures/boards. To maintain backward compatibility,
enable it by default on TI Keystone.
Signed-off-by: João Paulo Gonçalves <joao.goncalves@toradex.com>
scene_obj_find can return NULL but this is not checked for before
the return is dereferenced. Add a NULL check.
This issue was found by Smatch.
Also add a NULL check for str.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
In the case where parse_sliteral returns an error then label_name
will not have been assigned to. In order to prevent evaluating
label_name in this case add a check for the return value of parse_sliteral.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Initialise vhdr to prevent its use when uninitialised.
This issue was found with Smatch.
Fixes: e058176be32b (android: boot: add vendor boot image to prepare for v3, v4 support)
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Link: https://lore.kernel.org/r/20250625-abootimg_fix-v4-2-df7af00e87b0@linaro.org
Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
When booting RISC-V ELF-formatted kernel images (IH_TYPE_KERNEL + IH_OS_ELF),
explicitly pass SMP hart ID (via a0/argc) and DTB address (via a1/argv)
to comply with modern SMP-enabled kernels' boot protocol requirements.
See https://www.kernel.org/doc/html/latest/arch/riscv/boot.html#register-state
Signed-off-by: Zone.N <zone.niuzh@hotmail.com>
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>
Some androidboot image have invalid kernel/ramdisk load addr,
force to ignore those value and use loadaddr instead.
There is a concern on exposing the whole memory to image loading is
dangerous. Also, since it's not always possible to change the load
addr by repacking the boot.img (mainly due to AVB signature mismatch),
we need a way to use kernel_addr_r and ramdisk_addr_r.
Suggested-by: Casey Connolly <casey.connolly@linaro.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Tested-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Signed-off-by: George Chan <gchan9527@gmail.com>
Link: https://lore.kernel.org/r/20250518-android-boot-v3-1-02c8768e131f@gmail.com
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
Marek Vasut <marek.vasut+renesas@mailbox.org> says:
Rename the environment related variables and add ENV_ prefix, so that
all configuration options which are related to environment would have
an CONFIG_ENV_ prefix. No functional change.
Link: https://lore.kernel.org/r/20250609192701.20260-1-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.
Also rename USE_DEFAULT_ENV_FILE to USE_ENV_DEFAULT_ENV_TEXT_FILE .
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
There is no such thing as struct bootmeth, it's probably a typo. This
issue doesn't affect the execution as it's a pointer, and pointer sizes
are the same for all data types. But it can be confusing, so make it
struct udevice, as it should be.
Fixes: a950d31abe98 ("bootstd: Add the bootmeth uclass and helpers")
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Specifying efi_mgr in 'bootmeths' environment variable leads to NULL
pointer dereference when 'bootflow scan' is executed, with call trace
like this:
priv->fake_dev // NULL pointer dereference
.read_bootflow = efi_mgr_read_bootflow()
bootmeth_get_bootflow()
bootflow_check()
bootflow_scan_first()
do_bootflow_scan()
'bootflow scan -l'
That happens because in case when 'bootmeths' env var is defined the
bootmeth_efi_mgr driver is not probed, and the memory for its private
data isn't allocated by .priv_auto. In case when 'bootmeths' env var is
not defined, the std->bootmeth_count is 0, and the execution flow in
bootmeth_setup_iter_order() takes "no ordering" path, which in turn runs
uclass_get_device_by_seq() -> ... -> device_probe(), so issue isn't
present there. But when 'bootmeths' is defined and contains efi_mgr, the
std->bootmeth_count > 0, so bootmeth_setup_iter_order() follows the "we
have an ordering" path, where devices are not probed. In other words:
'bootmeths' defined 'bootmeths' not defined
--------------------------------------------------------
priv == NULL priv != NULL
^ ^
| device_alloc_priv()
no probe device_of_to_plat()
^ device_probe()
| uclass_get_device_tail()
dev = order[i] uclass_get_device_by_seq()
^ ^
| have an ordering | no ordering
+----------------+---------------+
|
bootmeth_setup_iter_order()
bootflow_scan_first()
do_bootflow_scan()
Add an explicit device_probe() call in "we have an ordering" case to fix
the issue.
Fixes: c627cfc14c08 ("bootstd: Allow scanning for global bootmeths separately")
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Free memory allocated for 'order' (array of bootmeths) on error paths in
bootmeth_setup_iter_order() function.
Fixes: c627cfc14c08 ("bootstd: Allow scanning for global bootmeths separately")
Fixes: 10d16faa436c ("bootstd: Detect empty bootmeth")
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Martin Schwan <m.schwan@phytec.de> says:
This series implements a new bootmeth for RAUC A/B systems. RAUC (Robust
Auto Update Controller) is a lightweight update client, providing "Safe
and Secure OTA Updates for Embedded Linux". See the following links for
more information about RAUC:
https://rauc.io/https://rauc.readthedocs.io/en/latest/
PHYTEC uses RAUC in its Yocto based distribution "Ampliphy" as the
default way of updating embedded devices based on PHYTEC hardware. So
far, the logic selecting the correct partitions and files to boot was
being implemented in the U-Boot environment. While this is a
straightforward way to do it, adding and supporting new platforms became
somewhat tedious and is platform-specific. The introduction of U-Boot's
"Standard Boot" provided a convincing alternative, promising a simpler
and more portable way of booting, even for RAUC systems. This led me to
implement a new bootmeth supporting RAUC A/B systems. Note, that this
new bootmeth is not proprietary to PHYTEC products and is designed to
work on other hardware with a RAUC A/B system, too.
The bootmeth currently only supports symmetric A/B partitioning layouts.
E.g. A/rescue is not (yet) supported. The partition indexes and default
slot tries can be specified via configuration options.
For now, the bootmeth_rauc uses a similar approach for loading the
Kernel and device tree as the bootmeth_script, in that it requires a FIT
containing a U-Boot script loading the desired distro. It could be
possible to support booting without a script and load the Kernel and DT
directly with this bootmeth, but I found the script method to be very
flexible for now, in letting the distro decide what to load.
The bootmeth_rauc was tested on a phyBOARD-Pollux i.MX8M Plus [1] with
BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2 [2].
Supported boot devices are currently only MMC devices, but it should be
possible to add SPI flashes in the future.
To test this patch stack with PHYTEC's phyBOARD-Pollux i.MX8M Plus
board, you need to adjust the boot files to include the boot.scr.uimg
containing the distro's boot script and set "optargs" to "${raucargs}"
in it. Also disable any legacyboot in the U-Boot environment and simply
boot with Standard Boot:
bootmeth order rauc
bootflow scan -lb
[1]: https://www.phytec.eu/en/produkte/single-board-computer/phyboard-pollux/
[2]: https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2/
Link: https://lore.kernel.org/r/20250604-wip-bootmeth-rauc-v3-0-f9fad913c57e@phytec.de
[trini: Don't enable by default]
Add a bootmeth driver which supports booting A/B system with RAUC as
their update client.
Signed-off-by: Martin Schwan <m.schwan@phytec.de>
Tested-by: Wadim Egorov <w.egorov@phytec.de>
Although if we don't setup an initrd, there could be a stale initrd
setting from the previous boot firmware in the live device tree. So,
make sure there is no setting left if we don't want an initrd.
This can happen when booting on a Raspberry Pi. The boot firmware can
happily load an initrd before us and configuring the addresses in the
live device tree we get handed over.
Especially the setting `auto_initramfs` in config.txt is dangerous.
When enabled (default), the firmware tries to be smart and looks for
initramfs files.
Signed-off-by: Richard Weinberger <richard@nod.at>
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>
This reverts commit 14a4792a71db3561bea065415ac1f2ac69ef32b5 as
discussed in [1].
[1] https://lists.denx.de/pipermail/u-boot/2025-May/590841.html
Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Commit 21e7fa0e3ac5 ("image: android: handle ramdisk default address")
changed the default behavior for header versions less than or equal to 2.
The ramdisk address (img_data.ramdisk_ptr) is only assigned to *rd_data
if the physical load address (img_data.ramdisk_addr) is equal to 0 or
the Android default ramdisk address.
/* Ramdisk can be used in-place, use current ptr */
if (img_data.ramdisk_addr == 0 ||
img_data.ramdisk_addr == ANDROID_IMAGE_DEFAULT_RAMDISK_ADDR) {
*rd_data = img_data.ramdisk_ptr;
} else {
ramdisk_ptr = img_data.ramdisk_addr;
*rd_data = ramdisk_ptr;
memcpy((void *)(ramdisk_ptr), (void *)img_data.ramdisk_ptr,
img_data.ramdisk_size);
}
When the img_data.ramdisk_addr and the img_data.kernel_addr are the same
*rd_data needs to be assigned to the ramdisk address (ramdisk_ptr), not
the physical address (ramdisk_addr).
As a result of the current behavior, we can no longer boot a kernel on
the Renesas R-Car S4 board.
Add an additional check to the if clause so that the ramdisk address is
assigned when the kernel address and the ramdisk address are the same,
restoring the previous default behavior.
Fixes: 21e7fa0e3ac5 ("image: android: handle ramdisk default address")
Signed-off-by: Eddie Kovsky <ekovsky@redhat.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Tested-by: Mattijs Korpershoek <mkorpershoek@kernel.org> # khadas vim3
When building with only bootz command, without bootm, images pointer
inside bootm_info structure is not initialized. And since this structure
is stored in stack, the generated error is kind of random, but most of
the time this will generate: "ramdisk - allocation error".
Also, after analysis, this problem could occur with the command booti,
if the command bootm is disabled.
Currently bootm_init() is called by: do_bootz(), do_bootm(), do_booti()
and by do_stm32prog(). And all of these commands execute bootm_run_states()
which access the images pointer stored into bootm_info structure.
So, to fix this issue, just do the assignment unconditionally.
Fixes: c2211ff65136 ("bootm: Add more fields to bootm_info")
Signed-off-by: Benjamin ROBIN <dev@benjarobin.fr>
Reviewed-by: Tom Rini <trini@konsulko.com>
