u-boot.git/boot/image-android.c, branch v2025.01

boot: android: rework bootargs concatenation

2024-12-18T13:04:23+00:00

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 
Reviewed-by: Mattijs Korpershoek 
Link: https://lore.kernel.org/r/20241217-fix-bootargs-concatenation-v2-3-b2fd7cf4e130@baylibre.com
Signed-off-by: Mattijs Korpershoek

boot: android: free newbootargs when done

2024-12-18T13:04:23+00:00

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

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

boot: android: fix extra command line support

2024-12-18T13:04:23+00:00

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 
Signed-off-by: Nicolas Belin 
Link: https://lore.kernel.org/r/20241217-fix-bootargs-concatenation-v2-1-b2fd7cf4e130@baylibre.com
Signed-off-by: Mattijs Korpershoek

image: android: handle ramdisk default address

2024-10-24T07:48:14+00:00

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 
Reviewed-by: Mattijs Korpershoek 
Tested-by: Guillaume La Roque 
Link: https://lore.kernel.org/r/20241017-topic-fastboot-fixes-mkbootimg-v2-3-c3927102d931@linaro.org
Signed-off-by: Mattijs Korpershoek

image: android: do not boot XIP when kernel is compressed

2024-10-24T07:48:14+00:00

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 
Reviewed-by: Mattijs Korpershoek 
Tested-by: Guillaume La Roque 
Link: https://lore.kernel.org/r/20241017-topic-fastboot-fixes-mkbootimg-v2-2-c3927102d931@linaro.org
Signed-off-by: Mattijs Korpershoek

image: android: use ulong for kernel address

2024-10-24T07:48:14+00:00

When booting with platforms having > 4GiB of memory,
the kernel physical address can be more than 32bits.

Use ulong like all the other addresses, and fix the
print to show the > 32bits address numbers.

Signed-off-by: Neil Armstrong 
Reviewed-by: Mattijs Korpershoek 
Tested-by: Guillaume La Roque 
Link: https://lore.kernel.org/r/20241017-topic-fastboot-fixes-mkbootimg-v2-1-c3927102d931@linaro.org
Signed-off-by: Mattijs Korpershoek

Merge patch series "Tidy up use of 'SPL' and CONFIG_SPL_BUILD"

2024-10-11T18:23:25+00:00

Simon Glass  says:

When the SPL build-phase was first created it was designed to solve a
particular problem (the need to init SDRAM so that U-Boot proper could
be loaded). It has since expanded to become an important part of U-Boot,
with three phases now present: TPL, VPL and SPL

Due to this history, the term 'SPL' is used to mean both a particular
phase (the one before U-Boot proper) and all the non-proper phases.
This has become confusing.

For a similar reason CONFIG_SPL_BUILD is set to 'y' for all 'SPL'
phases, not just SPL. So code which can only be compiled for actual SPL,
for example, must use something like this:

   #if defined(CONFIG_SPL_BUILD) && !defined(CONFIG_TPL_BUILD)

In Makefiles we have similar issues. SPL_ has been used as a variable
which expands to either SPL_ or nothing, to chose between options like
CONFIG_BLK and CONFIG_SPL_BLK. When TPL appeared, a new SPL_TPL variable
was created which expanded to 'SPL_', 'TPL_' or nothing. Later it was
updated to support 'VPL_' as well.

This series starts a change in terminology and usage to resolve the
above issues:

- The word 'xPL' is used instead of 'SPL' to mean a non-proper build
- A new CONFIG_XPL_BUILD define indicates that the current build is an
  'xPL' build
- The existing CONFIG_SPL_BUILD is changed to mean SPL; it is not now
  defined for TPL and VPL phases
- The existing SPL_ Makefile variable is renamed to SPL_
- The existing SPL_TPL Makefile variable is renamed to PHASE_

It should be noted that xpl_phase() can generally be used instead of
the above CONFIGs without a code-space or run-time penalty.

This series does not attempt to convert all of U-Boot to use this new
terminology but it makes a start. In particular, renaming spl.h and
common/spl seems like a bridge too far at this point.

The series is fully bisectable. It has also been checked to ensure there
are no code-size changes on any commit.

global: Use CONFIG_XPL_BUILD instead of CONFIG_SPL_BUILD

2024-10-11T17:44:48+00:00

Complete this rename for all directories outside arch/ board/ drivers/
and include/

Use the new symbol to refer to any 'SPL' build, including TPL and VPL

Signed-off-by: Simon Glass

boot: android: Fix ramdisk loading for v2 header

2024-10-03T17:30:25+00:00

Before
commit da3447d09fa0 ("android: Fix ramdisk loading for bootimage v3+"),
the ramdisk was loaded from img_data.ramdisk_ptr, ignoring offset
provided via mkbootimg.

commit da3447d09fa0 ("android: Fix ramdisk loading for bootimage v3+")
rightfully fixes this by switching to use img_data.ramdisk_addr instead.

However, it does not copy the ramdisk content to img_data.ramdisk_addr
in case we use boot image v2.

Because of this, we can no longer boot Android on Khadas vim3 board:

[    3.940361] RAMDISK: Couldn't find valid RAM disk image starting at 0.

Add the missing memcpy() to fix the issue.

Fixes: da3447d09fa0 ("android: Fix ramdisk loading for bootimage v3+")
Signed-off-by: Mattijs Korpershoek

boot: android: fix booting without a ramdisk

2024-08-22T07:23:33+00:00

android_image_get_ramdisk() will return an error if there is no ramdisk.
Using the android image without a ramdisk worked until commit
1ce8e10f3b4b ("image: Fix up ANDROID_BOOT_IMAGE ramdisk code") because
the return code wasn't checked until then. Return -ENOENT in case
there is no ramdisk and translate that into -ENOPKG in the calling
code, which will then indicate "no ramdisk" to its caller
(boot_get_ramdisk()).

This way, we can get rid of the "*rd_data = *rd_len = 0;" in the error
path, too.

With this, I'm able to boot a linux kernel using fastboot again:

  fastboot --base 0x41000000 --header-version 2 --dtb /path/to/dtb \
  --cmdline "root=/dev/mmcblk0p1 rootwait" boot path/to/Image

Signed-off-by: Michael Walle 
Reviewed-by: Mattijs Korpershoek 
Reviewed-by: Simon Glass 
Link: https://lore.kernel.org/r/20240729213657.2550935-1-mwalle@kernel.org
Signed-off-by: Mattijs Korpershoek