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

607b07554e2 removed the check on the return status of the
android_image_get_dtb_img_addr call from android_image_get_dtb_by_index,
which results in null pointer accesses shortly after when trying to
check the header of a nonexistent DTB.

Fixes: 607b07554e2 ("android: boot: move to andr_image_data structure")
Signed-off-by: Sam Day <me@samcday.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Link: https://lore.kernel.org/r/20250123-android-handle-no-dtb-v1-1-1cb7373247da@samcday.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>

kcmdline and kcmdline_extra strings can be NULL. In that case, we still
read the content from 0x00000 and pass that to the kernel, which is
completely wrong.

Fix android_image_get_kernel() to check for NULL before checking if
they are empty strings.

Fixes: 53a0ddb6d3be ("boot: android: fix extra command line support")
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Reviewed-by: Nicolas Belin <nbelin@baylibre.com>
Reviewed-by: Julien Masson <jmasson@baylibre.com>
Tested-by: Sam Day <me@samcday.com>
Link: https://lore.kernel.org/r/20250113-kcmdline-extra-fix-v1-1-03cc9c039159@baylibre.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>

Prepare v2025.01-rc5

Rework the bootargs concatenation allocating more accurately
the length that is needed.
Do not forget an extra byte for the null termination byte as,
in some cases, the allocation was 1 byte short.

Fixes: 86f4695b ("image: Fix Android boot image support")
Signed-off-by: Nicolas Belin <nbelin@baylibre.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Link: https://lore.kernel.org/r/20241217-fix-bootargs-concatenation-v2-3-b2fd7cf4e130@baylibre.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>

Free newbootargs when the concatenation is done and bootargs env
is set.

Fixes: 86f4695b ("image: Fix Android boot image support")
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Signed-off-by: Nicolas Belin <nbelin@baylibre.com>
Link: https://lore.kernel.org/r/20241217-fix-bootargs-concatenation-v2-2-b2fd7cf4e130@baylibre.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>

Check that the value at the address kcmdline_extra is not 0
instead of checking the address value itself keeping it
consistent with what is done for kcmdline.

Fixes: b36b227b ("android: boot: support extra command line")
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Signed-off-by: Nicolas Belin <nbelin@baylibre.com>
Link: https://lore.kernel.org/r/20241217-fix-bootargs-concatenation-v2-1-b2fd7cf4e130@baylibre.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>

The current implementation is reading the whole partition for boot and
vendor_boot image which can be long following the size of the
partition or the time to read blocks (driver/SoC specific).

For example with mediatek mt8365 EVK board, we have a 64MiB boot
partition and the boot image flashed in this partition is only 42MiB.
It takes ~8-9 secs to read the boot partition.

Instead we can retrieved the boot image and vendor boot image size
with these new functions:
- android_image_get_bootimg_size
- android_image_get_vendor_bootimg_size
Use these information and read only the necessary.

By doing this with mt8365 EVK board, we read boot image in ~5 secs.

Signed-off-by: Julien Masson <jmasson@baylibre.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Link: https://lore.kernel.org/r/20241121-bootmeth-android-part-sizes-v1-1-25760bbd0f08@baylibre.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>

The two tools that create android boot images, mkbootimg and the fastboot
client, set the kernel address by default to 0x11008000.

U-boot always honors this field, and will try to copy the ramdisk to
whatever value is set in the header, which won't be mapped to the actual
RAM on most platforms, resulting in the kernel obviously not booting.

All the targets in U-Boot right now will download the android boot image
to CONFIG_SYS_LOAD_ADDR, which means that it will already have been
downloaded to some location that is suitable to use the ramdisk in-place
for header version 0 to 2. For header version 3 and later, the ramdisk
can't be used in-place to use ramdisk_addr_r in this case.

Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Guillaume La Roque <glaroque@baylibre.com>
Link: https://lore.kernel.org/r/20241017-topic-fastboot-fixes-mkbootimg-v2-3-c3927102d931@linaro.org
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>

When trying to boot an android boot image with a compressed
kernel, if the kernel is used in-place because it was created
with mkbootimg, the space will be too small to properly
uncompress.

Take in account the compressed state, and if compressed
use the kernel_addr_r which should be big enough.

Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Guillaume La Roque <glaroque@baylibre.com>
Link: https://lore.kernel.org/r/20241017-topic-fastboot-fixes-mkbootimg-v2-2-c3927102d931@linaro.org
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>