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

- configs: libretech: set SPI mode to 0 to fix SPI NOR Flash probe

Kconfig defaults to mode 3 if CONFIG_SF_DEFAULT_MODE is not set.
It becomes an issue since meson_spifc does not support SPI_CPHA.
Needed after commit e2e95e5e ("spi: Update speed/mode on change").

Fixes: e2e95e5e ("spi: Update speed/mode on change")
Signed-off-by: NDa Xue <da@libre.computer>
[narmstrong: reformated commit reference & added Fixes tag]
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>

Pull request for efi-2021-07-rc6

Bug fixes:

* improve specification compliance of UEFI capsule updates
* allow capsule update on-disk without checking OsIndications
* provide parameter checks for QueryVariableInfo()

replace CONFIG_AUTOBOOT_USE_MENUKEY with CONFIG_AUTOBOOT_MENUKEY
Signed-off-by: NDa Xue <da@libre.computer>

Although U-Boot supports capsule update on-disk, it's lack of support for
SetVariable at runtime prevents applications like fwupd from using it.

In order to perform the capsule update on-disk the spec says that the OS
must copy the capsule to the \EFI\UpdateCapsule directory and set a bit in
the OsIndications variable.  The firmware then checks for the
EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED bit in OsIndications
variable, which is set by the submitter to trigger processing of the
capsule on the next reboot.

Let's add a config option which ignores the bit and just relies on the
capsule being present. Since U-Boot deletes the capsule while processing
it, we won't end up applying it multiple times.

Note that this is allowed for all capsules. In the future, once
authenticated capsules are fully supported, we can limit the functionality
to those only.
Signed-off-by: Napalos <ilias.apalodimas@linaro.org>

Reword Kconfig description.
Reviewed-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>

After each reboot we must clear flag
EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED in variable
OsIndications.
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>

Improve efi_query_variable_info() to check the parameter settings and
return correct error code according to the UEFI Specification 2.9,
and the Self Certification Test (SCT) II Case Specification, June
2017, chapter 4.1.4 QueryVariableInfo().
Reported-by: NKazuhiko Sakamoto <sakamoto.kazuhiko@socionext.com>
Signed-off-by: NMasami Hiramatsu <masami.hiramatsu@linaro.org>
Reviewed-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>

After if we should use parentheses to keep the code readable.

Fixes: a95f4c88 ("efi_loader: NULL dereference in EFI console")
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>

We only install FMPs if a CapsuleUpdate is requested.  Since we now have an
ESRT table which relies on FMPs to build the required information, it
makes more sense to unconditionally install them. This will allow userspace
applications (e.g fwupd) to make use of the ERST and provide us with files
we can use to run CapsuleUpdate on-disk
Signed-off-by: NIlias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>

Chapter 23 of the EFI spec (rev 2.9) says:
"A specific updatable hardware firmware store must be represented by
exactly one FMP instance".
This is not the case for us, since both of our FMP protocols can be
installed at the same time because they are controlled by a single
'dfu_alt_info' env variable.
So make the config options depend on each other and allow the user to
install one of them at any given time.  If we fix the meta-data provided
by the 'dfu_alt_info' in the future,  to hint about the capsule type
(fit or raw) we can revise this and enable both FMPs to be installed, as
long as they target different firmware hardware stores

Note that we are not using a Kconfig 'choice' on purpose, since we
want to allow both of those to be installed and tested in sandbox
Signed-off-by: NIlias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>

When running the efidebug capsule disk-update command, the efi_fmp_raw
protocol installation fails with 2 (EFI_INVALID_PARAMETER) as below.
This is because the code passes efi_root instead of the handle local var.

