Pull request efi-2023-07-rc3

Documentation:

* update the description of signature algorithms

UEFI:

* fix unaligned access to GUID in HII database protocol
* fix launching EFI binaries loaded via semihosting
* fix filling of file path in loaded image protocol for non-block devices

- Merge in a long-standing fix for some exynos platforms, correct a
  Kconfig description, fix some env issues, fix an issue in
  devfdt_get_addr_size_index_ptr and look for "panel-timings" not
  "panel-timing" per upstream binding.

Xilinx changes for v2023.07-rc3

.mailmap
- Fix Xilinx IDs

ZynqMP:
- Fix R5 split boot mode
- DT fixes - sync with Linux

Xilinx:
- Enable virtio and RNG support
- Enable ADI ethernet phy

SPI/Zynq:
- Fix dummy byte calculation

During refactor this seemed to have been missed.

Fixes: 65dbb128fb45 ("include: environment: ti: Use .env for environment variables")

Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>

For the devfdt_get_addr_size_index_ptr() function use
map_sysmem() function as cast for the return for use in
sandbox.

Signed-off-by: Johan Jonker <jbx6244@gmail.com>

In case where a single timing resolution is implemented in the
device-tree, the property is named "panel-timing", as specify
in Linux kernel binding file:

Documentation/devicetree/bindings/display/panel/panel-common.yaml

  # Display Timings
  panel-timing:
    description:
      Most display panels are restricted to a single resolution and
      require specific display timings. The panel-timing subnode expresses those
      timings.
    $ref: panel-timing.yaml#

  display-timings:
    description:
      Some display panels support several resolutions with different timings.
      The display-timings bindings supports specifying several timings and
      optionally specifying which is the native mode.
    $ref: display-timings.yaml#

Fixes: 0347cc773270 ("drivers: core: ofnode: Add panel timing decode.")
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

After converting my targets from CFG_EXTRA_ENV_SETTINGS to
CONFIG_EXTRA_ENV_TEXT as suggested by Tom, I discovered that
fw_setenv doesn't set the entire defaut environment anymore.

I tried to fix it with the below patch, but it fails qemu-x86 CI test,
see https://source.denx.de/u-boot/custodians/u-boot-mpc8xx/-/pipelines/16326
That's the only CI test that fails AFAICS.

Could you help with a solution ? This needs to be fixed.

Thanks
Christophe

---- >8 ----
From: Christophe Leroy <christophe.leroy@csgroup.eu>
Subject: [RFC PATCH] envtools: Fix default environment

After converting some targets from CFG_EXTRA_ENV_SETTINGS to
CONFIG_EXTRA_ENV_TEXT, default environment embedded in
fw_env tool missed all extra settings.

Commit 86b9c3e4e4 ("env: Allow U-Boot scripts to be placed in
a .env file") restricted the inclusion of the content of that
file to builds without USE_HOSTCC.

But as mentionned in commit 79fc0c5f49 ("tools/env: cross-compile
fw_printenv without setting HOSTCC"), HOSTCC and USE_HOSTCC are
kept for code re-use.

Remove the restricting so that settings included in a .env
file are also added to fw_env tool.

Fixes: 86b9c3e4e4 ("env: Allow U-Boot scripts to be placed in a .env file")
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>

Otherwise non-ChromeOS samsung devices, like the odroid boards, are
stuck in a bootloop if CONFIG_CROS_EC is not enabled:

    <...>
    MMC: SAMSUNG SDHCI: 2, EXYNOS DWMMC: 0
    Loading Environment from MMC... *** Warning - bad CRC, using default environment

    cros-ec communications failure -96

    Please reset with Power+Refresh

    Cannot init cros-ec device
    resetting ...

Issue started after commit e44d7e73fe0d ("dm: core: Switch
uclass_*_device_err to use uclass_*_device_check").

Signed-off-by: Henrik Grimler <henrik@grimler.se>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Minkyu Kang <mk7.kang@samsung.com>

This reverts commit a034ec06ff1d558bbe11d5ee05edbb4de3ee2215.

Commit 4a3ea75de4c5 ("Revert "mmc: sdhci: set to INT_DATA_END when
there are data"") reverted the alternative fix that was added for
Exynos 4 devices, causing an error when trying to boot from an sdcard:

    <...>
    Loading Environment from MMC... sdhci_send_command: Timeout for status update!
    mmc fail to send stop cmd
    <...>

Re-add the quirk to allow booting from sdcards again.

Signed-off-by: Henrik Grimler <henrik@grimler.se>

Make it clear that this is the SPL option to avoid potential confusion
when the description for CONFIG_SPL_VIDEO is the same as that for
CONFIG_VIDEO.

Signed-off-by: John Keeping <john@metanate.com>