A FIT image which is NOT using -E when created by mkimage - that is with image data within the FIT - will fail to apply FDTO if the base FDT image node does not specify a load property (which points to an address in DRAM). This is because we check that the FDT address we want to apply overlay to (i.e. modify and likely increase in size) is not inside the FIT and give up otherwise. This is assumed necessary because we may then overwrite other data when applying in-place. However, we can do better than giving up: relocating the FDT in another place in DRAM where it's safe to increase its size and apply FDTOs. While at it, do not discriminate anymore on whether the data is within the FIT data address space - that is FIT images created with mkimage -E - as that still may be susceptible to unintended data overwrites as mkimage -E simply concatenates all blobs after the FIT. If the FDT blob isn't the last, it'll result in overwriting later blobs when resizing. The side effect is that the load property in the FIT is only temporarily used to load the FDT but then relocated right before we start applying overlays. Suggested-by: Marek Vasut <marex@denx.de> Reviewed-by: Marek Vasut <marex@denx.de> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
So far only VBE-simple is implemented in U-Boot. This supports a single image which can be updated in situ. It is often necessary to support two images (A and B) so that the board is not bricked if the update is interrupted or is bad. In some cases, a non-updatable recovery image is desirable, so that the board can be returned to a known-good state in the event of a serious failure. Introduce ABrec which provides these features. It supports three independent images and the logic to select the desired one on boot. While we are here, fix a debug message to indicate the function it called. Provide a maintainers entry for VBE. Note that fwupdated only supports VBE-simple so far, but supports for ABrec will appear in time. Signed-off-by: Simon Glass <sjg@chromium.org>
When VBE operates within VPL it does not want the FDT to be changed. Provide a way to disable this feature. Move the FIT_IMAGE_TINY condition out of spl_fit_record_loadable() so that both conditions are together. This makes the code easier to understand. Replace the existing fit_loaded member, which is no-longer used. Signed-off-by: Simon Glass <sjg@chromium.org>
Join the comment block for the fit_image_load() call back to where it should be. Also fix a debug statement. Signed-off-by: Simon Glass <sjg@chromium.org>
With SPL we want to specify the phase of the image to be loaded. Add support for this. This is the implementation of a FIT feature added to the spec a few years ago and entails a small code-size increase, about 70 bytes on Thumb2. Signed-off-by: Simon Glass <sjg@chromium.org> Link: https://docs.u-boot.org/en/latest/usage/fit/index.html
Finish off the implementation so it is possible to boot an EFI app over a network. Signed-off-by: Simon Glass <sjg@chromium.org>
Rather than setting up the global variables and then making the call, pass them into function directly. This cleans up the code and makes it all a bit easier to understand. Signed-off-by: Simon Glass <sjg@chromium.org>
When the bootloader is UNLOCKED, it should be possible to boot Android
even if AVB reports verification errors [1].
This allows developers to flash modified partitions on
userdebug/engineering builds.
Developers can do so on unlocked devices with:
$ fastboot flash --disable-verity --disable-verification vbmeta vbmeta.img
In such case, bootmeth_android refuses to boot.
Allow the boot to continue when the device is UNLOCKED and AVB reports
verification errors.
[1] https://source.android.com/docs/security/features/verifiedboot/boot-flow#unlocked-devices
Fixes: 125d9f3306ea ("bootstd: Add a bootmeth for Android")
Reviewed-by: Julien Masson <jmasson@baylibre.com>
Link: https://lore.kernel.org/r/20250108-avb-disable-verif-v2-2-ba7d3b0d5b6a@baylibre.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
When booting an Android build with AVB enabled, it's still possible to
deactivate the check for development purposes if the bootloader state is
UNLOCKED.
This is very useful for development and can be done at flashing time via:
$ fastboot flash --disable-verity --disable-verification vbmeta vbmeta.img
However, with bootmeth_android, we cannot boot this way:
Scanning bootdev 'mmc@fa10000.bootdev':
0 android ready mmc 0 mmc@fa10000.bootdev.whole
** Booting bootflow 'mmc@fa10000.bootdev.whole' with android
avb_vbmeta_image.c:188: ERROR: Hash does not match!
avb_slot_verify.c:732: ERROR: vbmeta_a: Error verifying vbmeta image: HASH_MISMATCH
get_partition: can't find partition '_a'
avb_slot_verify.c:496: ERROR: _a: Error determining partition size.
Verification failed, reason: I/O error occurred while trying to load data
Boot failed (err=-5)
No more bootdevs
From the logs we can see that avb tries to read a partition named '_a'.
It's doing so because the last element of requested_partitions implicitly is
'\0', but the doc explicitly request it to be NULL instead.
Add NULL as last element to requested_partitions to avoid this problem.
Fixes: 125d9f3306ea ("bootstd: Add a bootmeth for Android")
Reviewed-by: Julien Masson <jmasson@baylibre.com>
Link: https://lore.kernel.org/r/20250108-avb-disable-verif-v2-1-ba7d3b0d5b6a@baylibre.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>