=> efidebug capsule disk-update
EFI: Call: efi_install_multiple_protocol_interfaces( &handle, &efi_guid_firmware_management_protocol, &efi_fmp_fit, NULL)
  EFI: Entry efi_install_multiple_protocol_interfaces(00000000fbaf5988)
    EFI: Call: efi_install_protocol_interface( handle, protocol, EFI_NATIVE_INTERFACE, protocol_interface)
      EFI: Entry efi_install_protocol_interface(00000000fbaf5988, 86c77a67-0b97-4633-a187-49104d0685c7, 0, 00000000fbfa6ee8)
        EFI: new handle 00000000fbb37520
      EFI: Exit: efi_install_protocol_interface: 0
    EFI: 0 returned by efi_install_protocol_interface( handle, protocol, EFI_NATIVE_INTERFACE, protocol_interface)
  EFI: Exit: efi_install_multiple_protocol_interfaces: 0
EFI: 0 returned by efi_install_multiple_protocol_interfaces( &handle, &efi_guid_firmware_management_protocol, &efi_fmp_fit, NULL)
EFI: Call: efi_install_multiple_protocol_interfaces( &efi_root, &efi_guid_firmware_management_protocol, &efi_fmp_raw, NULL)
  EFI: Entry efi_install_multiple_protocol_interfaces(00000000fbfec648)
    EFI: Call: efi_install_protocol_interface( handle, protocol, EFI_NATIVE_INTERFACE, protocol_interface)
      EFI: Entry efi_install_protocol_interface(00000000fbfec648, 86c77a67-0b97-4633-a187-49104d0685c7, 0, 00000000fbfa6f18)
        EFI: handle 00000000fbaf8520
      EFI: Exit: efi_install_protocol_interface: 2
    EFI: 2 returned by efi_install_protocol_interface( handle, protocol, EFI_NATIVE_INTERFACE, protocol_interface)
  EFI: Exit: efi_install_multiple_protocol_interfaces: 2
EFI: 2 returned by efi_install_multiple_protocol_interfaces( &efi_root, &efi_guid_firmware_management_protocol, &efi_fmp_raw, NULL)
Command failed, result=1

To fix this issue, pass the handle local var which is set NULL right
before installing efi_fmp_raw as same as the installing efi_fmp_fit.
(In both cases, the local reference to the handle will be just discarded)
Signed-off-by: NMasami Hiramatsu <masami.hiramatsu@linaro.org>
Signed-off-by: NIlias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>

This reverts commit 4e1903a6.

This local commit was not intended to be pushed out.
Signed-off-by: NTom Rini <trini@konsulko.com>

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

The spi_get_bus_and_cs() may be called on the same bus and chipselect
with different frequency or mode. This is valid usecase, but the code
fails to notify the controller of such a configuration change. Call
spi_set_speed_mode() in case bus frequency or bus mode changed to let
the controller update the configuration.

The problem can easily be triggered using the sspi command:
=> sspi 0:0@1000
=> sspi 0:0@2000
Without this patch, both transfers happen at 1000 Hz. With this patch,
the later transfer happens correctly at 2000 Hz.
Signed-off-by: NMarek Vasut <marex@denx.de>
Cc: Jagan Teki <jagan@amarulasolutions.com>
Cc: Patrick Delaunay <patrick.delaunay@foss.st.com>

Pull request for efi-2021-07-rc5-2

Documentation:

* man-page for askenv

bug fixes

* correct display of BootOrder in efidebug command
* do not allow TPL_HIGH_LEVEL for CreateEvent(Ex)
* correct handling of unknown properties in SMBIOS tables

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

If both POSITION_INDEPENDENT and SYS_RELOC_GD_ENV_ADDR are enabled,
wherever original env is placed anywhere, it should be relocated to
the right address.

Relocation offset gd->reloc_off is calculated with SYS_TEXT_BASE in
setup_reloc() and env address gd->env_addr is relocated by the offset in
initr_reloc_global_data().

gd->env_addr
  = (orig env) + gd->reloc_off
  = (orig env) + (gd->relocaddr - SYS_TEXT_BASE)

