It does not make sense to enable all SHA algorithms unless they are
needed. It bloats the code and in this case, causes chromebook_link to
fail to build. That board does use the TPM, but not with measured boot,
nor EFI.

Since EFI_TCG2_PROTOCOL already selects these options, we just need to
add them to MEASURED_BOOT as well.

Note that the original commit combines refactoring and new features,
which makes it hard to see what is going on.

Fixes: 97707f12fda tpm: Support boot measurements
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Simon Glass <sjg@chromium.org>

Correct the links to the FIT documentation in boot/Kconfig.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

The PC client spec [0], doesn't describe measurements for DTBs. It does
describe what do to for ACPI tables though.

There is a description for ACPI in 3.3.4.1 PCR[0] – SRTM, POST BIOS,
and Embedded Drivers and they explicitly mention ACPI in there. There's
no mention of ACPI in 3.3.4.2 PCR[1] – Host Platform Configuration.

However, in Figure 6 --  PCR Mapping of UEFI Components ACPI is shown
in PCR1. The general description also mentions PCR0 is for code and PCR1
is for data such as ACPI and SMBIOS.

So let's switch over the DTB measurements to PCR1 which seems a better
fit.

[0] https://trustedcomputinggroup.org/resource/pc-client-specific-platform-firmware-profile-specification

Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Eddie James <eajames@linux.ibm.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>

Add SPL variant of DM_RNG so that the DM_RNG can be disabled in SPL
if necessary. This may be necessary due to e.g. size constraints of
the SPL.

Signed-off-by: Marek Vasut <marex@denx.de>

Create separate helper for just reserving framebuffer region without
creating or enabling simple-framebuffer node.

This is useful for scenarios where user want to preserve the bootloader
splash screen till OS boots up and display server gets started without
displaying anything else in between and thus not requiring
simple-framebuffer.

Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
Reviewed-by: Nikhil M Jain <n-jain1@ti.com>

Enable and update simple-framebuffer node using the video handoff
bloblist if video was enabled at SPL stage and corresponding video
bloblist was received at u-boot proper with necessary parameters.

Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
Reviewed-by: Nikhil M Jain <n-jain1@ti.com>

default n doesn't need to be specified. It is default option anyway.
Similar changes have been done by commit 18370f14975c ("Kconfig: Remove all
default n/no options").

Signed-off-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

In case of systems where DRAM bank ends at the edge of 32bit boundary,
start + size calculations would overflow. This happens on STM32MP15xx
with 1 DRAM bank starting at 0xc0000000 and 1 GiB of DRAM. This is a
usual 32bit system DRAM size overflow, fix it by doing all DRAM size
and offset calculations using u64 types. This also covers a case where
a 32bit PAE system might be able to address up to 36bits of DRAM.

Fixes: a4df06e41fa2 ("boot: fdt: Change type of env_get_bootm_low() to phys_addr_t")
Signed-off-by: Marek Vasut <marex@denx.de>