Commit graph

85791 commits

Author SHA1 Message Date
Heinrich Schuchardt
120ec1dfa9 ata: don't use SYS_SCSI_MAX_SCSI_ID for SATA
CONFIG_SYS_SCSI_MAX_SCSI_ID is not defined if CONFIG_SCSI=n.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2023-04-06 19:10:08 -04:00
Heinrich Schuchardt
480c1d6725 ata: fix requirements for CONFIG_AHCI_PCI
Building with CONFIG_AHCI_PCI=y and CONFIG_SCSI_AHCI=n leads to

    drivers/ata/ahci-pci.o: in function `ahci_pci_probe':
    drivers/ata/ahci-pci.c:21: undefined reference to `ahci_probe_scsi_pci'

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2023-04-06 19:10:08 -04:00
Corentin Guillevic
1172e258bf spi: Kconfig: add dependency on CONFIG_MPC85xx for FSL_ESPI entry
The Freescale ESPI driver (CONFIG_FSL_ESPI) relies to the MPC85xx platform
(PowerPC) through arch/powerpc/include/asm/immap_85xx.h. The driver can't
compile on another architecture/platform.

Signed-off-by: Corentin Guillevic <corentin.guillevic@smile.fr>
2023-04-06 19:10:08 -04:00
Angelo Dureghello
0e685058db doc: arch: m68k: fix maintainer email
Fix email with currently used address.

Signed-off-by: Angelo Dureghello <angelo@kernel-space.org>
2023-04-06 19:10:08 -04:00
Francis Laniel
5ffcf7c590 arm: lib: add __gnu_thumb1_case_si
The assembly for __gnu_thumb1_case_si was taken from upstream gcc and adapted
as width suffix was removed for the add instruction [1].