However, SYS_TEXT_BASE isn't always runtime base address when
POSITION_INDEPENDENT is enabled. So the relocated env_addr might point to
wrong address. For example, if SYS_TEXT_BASE is zero, gd->env_addr is
out of memory location and memory exception will occur.

There is a difference between linked address such as SYS_TEXT_BASE and
runtime base address. In _main, the difference is calculated as
"run-vs-link" offset. The env_addr should also be added to the offset
to fix the address.

gd->env_addr
  = (orig env) + ("run-vs-link" offset)   + gd->reloc_off
  = (orig env) + (SYS_TEXT_BASE - _start) + (gd->relocaddr - SYS_TEXT_BASE)
  = (orig env) + (gd->relocaddr - _start)

Cc: Marek Vasut <marex@denx.de>
Signed-off-by: NKunihiko Hayashi <hayashi.kunihiko@socionext.com>
Acked-by: NMarek Vasut <marex@denx.de>
Tested-by: NMarek Vasut <marex@denx.de>

Commit e4f8e543("smbios: Drop the unused Kconfig options")
break SMBIOS tables.  The reason is that the patch drops the Kconfig
options *after* removing the code using them,  but that changes the semantics
of the code completely.  Prior to the change a non NULL value was used in
the 'product' and 'manufacturer ' fields.

Chapter 6.2 of the DMTF spec requires Manufacturer and Product Name to be
non-null on some of the tables. So let's add sane defaults for Type1/2/3.

* Before the patchset:

<snip>
Handle 0x0002, DMI type 2, 14 bytes
Base Board Information
        Manufacturer: Not Specified
        Product Name: Not Specified
        Version: Not Specified
        Serial Number: Not Specified
        Asset Tag: Not Specified
        Features:
                Board is a hosting board
        Location In Chassis: Not Specified
        Chassis Handle: 0x0000
        Type: Motherboard

Invalid entry length (0). DMI table is broken! Stop.

* After the patchset:

<snip>
Handle 0x0005, DMI type 32, 11 bytes
System Boot Information
        Status: No errors detected

Handle 0x0006, DMI type 127, 4 bytes
End Of Table

Fixes: e4f8e543 ("smbios: Drop the unused Kconfig options")
Signed-off-by: NIlias Apalodimas <ilias.apalodimas@linaro.org>

We currently define the EFI support of an SMBIOS table as the third bit of
"BIOS Characteristics Extension Byte 1". The latest DMTF spec defines it
on "BIOS Characteristics Extension Byte 2".
Signed-off-by: NIlias Apalodimas <ilias.apalodimas@linaro.org>

Remove superfluous assignment.
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>

help file for using askenv cmd is created.
It provides description on the command purpose,
description of arguments,
couple of examples (illustrating command usage),
configuration parameter and
possible return values.
Signed-off-by: NAdarsh Babu Kalepalli <opensource.kab@gmail.com>
Add missing entry in doc/usage/index.rst.
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>

Use 'Return:' instead of '@return:'.
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>

Display the number of the boot option and not its index.

Fixes: 2ecee310 ("efi_loader: use efi_create_indexed_name()")
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>

According to chapter 7.1 "Event, Timer, and Task Priority Services"
TPL_HIGH_LEVEL should not be exposed to applications and drivers.

According to the discussion with EDK II contributors this implies that
CreateEvent() shall not allow to create events with TPL_HIGH_LEVEL.

Cc: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
Acked-by: NSamer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>

Rsync all defconfig files using moveconfig.py
Signed-off-by: NTom Rini <trini@konsulko.com>

Fixes for 2021.07
-----------------

CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/7903

- Beacon board fix, for this release.

- A few easy MX7 EHCI USB fixes, for this release.

Unlike imx6, on imx7 the USB PHY is described as:

	usbphynop1: usbphynop1 {
		compatible = "usb-nop-xceiv";
		clocks = <&clks IMX7D_USB_PHY1_CLK>;
		clock-names = "main_clk";
		#phy-cells = <0>;
	};

