| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
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>
|
|
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>
|
|
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 <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-1-c3927102d931@linaro.org
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
|
|
Simon Glass <sjg@chromium.org> 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.
|
|
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 <sjg@chromium.org>
|
|
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 <mkorpershoek@baylibre.com>
|
|
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 <mwalle@kernel.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Link: https://lore.kernel.org/r/20240729213657.2550935-1-mwalle@kernel.org
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
|
|
When calling android_image_get_dtb_by_index() using boot image v3+,
we should also pass the vendor_boot ramdisk address.
Use get_avendor_bootimg_addr() to do so.
Notes: on boot image v2, this is harmless since get_avendor_bootimg_addr()
returns -1.
for legacy implementations that don't have CMD_ABOOTIMG, add a weak
implementation to avoid linking errors.
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Julien Masson <jmasson@baylibre.com>
Reviewed-by: Igor Opaniuk <igor.opaniuk@gmail.com>
Reviewed-by: Guillaume La Roque <glaroque@baylibre.com>
Tested-by: Guillaume La Roque <glaroque@baylibre.com>
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
|
|
The boot_ramdisk and vendor_ramdisk must be both concatenated together.
Without this change, Android root is missing some of the necessary tools
to complete virtual AB OTA.
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
|
|
As part of bringing the master branch back in to next, we need to allow
for all of these changes to exist here.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.
This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing
changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
Remove <common.h> from all "boot/" files and when needed add
missing include files directly.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
Support Bootconfig feature.
- The bootconfig feature replaces the androidboot.*
kernel cmdline options.
This was adapted from downstream [1] commit : 7af0a0506d4d ("cuttlefish:
support bootconfig parameters").
Link:[1] https://android.googlesource.com/platform/external/u-boot/
Signed-off-by: Safae Ouajih <souajih@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
|
|
Enable the support for boot image header version 3 and 4
using abootimg command.
In order to use version 3 or 4:
1- Vendor boot image address should be given to abootimg cmd.
abootimg addr $1 $vendor_boot_load_addr
2- "ramdisk_addr_r" env variable (ramdisk address) should be set to host
the ramdisk : generic ramdisk + vendor ramdisk
Replace "struct andr_boot_img_hdr_v0*" by "void *" in
some functions since v3 and v4 are now supported as well.
Signed-off-by: Safae Ouajih <souajih@baylibre.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
|
|
Add support for boot image version 3 and 4 in
android_image_get_dtb_img_addr().
Since the dtb is now included in vendor_boot image
instead of boot image, extract the dtb address from
vendor_boot image when a v3 or v4 is used.
Signed-off-by: Safae Ouajih <souajih@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
|
|
In version 3 and 4 of boot image header, the vendor specific
command line are located in vendor boot image. Thus, use
extra command line to add those cmd to bootargs.
Signed-off-by: Safae Ouajih <souajih@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
|
|
Version 3 and 4 of boot image header introduced
vendor boot ramdisk: Please check include/android_image.h
for details.
The ramdisk is now split into a generic ramdisk in boot image
and a vendor ramdisk in vendor boot image.
Support the new vendor ramdisk.
Signed-off-by: Safae Ouajih <souajih@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
|
|
Since boot image header version 3 and 4 introduced vendor boot image,
use the following functions to fill the generic android
structure : andr_image_data:
- android_boot_image_v3_v4_parse_hdr()
- android_vendor_boot_image_v3_v4_parse_hdr()
Update android_image_get_data() to support v3 and v4
Signed-off-by: Safae Ouajih <souajih@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
|
|
Introduce vendor boot image for version 3 and 4 of boot image header.
The vendor boot image will hold extra information about kernel, dtb
and ramdisk.
This is done to prepare for boot image version 3 and 4 support.
Signed-off-by: Safae Ouajih <souajih@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
|
|
android_image_get_dtbo() is used to get recovery DTBO via abootimg cmd.
This is not supported in boot image header v3 and v4. Thus, print an
error message when v1,v2 header version are not used.
Signed-off-by: Safae Ouajih <souajih@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
|
|
Content print is not supported for version 3 and 4 of boot image header.
Thus, only print that content when v2 is used.
Update android_print_contents() to print an error message
when trying to print boot image header version 3 or 4 content.
Signed-off-by: Safae Ouajih <souajih@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
|
|
Move from andr_boot_img_hdr_v0 to andr_image_data
structure to prepare for boot image header
version 3 and 4.
Signed-off-by: Safae Ouajih <souajih@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
|
|
andr_image_data structure is used as a global representation of
boot image header structure. Introduce this new structure to
support all boot header versions : v0,v1.v2.v3.v4 and to support
v3 and v4 while maitaining support for v0,v1,v2.
The need of using andr_image_data comes from the change of header
structure in both version 3 and 4.
Rework android_image_get_kcomp() to support this new struct.
Signed-off-by: Safae Ouajih <souajih@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
|
|
With the new vendor boot image introduced in versions 3 and 4
of boot image header, the header check must be done for both boot
image and vendor boot image. Thus, replace android_image_check_header()
by is_android_boot_image_header() to only refer to boot image header check.
Signed-off-by: Safae Ouajih <souajih@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
|
|
Android introduced boot header version 3 or 4.
The header structure change with version 3 and 4 to support
the new updates such as:
- Introducing Vendor boot image: with a vendor ramdisk
- Bootconfig feature (v4)
Change andr_img_hdr struct name to maintain support for version v0,
v1 and v2 while introducing version 3 and 4.
Signed-off-by: Safae Ouajih <souajih@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
|
|
This is not needed and we should avoid typedefs. Use the struct instead
and rename it to indicate that it really is a legacy struct.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Quite a lot of the code in common/relates to booting and images. Before
adding more it seems like a good time to move the code into its own
directory.
Most files with 'boot' or 'image' in them are moved, except:
- autoboot.c which relates to U-Boot automatically running a script
- bootstage.c which relates to U-Boot timing
Drop the removal of boot* files from the output directory, since this
interfers with the symlinks created by tools and there does not appear
to be any such file from my brief testing.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Artem Lapkin <email2tema@gmail.com>
Tested-by: Artem Lapkin <email2tema@gmail.com>
|