Signed-off-by: Francis Laniel <francis.laniel@amarulasolutions.com>
Tested-by: Tony Dinh <mibodhi@gmail.com>
[1] 4f181f9c7e/libgcc/config/arm/lib1funcs.S (L2156)
Acked-by: Pali Rohár <pali@kernel.org>
Acked-by:  Tony Dinh <mibodhi@gmail.com>
2023-04-06 19:10:08 -04:00
Heinrich Schuchardt
16abdd42b3 cmd/regulator: missing fallthrough in do_dev()
Add missing fallthrough macro.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2023-04-06 19:10:08 -04:00
Heinrich Schuchardt
62d92d87f3 cmd: missing fallthrough macro in do_pci()
Add a missing fallthrough macro to avoid a -Wimplicit-fallthrough warning.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2023-04-06 19:10:08 -04:00
Heinrich Schuchardt
06a94b3e8b cmd: convert fallthrough comment.
gcc does not understand /* FALL TROUGH */ and emits a warning:

    cmd/date.c: In function ‘do_date’:
    cmd/date.c:62:20: warning:
    this statement may fall through [-Wimplicit-fallthrough=]
       62 |                 if (strcmp(argv[1],"reset") == 0) {
          |                    ^
    cmd/date.c:102:9: note: here
      102 |         case 1:                 /* get date & time */
          |         ^~~~

Use the fallthrough macro instead.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2023-04-06 19:10:08 -04:00
Heinrich Schuchardt
9ee32a7876 lib: missing fallthrough comment in vsnprintf_internal()
When a case statement intentionally falls through we should add a comment.
Cf. -Wimplicit-fallthrough

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2023-04-06 19:10:08 -04:00
Heinrich Schuchardt
686e9ef605 tools: avoid implicit fallthrough in fdt_add_pubkey
When building with -Wimplicit-fallthrough we get a warning

    tools/fdt_add_pubkey.c:52:25: warning:
    this statement may fall through [-Wimplicit-fallthrough=]
       52 |                         print_help();
          |

Explicitly declare which functions don't return.

Fixes: 30238e9961 ("tools: add fdt_add_pubkey")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2023-04-06 19:10:08 -04:00
Tim Lee
aeb40f1166 tools: env: use /run to store lockfile
According this issue https://github.com/ppp-project/ppp/issues/339.
Eventually, the dt-utils changed lock directory to fix missing /var/lock
directory error then make dt-utils can run normally.

We also have a similar issue with these two utilities fw_printenv and
fw_setenv will failed when the directory /var/lock is non-existent.

We have a custom linux distribution built with yocto (OpenBMC) that
use systemd and it deprecated the /var/lock directory.
More discussion in systemd/systemd#15668.

Thus, we sync with community's solution for uboot/tools/env utilities:
The current location /var/lock is considered legacy (at least by systemd).
Just use /run to store the lockfile and append the usual .lock suffix.

Tested:
Verified /run/lock is now present and fw_printenv can work in OpenBMC.

Signed-off-by: Tim Lee <timlee660101@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
2023-04-06 19:10:05 -04:00
Patrick Delaunay
c9eb37a1e7 lmb: add max number of region in lmb_dump_region() output
Add the max number of region in lmb dump; this patch allows to
check the limit for usage of the LMB regions, memory or reserved.

Result on STM32MP157C-DK2:

STM32MP> bdinfo
.....
lmb_dump_all:
 memory.cnt = 0x1 / max = 0x2
 memory[0]	[0xc0000000-0xdfffffff], 0x20000000 bytes flags: 0
 reserved.cnt = 0x6 / max = 0x10
 reserved[0]	[0x10000000-0x10045fff], 0x00046000 bytes flags: 4
 reserved[1]	[0x30000000-0x3003ffff], 0x00040000 bytes flags: 4
 reserved[2]	[0x38000000-0x3800ffff], 0x00010000 bytes flags: 4
 reserved[3]	[0xd4000000-0xd7ffffff], 0x04000000 bytes flags: 4
 reserved[4]	[0xdcae5000-0xdfffffff], 0x0351b000 bytes flags: 0
 reserved[5]	[0xddafb5b8-0xdfffffff], 0x02504a48 bytes flags: 0
....

Reported-by: Mark Millard <marklmi@yahoo.com>
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2023-04-06 15:08:46 -04:00
Patrick Delaunay
94c8da2121 lmb: Fix LMB_MEMORY_REGIONS flag usage
Remove test on CONFIG_LMB_MEMORY_REGIONS introduced by commit
7c1860fce4 ("lmb: Fix lmb property's defination under struct lmb").

This code in lmb_init() is strange, because if CONFIG_LMB_USE_MAX_REGIONS
and CONFIG_LMB_MEMORY_REGIONS are not defined, the implicit #else is empty
and the required initialization is not done:
lmb->memory.max = ?
lmb->reserved.max = ?

But this setting is not possible:
- CONFIG_LMB_USE_MAX_REGIONS not defined
- CONFIG_LMB_MEMORY_REGIONS not defined
because CONFIG_LMB_MEMORY_REGIONS and CONFIG_LMB_RESERVED_REGIONS are
defined as soon as the CONFIG_LMB_USE_MAX_REGIONS is not defined.

This patch removes this impossible case #elif and I add some
explanation in lmb.h to explain why in the struct lmb {} the lmb
property is defined if CONFIG_LMB_MEMORY_REGIONS is NOT defined.

This patch also removes CONFIG_LMB_XXX dependency on CONFIG_LMB as these
defines are used in API file lmb.h and not only in library file.

Fixes: 5e2548c1d6 ("lmb: Fix LMB_MEMORY_REGIONS flag usage")
Reported-by: Mark Millard <marklmi@yahoo.com>
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Acked-by: Michal Simek <michal.simek@amd.com>
2023-04-06 15:08:46 -04:00
Tom Rini
b0b77fdf3d Merge tag 'fsl-qoriq-2023-4-6' of https://source.denx.de/u-boot/custodians/u-boot-fsl-qoriq
convert NXP LS1028A RDB and QDS to DM_SERIAL
enable DM_SERIAL for ls1088a
sync serial nodes with linux for lx2160a/ls1088a
2023-04-05 22:19:57 -04:00
Tom Rini
487e42f7bc Merge branch '2023-04-05-blkmap-composable-virtual-block-devices'
To quote the author:
Block maps are a way of looking at various sources of data through the
lens of a regular block device. It lets you treat devices that are not
block devices, like RAM, as if they were. It also lets you export a
slice of an existing block device, which does not have to correspond to
a partition boundary, as a new block device.

This is primarily useful because U-Boot's filesystem drivers only
operate on block devices, so a block map lets you access filesystems
wherever they might be located.

The implementation is loosely modeled on Linux's "Device Mapper"
subsystem, see the kernel documentation [1] for more information.

The primary use-cases are to access filesystem images stored in RAM, and
within FIT images stored on disk. See doc/usage/blkmap.rst for more
details.

The architecture is pluggable, so adding other types of mappings should
be quite easy.

[1]: https://docs.kernel.org/admin-guide/device-mapper/index.html
2023-04-05 18:59:47 -04:00
Tobias Waldekranz
272ec6b453 efi_loader: device_path: support blkmap devices
Create a distinct EFI device path for each blkmap device.

Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2023-04-05 10:54:47 -04:00
Tobias Waldekranz
3eee5d073a doc: blkmap: Add introduction and examples
Explain block maps by going through two common use-cases.

Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2023-04-05 10:54:47 -04:00
Tobias Waldekranz
6da06a0338 test: blkmap: Add test suite
Verify that:

- Block maps can be created and destroyed
- Mappings aren't allowed to overlap
- Multiple mappings can be attached and be read/written from/to

Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2023-04-05 10:54:47 -04:00
Tobias Waldekranz
bb56da117f cmd: blkmap: Add blkmap command
Add a frontend for the blkmap subsystem. In addition to the common
block device operations, this allows users to create and destroy
devices, and map in memory and slices of other block devices.

With that we support two primary use-cases:

- Being able to "distro boot" from a RAM disk. I.e., from an image
  where the kernel is stored in /boot of some filesystem supported
  by U-Boot.

- Accessing filesystems not located on exact partition boundaries,
  e.g. when a filesystem image is wrapped in an FIT image and stored
  in a disk partition.

Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2023-04-05 10:54:47 -04:00
Tobias Waldekranz
762dc78bde blk: blkmap: Add linear device mapping support
Allow a slice of an existing block device to be mapped to a
blkmap. This means that filesystems that are not stored at exact
partition boundaries can be accessed by remapping a slice of the
existing device to a blkmap device.

Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2023-04-05 10:54:47 -04:00
Tobias Waldekranz
15d9e99a27 blk: blkmap: Add memory mapping support
Allow a slice of RAM to be mapped to a blkmap. This means that RAM can
now be accessed as if it was a block device, meaning that existing
filesystem drivers can now be used to access ramdisks.

Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2023-04-05 10:54:47 -04:00
Tobias Waldekranz
c41e209ea6 blk: blkmap: Add basic infrastructure
blkmaps are loosely modeled on Linux's device mapper subsystem. The
basic idea is that you can create virtual block devices whose blocks
can be backed by a plethora of sources that are user configurable.

This change just adds the basic infrastructure for creating and
removing blkmap devices. Subsequent changes will extend this to add
support for actual mappings.

Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2023-04-05 10:54:47 -04:00
Tobias Waldekranz
3d2fc79714 cmd: blk: Allow generic read/write operations to work in sandbox
Ensure that the memory destination/source addresses of block
read/write operations are mapped in before access. Currently, this is
only needed on sandbox builds.

Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2023-04-05 10:54:47 -04:00
Tobias Waldekranz
e45bba562f image: Fix script execution from FIT images with external data
Update the script loading code to recognize when script data is stored
externally from the FIT metadata (i.e., built with `mkimage -E`).

Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2023-04-05 10:54:47 -04:00
Tom Rini
25eeda170c Merge branch '2023-04-04-android-image-v3-v4-support'
To quote the author:
* This is based on Roman Stratiienko's work to support boot image header version 3 and 4.

* This supports the new boot image headers v3, v4 and bootconfig feature.
https://source.android.com/docs/core/architecture/bootloader/boot-image-header
https://source.android.com/docs/core/architecture/bootloader/implementing-bootconfig

- Tested on Amlogic Khadas vim3l, a reference board for Android Open Source Project
  https://www.khadas.com/vim3l

  And on AM625 Texas Instruments board with 5.10 linux kernel

Main changes :
- New partition : vendor boot, with a specific vendor ramdisk
- DTB is stored in the vendor boot partition
- The generic ramdisk is placed after the vendor ramdisk
- Bootconfig feature support

Here is a link to see the related android boot flow changes on KHADAS vim3l as an example:
https://gitlab.baylibre.com/baylibre/amlogic/atv/u-boot/-/commits/souajih/BootImagev4/
2023-04-05 10:40:05 -04:00
Safae Ouajih
f444939755 Dockerfile: add mkbootimg tool
mkbootimg tool is part of the Android project and it is
used to pack Android boot images such as boot image
and vendor_boot image.

Use the following command to run mkbootimg:
$ python3 -m mkbootimg

Add mkbootimg to the docker file

Signed-off-by: Safae Ouajih <souajih@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
2023-04-04 14:50:47 -04:00
Safae Ouajih
83d48a3c8b test/py: android: extend abootimg test
test_abootimg is extended to include the testing of boot images
version 4. For this, boot.img and vendor_boot.img have been
generated using mkbootimg tool with setting the header
version to 4.

This tests:
- Getting the header version using abootimg
- Extracting the load address of the dtb
- Extracting the dtb start address in RAM

Running test:
$ ./test/py/test.py --bd sandbox --build -k test_abootimg

Signed-off-by: Safae Ouajih <souajih@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
2023-04-04 14:50:47 -04:00
Safae Ouajih
3e7b71c728 doc: android: add documentation for v3, v4 boot image header
Update the Android documentation to describe version 3 and 4 of boot
image header.

Signed-off-by: Safae Ouajih <souajih@baylibre.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
2023-04-04 14:50:47 -04:00
Safae Ouajih
57e405e1f4 android: boot: support bootconfig
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>
2023-04-04 14:50:47 -04:00
Safae Ouajih
636da2039a android: boot: support boot image header version 3 and 4
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>
2023-04-04 14:50:47 -04:00
Safae Ouajih
bc6413bdd9 drivers: fastboot: zImage flashing is not supported for v3, v4
With vendor boot image introduced in version 3 and 4 of boot
image header, boot information is located in both boot image
and vendor boot image.

Flashing zImage is not supported for version 3 and 4 since this
requires updating vendor boot image and/or generating a new image.

Print an error message when the boot image header version is
greater than 2.

Signed-off-by: Safae Ouajih <souajih@baylibre.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
2023-04-04 14:50:47 -04:00
Safae Ouajih
2d0da1972d android: boot: update android_image_get_dtb_img_addr to support v3, v4
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>
2023-04-04 14:50:47 -04:00
Safae Ouajih
b36b227b6a android: boot: support extra command line
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>
2023-04-04 14:50:47 -04:00
Safae Ouajih
c79a2e6823 android: boot: ramdisk: support vendor ramdisk
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>
2023-04-04 14:50:47 -04:00
Safae Ouajih
1115027d2f android: boot: update android_image_get_data to support v3, v4
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>
2023-04-04 14:50:47 -04:00
Safae Ouajih
e058176be3 android: boot: add vendor boot image to prepare for v3, v4 support
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>
2023-04-04 14:50:47 -04:00
Safae Ouajih
447240e27b android: boot: boot image header v3, v4 do not support recovery DTBO
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>
2023-04-04 14:50:47 -04:00
Safae Ouajih
bb5d692732 android: boot: content print is not supported for v3, v4 header version
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>
2023-04-04 14:50:46 -04:00
Safae Ouajih
607b07554e android: boot: move to andr_image_data structure
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>
2023-04-04 14:50:46 -04:00
Safae Ouajih
f48efa0edb android: boot: kcomp: support andr_image_data
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>
2023-04-04 14:50:46 -04:00
Safae Ouajih
fbb645e7d9 android: boot: add boot image header v3 and v4 structures
Add support for v3/v4 boot image format by adding
the following structures:

- andr_boot_img_hdr_v3 : describes boot image header
- andr_vnd_boot_img_hdr : describes vendor boot image header

These definitions have been copied over from the AOSP documentation at
[1] and [2]

Boot arg sizes are taken from [3]:
commit: 35fb6262bc3f (ANDROID: Support for vendor boot)

This also adds documentation for boot image header v3/v4 structure
that was imported from [4], file: include/bootimg/bootimg.h
commit: 8d0922bfb932 (Adding GKI signature in boot.img v4)

Link:[1] https://source.android.com/docs/core/architecture/bootloader/boot-image-header
Link:[2] https://source.android.com/docs/core/architecture/bootloader/partitions/vendor-boot-partitions#vendor-boot-header
Link:[3] https://android.googlesource.com/platform/external/u-boot
Link:[4] https://android.googlesource.com/platform/system/tools/mkbootimg

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>
2023-04-04 14:50:46 -04:00
Safae Ouajih
734cb47d6d android: boot: replace android_image_check_header
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>
2023-04-04 14:50:46 -04:00
Safae Ouajih
86b62947eb android: boot: support vendor boot image in abootimg
Vendor boot image is introduced in boot image header
version 3 and 4. Please check [1] for more details.

To prepare for boot image v3/v4 support, allow the abootimg command
to store the vendor_boot image address.

Full support for this new format will be done in a future patch.

Link:[1] https://source.android.com/docs/core/architecture/bootloader/partitions/vendor-boot-partitions

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>
2023-04-04 14:50:46 -04:00
Safae Ouajih
d71a732af4 android: boot: rename andr_img_hdr -> andr_boot_img_hdr_v0
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>
2023-04-04 14:50:46 -04:00
Tom Rini
698c2bd364 Merge branch '2023-04-04-update-to-clang-16'
- Update our CI to use clang-16 for tests. This also changes slightly
  how we do linker lists so that we don't rely on undefined behavior
  that lead to clang-15 and later failing to work (and in some cases
  seemingly, earlier versions of clang would sometimes fail).
2023-04-04 14:36:43 -04:00
Tom Rini
d7e0678c76 CI: Move to clang-16
As this is now the stable release, move to using that now for our tests.

Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2023-04-04 12:26:31 -04:00
Tom Rini
d0e3378ad7 linker_lists: Rework start/end macros to not rely on undefined behavior
Per the GCC bug listed below, the way we do linker lists is relying on
undefined behavior that seems to work in gcc, but doesn't always work in
clang. Andrew suggests rewriting our start/end macros in a different way
(as implemented here, from what he said in comment 1) to avoid these
problems.

Reported-by: AdityaK <appujee@google.com>
Suggested-by: Andrew Pinski <apinski@marvell.com>
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108915
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Andrew Pinski <apinski@marvell.com>
2023-04-04 12:24:29 -04:00
Tom Rini
65fa29d6c3 smartweb: Enable LTO
In order to prepare for slight size growth due to reworking linker list
support, enable LTO here to save more space again.

Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
2023-04-04 12:24:29 -04:00
Tom Rini
866f30205b Dockerfile: Populate a pip cache
Given the number of jobs in CI we have which use python and pip install
packages, we should do this once in the Dockerfile, in order to populate
the cache. We let each job continue to create and use the virtual
environments they need to facilitate making updates to these
environments easier.

Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2023-04-04 12:24:29 -04:00
Tom Rini
046b8ef438 pytest: Update requirements to match sphinx versions
In order to better make use of pip caches, and also for better overall
consistency, we should use the same versions of packages in each of our
python requirements files. Update pytest to use the newer versions of
packages we use in sphinx builds.

Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2023-04-04 12:24:29 -04:00