which does not have the 'reg' property.

Do not return an error when the 'reg' property is not found
for the USB PHY.

This fixes USB gadget regression on a imx7s-warp board.

Successfully tested the "ums 0 mmc 0" command on two boards:
imx7s-warp and imx6dl-pico-pi.
Signed-off-by: NFabio Estevam <festevam@denx.de>

On a imx7s-warp board the fdtdec_get_alias_seq() function
always fails.

As priv->portnr is only used on i.MX6, move fdtdec_get_alias_seq()
inside the CONFIG_MX6 block.
Signed-off-by: NFabio Estevam <festevam@denx.de>

The board detection is incorrectly stating it's an rcar3 variant
instead of an RZ/G2 variant on all the r8a774*1_beacon boards.
Set the flag to correctly display as RZ/G2[M/N/H]
Signed-off-by: NAdam Ford <aford173@gmail.com>

- x86: Discard .note.gnu.property sections
- nvme: Skip block device creation for inactive namespaces
- nvme: Convert NVMe doc to reST, and various minor fixes

- Revert fsl_esdhc_imx using VENDORSPEC_FRC_SDCLK_ON
- Fix data read for dw_mmc
- Increase minimum bus freq for mtk-sd
- Minor cleanup

- Assorted minor bugfixes

On some distributions the mkfs is under /sbin and /sbin is not set
for mere users. Include /sbin to the PATH when creating file system,
so that users won't get a scary traceback from Python.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Update to me as co-maintainer with Peng.
Additionally, update the mmc alias in git-mailrc.
Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
Acked-by: NPeng Fan <peng.fan@nxp.com>

All symbols that are defined in Kconfig will always be defined (or not)
prior to preprocessing due to the -include directive while building.
However, symbols which are not yet migrated will only be defined (or
not) once the board config.h is included, via <config.h>.  While the end
goal must be to migrate all symbols, today we have cases where the size
of gd will get mismatched within the build, based on include order.
Mitigate this by making sure that any <asm/global_data.h> that uses
symbols not in Kconfig does start with <config.h>.  Remove this when not
needed.

Cc: Alexey Brodkin <alexey.brodkin@synopsys.com>
Cc: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Cc: Huan Wang <alison.wang@nxp.com>
Cc: Angelo Dureghello <angelo@sysam.it>
Cc: Rick Chen <rick@andestech.com>
Signed-off-by: NTom Rini <trini@konsulko.com>

Based on the comment in socfpga_soc64_common.h, the intention is for
CONFIG_SYS_MEM_RESERVE_SECURE to be unused.  However, in the code we do:
...

and that will evaluate to true.  This leads to unwanted code being
compiled.  Further, as CONFIG_SYS_MEM_RESERVE_SECURE has not been
migrated to Kconfig, this leads to a mismatch in the size of gd
depending on if we have or have not also had <configs/BOARD.h> also
included yet.

Remove the define as it's not needed.

Cc: Siew Chin Lim <elly.siew.chin.lim@intel.com>
Cc: Chee Hong Ang <chee.hong.ang@intel.com>
Cc: Dalon Westergreen <dalon.westergreen@intel.com>
Signed-off-by: NTom Rini <trini@konsulko.com>

With the changes in commit 588efcdd72fc ("powerpc: Don't use relative
include for config.h in global_data.h") fixing the root of the problem,
we no longer need this re-inclusion.

This reverts commit f6c0d365.

Cc: Matt Merhar <mattmerhar@protonmail.com>
Signed-off-by: NTom Rini <trini@konsulko.com>

As there is an arch/powerpc/include/asm/config.h file using "" to get
config.h here can lead to using that rather than include/config.h.  This
in turn can lead to a mismatch in the size of gd.

Cc: Matt Merhar <mattmerhar@protonmail.com>
Signed-off-by: NTom Rini <trini@konsulko.com>
Tested-by: NMatt Merhar <mattmerhar@protonmail.com>