summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-04-07ARM: dts: renesas: Add R8A779F0 S4 DTHai Pham
Add initial DT for R8A779F0 S4 SoC. Based on Linux next commit 058f4df42121 ("Add linux-next specific files for 20230228") Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Signed-off-by: Hai Pham <hai.pham.ud@renesas.com> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> [Marek: Sync with Linux next 20230228, update commit message]
2023-04-07ARM: rmobile: Turn R-Car V3U into R-Car Gen4Hai Pham
Despite the name, R-Car V3U is the first member of the R-Car Gen4 family [1]. Hence reflect this in related files, select appropriate configuration options and split DT build into its own GEN4 entry. [1] https://www.renesas.com/us/en/products/automotive-products/automotive-system-chips-socs/r-car-v3u-best-class-r-car-v3u-asil-d-system-chip-automated-driving Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Signed-off-by: Hai Pham <hai.pham.ud@renesas.com> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> [Marek: Deduplicate DTC_FLAGS addition using RCAR_64 symbol Update commit message]
2023-04-07pinctrl: renesas: Add R8A779F0 S4 PFC tablesLUU HOAI
Add pinctrl tables for R8A779F0 S4 SoC. Based on Linux next 20230228 PFC tables tables up to commit 058f4df42121 ("Add linux-next specific files for 20230228") Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Signed-off-by: LUU HOAI <hoai.luu.ub@renesas.com> Signed-off-by: Hai Pham <hai.pham.ud@renesas.com> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> [Marek: Use RCAR_64 Kconfig, sync with Linux next 20230228]
2023-04-07clk: renesas: Add R8A779F0 S4 clock tablesHai Pham
Add clock tables for R8A779F0 S4 SoC Based on Linux commit 24aaff6a6ce4 ("clk: renesas: cpg-mssr: Add support for R-Car S4-8") by Yoshihiro Shimoda and sync the tables up to Linux next commit 058f4df42121 ("Add linux-next specific files for 20230228") Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Signed-off-by: Hai Pham <hai.pham.ud@renesas.com> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> [Marek: Sync with Linux next 20230228 . Update from CLK to CPG core driver]
2023-04-07clk: renesas: Update R-Car Gen3 driver Gen4 supportMarek Vasut
Update R-Car Gen4 support in Gen3 clock driver. This patch renames the V3U clock parts to Gen4 and extends them by new PLL2, PLL3, PLL4, PLL6 as well as SDSRC clock which use undocumented bits so far, and RPCSRC clock which uses its own more capable divider table. The Gen4 module standby and reset tables are also updated. This patch makes use of union to alias Gen3 and more extensive Gen4 PLL tables, as the driver cannot ever be instantiated on hardware that would identify itself as both Gen3 and Gen4. The V3U clock driver is updated to match Gen4 clock driver behavior, it is augmented with a more extensive PLL table and a valid MODEMR register offset. This supersedes "clk: renesas: Introduce R-Car Gen4 CPG driver" from Hai Pham as the R-Car Gen3 and Gen4 clock core drivers are extremely similar. That implementation was in turn based on Linux commit 470e3f0d0b15 ("clk: renesas: rcar-gen4: Introduce R-Car Gen4 CPG driver") by Yoshihiro Shimoda . Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
2023-04-07dt-bindings: clock: Add R8A779F0 S4 CPG Core Clock headersTho Vu
Add definitions for R8A779F0 S4 CPG Core Clock headers from Linux next commit 058f4df42121 ("Add linux-next specific files for 20230228") Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Signed-off-by: Tho Vu <tho.vu.wh@renesas.com> Signed-off-by: Hai Pham <hai.pham.ud@renesas.com> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> [Marek: Update to linux next 20230228 state]
2023-04-07dt-bindings: power: Add R8A779F0 S4 SYSC power domain definitionsTho Vu
Add power domain indices for R-Car S4 (R8A779F0) from Linux next commit 058f4df42121 ("Add linux-next specific files for 20230228") Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Signed-off-by: Tho Vu <tho.vu.wh@renesas.com> Signed-off-by: Hai Pham <hai.pham.ud@renesas.com> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> [Marek: Update to linux next 20230228 state]
2023-04-07spi: renesas: Make driver available on R-Car Gen4Marek Vasut
Use CONFIG_RCAR_64 to make the driver available on both R-Car Gen3 and R-Car Gen4. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
2023-04-07serial: sh: Add HSCIF support for R-Car SoCHai Pham
Provide the basic HSCIF support for R-Car SoC. Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Signed-off-by: Hai Pham <hai.pham.ud@renesas.com> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> [Marek: Fill in HSSRR offset for Gen2 and SCBRR calculation for Gen2 and Gen3] Reviewed-by: Simon Glass <sjg@chromium.org>
2023-04-07serial: sh: Add R-Car Gen4 supportHai Pham
Add R-Car Gen4 family support. The basic function is as same as previous R-Car Generation. Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Signed-off-by: Hai Pham <hai.pham.ud@renesas.com> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> [Marek: Swap RZ/A1 and Gen4 to keep the GenN sequence, use RCAR_64]
2023-04-07net: ravb: Add R-Car Gen4 supportHai Pham
Add support for R-Car Gen4 SoCs and a matching DT compatible. Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Signed-off-by: Hai Pham <hai.pham.ud@renesas.com> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> [Marek: Drop SoC specific compatible, use RCAR_64 Kconfig symbol, update commit message]
2023-04-07mmc: renesas-sdhi: Add R-Car Gen4 supportHai Pham
Support R-Car Gen4 family. The default quirk is similar to previous generation. Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Signed-off-by: Hai Pham <hai.pham.ud@renesas.com> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> # Use RCAR_64 Kconfig
2023-04-07mmc: tmio: Replace ifdeffery with IS_ENABLED/CONFIG_IS_ENABLED macrosMarek Vasut
Instead of #if and #ifdef, use IS_ENABLED and CONFIG_IS_ENABLED macros. This improves build test coverage. The CONFIG_SPL_BUILD must remain an ifdef, as CONFIG_SPL_STACK may not always be defined, e.g. in U-Boot proper build. No functional change. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
2023-04-07mmc: tmio: Check 'addr' width before checking for 64bit limitationMarek Vasut
The 64bit limitation check is compiled and optimized out on 32bit platforms, but generates a type width warning: drivers/mmc/tmio-common.c: In function ‘tmio_sd_addr_is_dmaable’: drivers/mmc/tmio-common.c:376:26: warning: right shift count >= width of type [-Wshift-count-overflow] 376 | if (addr >> 32) | ^~ Fix the warning by checking the addr type width to see whether the shift even makes sense in the first place. The width check is also optimized out at compile time. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
2023-04-07i2c: rcar_i2c: Add R-Car Gen4 supportHai Pham
Add support for R-Car Gen4 SoCs into the driver. While I2C on R-Car Gen4 does support some extra features (Slave Clock Stretch Select), for now it is treated the same as I2C on R-Car Gen3, which let us share the same driver. Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Signed-off-by: Hai Pham <hai.pham.ud@renesas.com> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> # Use RCAR_64 Kconfig Reviewed-by: Heiko Schocher <hs@denx.de>
2023-04-07gpio: renesas: Add R-Car Gen4 supportHai Pham
Add support for the GPIO controller block in the R-Car Gen4 family. It has a General Input Enable Register (INEN), whose reset state is to have all inputs disabled. Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Signed-off-by: Hai Pham <hai.pham.ud@renesas.com> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
2023-04-07ARM: rmobile: Add R-Car Generation 4 supportHai Pham
This adds R-Car Generation 4 (Gen4) support as Renesas ARM64 SoC. In this version, reusing R-Car Gen3 lowlevel initialize routine [1] and R-Car Gen3 memory map tables [2] . [1] arch/arm/mach-rmobile/lowlevel_init_gen3.S [2] arch/arm/mach-rmobile/memmap-gen3.c Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Signed-off-by: Hai Pham <hai.pham.ud@renesas.com> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> [Marek: - Enable DTO support by default - Sort the Kconfig lists - Select RCAR_64 Kconfig option to pull in all the shared Kconfig options with Gen3, and use where applicable to deduplicate entries. - Fix reference [2] typo in commit message - Drop config options moved to Kconfig, rename rest to CFG_ accordingly to synchronize with upstream changes. Drop removed CONFIG_VERY_BIG_RAM. - Move board size limit to arch/Kconfig - Move GICR_BASE to headers instead of common config]
2023-04-05Merge tag 'fsl-qoriq-2023-4-6' of ↵Tom Rini
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-05Merge branch '2023-04-05-blkmap-composable-virtual-block-devices'Tom Rini
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-05efi_loader: device_path: support blkmap devicesTobias Waldekranz
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-05doc: blkmap: Add introduction and examplesTobias Waldekranz
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-05test: blkmap: Add test suiteTobias Waldekranz
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-05cmd: blkmap: Add blkmap commandTobias Waldekranz
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-05blk: blkmap: Add linear device mapping supportTobias Waldekranz
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-05blk: blkmap: Add memory mapping supportTobias Waldekranz
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-05blk: blkmap: Add basic infrastructureTobias Waldekranz
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-05cmd: blk: Allow generic read/write operations to work in sandboxTobias Waldekranz
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-05image: Fix script execution from FIT images with external dataTobias Waldekranz
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-05Merge branch '2023-04-04-android-image-v3-v4-support'Tom Rini
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-04Dockerfile: add mkbootimg toolSafae Ouajih
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-04test/py: android: extend abootimg testSafae Ouajih
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-04doc: android: add documentation for v3, v4 boot image headerSafae Ouajih
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-04android: boot: support bootconfigSafae Ouajih
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-04android: boot: support boot image header version 3 and 4Safae Ouajih
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-04drivers: fastboot: zImage flashing is not supported for v3, v4Safae Ouajih
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-04android: boot: update android_image_get_dtb_img_addr to support v3, v4Safae Ouajih
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-04android: boot: support extra command lineSafae Ouajih
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-04android: boot: ramdisk: support vendor ramdiskSafae Ouajih
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-04android: boot: update android_image_get_data to support v3, v4Safae Ouajih
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-04android: boot: add vendor boot image to prepare for v3, v4 supportSafae Ouajih
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-04android: boot: boot image header v3, v4 do not support recovery DTBOSafae Ouajih
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-04android: boot: content print is not supported for v3, v4 header versionSafae Ouajih
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-04android: boot: move to andr_image_data structureSafae Ouajih
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-04android: boot: kcomp: support andr_image_dataSafae Ouajih
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-04android: boot: add boot image header v3 and v4 structuresSafae Ouajih
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-04android: boot: replace android_image_check_headerSafae Ouajih
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-04android: boot: support vendor boot image in abootimgSafae Ouajih
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-04android: boot: rename andr_img_hdr -> andr_boot_img_hdr_v0Safae Ouajih
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-04Merge branch '2023-04-04-update-to-clang-16'Tom Rini
- 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-04CI: Move to clang-16Tom Rini
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>
generated by cgit v1.2.3 (git 2.0.4) at 2025-08-02 20:44:41 +0000