We should not use typedefs in U-Boot. They cannot be used as forward
declarations which means that header files must include the full header to
access them.

Drop the typedef and rename the struct to remove the _s suffix which is
now not useful.

This requires quite a few header-file additions.

Signed-off-by: Simon Glass <sjg@chromium.org>

Currently, there is no method that can detect compression types
given a file. This is very useful where a compressed kernel image
is loaded directly to the memory.

Inspect initial few bytes to figure out compression type of the
image. It will be used in booti method for now but can be reused
any other function in future as well.

Signed-off-by: Atish Patra <atish.patra@wdc.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

Xilinx changes for v2020.07

common:
- Align ENV_FAT_INTERFACE
- Fix MAC address source print log
- Improve based autodetection code

xilinx:
- Enable netconsole

Microblaze:
- Setup default ENV_OFFSET/ENV_SECT_SIZE

Zynq:
- Multiple DT updates/fixes
- Use DEVICE_TREE environment variable for DTB selection
- Switch to single zynq configuration
- Enable NOR flash via DM
- Minor SPL print removal
- Enable i2c mux driver

ZynqMP:
- Print multiboot register
- Enable cache commands in mini mtest
- Multiple DT updates/fixes
- Fix firmware probing when driver is not enabled
- Specify 3rd backup RAM boot mode in SPL
- Add SPL support for zcu102 v1.1 and zcu111 revA
- Redesign debug uart enabling and psu_init delay
- Enable full u-boot run from EL3
- Enable u-boot.itb generation without ATF with U-Boot in EL3

Versal:
- Enable distro default
- Enable others SPI flashes
- Enable systems without DDR

Drivers:
- Gem:
  - Flush memory after freeing
  - Handle mdio bus separately
- Watchdog:
  - Get rid of unused global data pointer
  - Enable window watchdog timer
- Serial:
  - Change reinitialization logic in zynq serial driver

Signed-off-by: Tom Rini <trini@konsulko.com>

These are used in multiple places so update them to use a shared #define.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Philippe Reynes <philippe.reynes@softathome.com>

This should mention that conf_uname can be NULL and should be in the
header file. Fix this.

Signed-off-by: Simon Glass <sjg@chromium.org>

For FIT verification, all the properties of a public key come from
"control fdt" pointed to by fdt_blob. In UEFI secure boot, on the other
hand, a public key is located and retrieved from dedicated signature
database stored as UEFI variables.

Added two fields may hold values of a public key if fdt_blob is NULL, and
will be used in rsa_verify_with_pkey() to verify a signature in UEFI
sub-system.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

Introduce new configuration, CONFIG_RSA_VERIFY which will decouple building
RSA functions from FIT verification and allow for adding a RSA-based
signature verification for other file formats, in particular PE file
for UEFI secure boot.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

On Feb. 16, 2020, Tom reported [1] build failure of U-Boot in-tree
tooling after applying https://patchwork.ozlabs.org/cover/1229663/
("[v6,0/7] rsa: extend rsa_verify() for UEFI secure boot").

Later on, Heinrich stressed the urgency of the issue in
https://patchwork.ozlabs.org/patch/1250858/#2379069:

 >>>>>>>>>
 We should finalize the topic as it stops EFI patches from being merged
 >>>>>>>>>

On the surface, the problem is caused by U-Boot commits [2-3], which
employed 'u32' in 'include/image.h', while historically U-Boot tooling
stayed agnostic on the {u,s}{8,16,32} types.

Thanks to Tom, Yamada-san and Heinrich, the following solutions have
been put head-to-head ('+' pros, '-' cons):

 A. Use an equivalent fixed-size type, i.e. s/u32/uint32_t/ in both
    android function prototypes (image.h) and definitions (c file):
    + quick and low-line-count
    - creates a 'soup' of fixed-sized types in the Android C file
    - will confuse contributors
    - is going against Linux kernel best practices [4]

 B. Guard Android functions by '!defined(USE_HOSTCC)' in image.h:
    + quick and low-line-count
    + reflects the reality (no android function is used by tooling)
    + zero impact on other subsystems
    - ifdeffery may look annoying (pre-existing problem of image.h)

 C. Make {u8,u16,u32} available in U-Boot tooling:
    + quick and low-line-count
    + [Yamada-san][5]:
      * forbidding u32 for tools is questionable to me
      * Linux kernel and Barebox use {u8,u16,u32} for the tools space
    - breaks U-Boot tradition?
    - has larger impact than [A] and [B]
    - adds type complexity/inconsistency in the tooling space

 D. [Yamada-san] Refactor the headers to minimize the code shared
    between U-Boot space and tooling space:
    + probably the long-term solution
    - high effort
    - can be seen/done as an incremental update on top of [B]

Looking at the above, [B] looks like the natural way to go forward.

[1] https://patchwork.ozlabs.org/patch/1238245/#2363052
[2] commit 7f2531502c74c0 ("image: android: Add routine to get dtbo params")
[3] commit c3bfad825a71ea ("image: android: Add functions for handling dtb field")
[4] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e6176fa4728fb6d
    ("checkpatch: add --strict warning for c99 fixed size typedefs : int<size>_t")
[5] https://patchwork.ozlabs.org/patch/1238245/#2363340

Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Sam Protsenko <joe.skb7@gmail.com>
Cc: Lokesh Vutla <lokeshvutla@ti.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reported-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Tested-by: Heinrich Schuchardt <xpyron.glpk@gmx.de>

Android Boot Image v1 adds "Recovery DTB" field in image header and
associate payload in boot image itself [1]. Payload should be in
Android DTB/DTBO format [2]. That "Recovery DTB" area should be only
populated for non-A/B devices, and only in recovery image.

Add function to get an address and size of that payload. That function
can be further used e.g. in 'abootimg' command to provide the user a way
to get the address of recovery dtbo from U-Boot shell, which can be
further parsed using 'adtimg' command.

[1] https://source.android.com/devices/bootloader/boot-image-header
[2] https://source.android.com/devices/architecture/dto/partitions

Signed-off-by: Sam Protsenko <joe.skb7@gmail.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

Android Boot Image v2 adds "DTB" payload (and corresponding field in the
image header). Provide functions for its handling:

  - android_image_get_dtb_by_index(): Obtain DTB blob from "DTB" part of
    boot image, by blob's index
  - android_image_print_dtb_contents(): Iterate over all DTB blobs in
    "DTB" part of boot image and print those blobs info

"DTB" payload might be in one of the following formats:
  1. concatenated DTB blobs
  2. Android DTBO format

The latter requires "android-image-dt.c" functionality, so this commit
selects that file for building for CONFIG_ANDROID_BOOT_IMAGE option.

Right now this new functionality isn't used, but it can be used further.
As it's required to apply some specific dtbo blob(s) from "dtbo"
partition, we can't automate this process inside of "bootm" command. But
we can do next:
  - come up with some new command like "abootimg" to extract dtb blob
    from boot image (using functions from this patch)
  - extract desired dtbo blobs from "dtbo" partition using "adtimg"
    command
  - merge dtbo blobs into dtb blob using "fdt apply" command
  - pass resulting dtb blob into bootm command in order to boot the
    Android kernel with Android ramdisk from boot image

Signed-off-by: Sam Protsenko <joe.skb7@gmail.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>