Add label to GPIO lines so the user-level applications can find any line
without knowing its physical path on System Controller on VCK190/VMK180.

These labels are describing EMIO gpio connection which depends on PL which
we normally don't describe but that's only way to go for now. Lately this
should be done out of this source code.
Signed-off-by: NSaeed Nowshadi <saeed.nowshadi@xilinx.com>
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>

The 'silabs,skip-recall' property prevents interruption in operation of
the clock while the driver is being probed.  Without this property, the
DDR DIMM clk can cause a failure during Versal's boot.
Signed-off-by: NSaeed Nowshadi <saeed.nowshadi@xilinx.com>

All si570 which are used for ps reference clock generation should contain
silabs,skip-recall property not to cause break on ps clock.
On Versal boards this will cause hang on Versal cpu when it is booted at
the same time with SC.
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>

Pull request for efi-2021-07-rc3

Documentation:

* add a man-page for the size command
* add man-page for extension command to index

Bug fixes:

* avoid build failure due to missing SHA512 hardware acceleration
* correct error handling in TCG2 protocol
* don't let user disable capsule authentication
* correct reading directories via UEFI API

Build error occurs when CONFIG_EFI_SECURE_BOOT or
CONFIG_EFI_CAPSULE_AUTHENTICATE is enabled,
because hash-checksum.c is not compiled.

Since hash_calculate() implemented in hash-checksum.c can be
commonly used aside from FIT image signature verification,
this commit itroduces HASH_CALCULATE option to decide
if hash-checksum.c shall be compiled.
Signed-off-by: NMasahisa Kojima <masahisa.kojima@linaro.org>
Reviewed-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>

EFI_TCG2 depends not only on TPMv2 but also on the underlying algorithms.
So select the missing SHA1, SHA256, SHA384 and SHA512 we currently support
Reported-by: NMichal Simek <michal.simek@xilinx.com>
Signed-off-by: NIlias Apalodimas <ilias.apalodimas@linaro.org>

Add 'default y'.
Reviewed-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>

Up to now we are stopping the EFI subsystem if a TPMv2 exists but the
protocol fails to install.  Now that we've switched the config to 'default
y' the sandbox TPM fails, since it doesn't support all the required
capabilities of the protocol.

Not installing the protocol is not catastrophic.  If the protocol fails
to install the PCRs will never be extended to the expected values, so
some other entity later in the boot flow will eventually figure it out
and take the necessary actions.

While at it fix a corner case were the user can see an invalid error
message when the protocol failed to install.  We do have a tcg2_uninit()
which we call when the protocol installation fails.  There are cases though
that this might be called before the configuration table is installed (e.g
probing the TPM for capabilities failed).  In that case the user will see
"Failed to delete final events config table".  So stop printing it since it's
not an actual failure , simply because the config table was never installed
in the first place.

In order to stop printing it make efi_init_event_log() and create_final_event()
cleanup themselves and only call tcg2_uninit() when the protocol installation
fails.
Signed-off-by: NIlias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>

Instead of just failing, clean up the installed config table and
EventLog memory if logging an s-crtm event fails during the protocol
installation
Signed-off-by: NIlias Apalodimas <ilias.apalodimas@linaro.org>

Eliminate label 'out:' by using return.
Reviewed-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>

efi_init_event_log() calls tcg2_uninit() in case of failure.
We can skip that since the function is called on efi_tcg2_register()
which also cleans up if an error occurs
Signed-off-by: NIlias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>

This is same issue as https://bugzilla.redhat.com/show_bug.cgi?id=1733817,
but that fix was wrongly partial reverted.

When reading a directory, EFI_BUFFER_TOO_SMALL should be returned when
the supplied buffer is too small, so a use-case is to call
EFI_FILE_PROTOCOL.Read() with *buffer_size=0 and buffer=NULL to
obtain the needed size before doing the actual read.

So remove the check only for directory reading, file reading already
do the check by itself.

Fixes: db12f518("efi_loader: implement non-blocking file services")
Signed-off-by: NPeng Fan <peng.fan@nxp.com>
Cc: Stefan Sørensen <stefan.sorensen@spectralink.com>
Tested-by: NPeter Robinson <pbrobinson@gmail.com>
Reviewed-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>

The current capsule authentication code checks if the environment
variable capsule_authentication_enabled is set, for authenticating the
capsule. This is in addition to the check for the config symbol
CONFIG_EFI_CAPSULE_AUTHENTICATE. Remove the check for the environment
variable. The capsule will now be authenticated if the config symbol
is set.
Signed-off-by: NSughosh Ganu <sughosh.ganu@linaro.org>
Reviwed-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>

Commit a479f103 ("hash: Allow for SHA512 hardware implementations")
defined function definitions for hardware accelerated SHA384 and SHA512.
If CONFIG_SHA_HW_ACCEL=y, these functions are used.

We already have boards using CONFIG_SHA_HW_ACCEL=y but none implements the
new functions hw_sha384() and hw_sha512().

For implementing the EFI TCG2 protocol we need SHA384 and SHA512. The
missing hardware acceleration functions lead to build errors on boards like
peach-pi_defconfig.

Introduce a new Kconfig symbol CONFIG_SHA512_HW_ACCEL to control if the
functions hw_sha384() and hw_sha512() shall be used to implement the SHA384
and SHA512 algorithms.

Fixes: a479f103 ("hash: Allow for SHA512 hardware implementations")
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Building 32bit boards with the TCG2 protocol enabled leads to a build
warning due to a missing conversion.

    lib/efi_loader/efi_tcg2.c:774:27:
    error: cast to pointer from integer of different size
    [-Werror=int-to-pointer-cast]
    774 |  ret = tcg2_create_digest((u8 *)data_to_hash, data_to_hash_len,
        |                           ^
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: NIlias Apalodimas <ilias.apalodimas@linaro.org>

'make htmldocs' results in a build warning

    checking consistency... doc/usage/extension.rst:
    WARNING: document isn't included in any toctree

Add the document to the index.

Fixes: 2f84e9cf ("cmd: add support for a new "extension" command")
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>

Provide a man-page for the size command.
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>

My mail address doesn't work any longer, change to gmail.
Signed-off-by: NLey Foon Tan <ley.foon.tan@intel.com>

Versions of U-Boot before 2014.01 created a symlink from include/asm to
the architecture-specific header directory.

If an ARM board is build with that old version, then sandbox is built on
a more recent version (both with in-tree builds), the include/asm symlink
confuses the build system. It picks up the ARM headers when it should be
using the sandbox ones.

Since 2014 U-Boot has only created a symlink inside the include/asm/
directory and only for out-of-tree builds. So for in-tree builds it does
not expect to see an include/asm symlink. It is not removed by
'make mrproper'. It does show up with 'git status' but is easy enough to
miss.

Add include/asm to the files to remove with 'make mkproper'. For recent
U-Boot builds this has no effect, since include/asm is a directory, not a
file. If the include/asm symlink is there, it will be removed.
Reported-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NSimon Glass <sjg@chromium.org>

s/psci_features/request_psci_features/g for the case when both
ARCH_SUPPORT_PSCI=y and ARM_PSCI_FW=y, that leads to these
compilation issues:

drivers/firmware/psci.c:69:12: error: conflicting types for 'psci_features'
   69 | static int psci_features(u32 psci_func_id)
      |            ^~~~~~~~~~~~~
In file included from drivers/firmware/psci.c:23:
./arch/arm/include/asm/system.h:548:5: note: previous declaration of 'psci_features' was here
  548 | s32 psci_features(u32 function_id, u32 psci_fid);
      |     ^~~~~~~~~~~~~
Tested-by: NAlexandru Gagniuc <mr.nuke.me@gmail.com>
Reported-by: NAlexandru Gagniuc <mr.nuke.me@gmail.com>
Fixes: b7135b03 ("psci: add features/reset2 support")
Signed-off-by: NIgor Opaniuk <igor.opaniuk@foundries.io>

This patch tries to distinguish two error messages.
Signed-off-by: Npeng.wang@smartm.com <peng.wang@smartm.com>

Python3 taken from the PATH causes build issues when pylibfdt bindings are
generated with Yocto SDK.

Python3 provided as a part of SDK is not compatible with host Python3,
therefore binding build breaks with following errors:

scripts/dtc/pylibfdt/libfdt_wrap.c:154:11: fatal error: Python.h: No such file or directory
  154 | # include <Python.h>
      |           ^~~~~~~~~~

Do not enforce the python3 from the PATH and make it conditionally-assigned
so it can be overridden from outside of build system. Keep the default
assignment to point to version that is taken from the PATH.

Similar fix has been introduced in b48bfc74 ("tools: allow to override
python"), where conditional assignment is used for python executable to
address similar build errors.
Signed-off-by: NAndrey Zhizhikin <andrey.zhizhikin@leica-geosystems.com>
Cc: Simon Glass <sjg@chromium.org>
Fixes: e91610da ("kconfig: re-sync with Linux 4.17-rc4")
Reviewed-by: NSimon Glass <sjg@chromium.org>

- Add base support for Marvell OcteonTX2 CN9130 DB (mostly done
  by Kostya)
- Sync Armada 8k MMU setup with Marvell version (misc Marvell
  authors)
- spi: kirkwood: Some fixes especially for baudrate generation
  (misc Marvell authors)
- mvebu: x530: Reduce SPL image size (Stefan)
- Rename "rx_training" to "mvebu_comphy_rx_training" (Stefan)

Currently all assembly optimized implementation of memory routines
show up at the top level of the RISC-V architecture Kconfig menu.
Let's group them together into a submenu.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>

At present U-Boot SPL fails to boot on SiFive Unleashed board, due
to a load address misaligned exception happens when loading the FIT
image in spl_load_simple_fit(). The exception happens in memmove()
which is called by fdt_splice_().

Commit 8f0dc4cf introduces an assembly version of memmove but
it does take misalignment into account (it checks if length is a
multiple of machine word size but pointers need also be aligned).
As a result it will generate misaligned load/store for the majority
of cases and causes significant performance regression on hardware
that traps misaligned load/store and emulate them using firmware.

The current behaviour of memcpy is that it checks if both src and
dest pointers are co-aligned (aka congruent modular SZ_REG). If
aligned, it will copy data word-by-word after first aligning
pointers to word boundary. If src and dst are not co-aligned,
however, byte-wise copy will be performed.

This patch was taken from the Linux kernel patch [1], which has not
been applied at the time being. It fixes the memmove and optimises
memcpy for misaligned cases. It will first align destination pointer
to word-boundary regardless whether src and dest are co-aligned or
not. If they indeed are, then wordwise copy is performed. If they
are not co-aligned, then it will load two adjacent words from src
and use shifts to assemble a full machine word. Some additional
assembly level micro-optimisation is also performed to ensure more
instructions can be compressed (e.g. prefer a0 to t6).

With this patch, U-Boot boots again on SiFive Unleashed board.

[1] https://patchwork.kernel.org/project/linux-riscv/patch/20210216225555.4976-1-gary@garyguo.net/

Fixes: 8f0dc4cf ("riscv: assembler versions of memcpy, memmove, memset")
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>

If /chosen was missing, chosen_offset would never get updated with the new
/chosen node. This would cause fdt_setprop_u32 to fail. This patch fixes
this by setting chosen_offset. In addition, log any errors from setting
boot-hartid as well.

Fixes: 5370478d ("riscv: Add boot hartid to device tree")
Signed-off-by: NSean Anderson <seanga2@gmail.com>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NRick Chen <rick@andestech.com>
Reviewed-by: NAtish Patra <atish.patra@wdc.com>

At present there is only one Kconfig option CONFIG_SIFIVE_CLINT to
control the enabling of SiFive CLINT support in both SPL (M-mode)
and U-Boot proper (S-mode). So for a typical SPL config that the
SiFive CLINT driver is enabled in both SPL and U-Boot proper, that
means the S-mode U-Boot tries to access the memory-mapped CLINT
registers directly, instead of the normal 'rdtime' instruction.

This was not a problem before, as the hardware does not forbid the
access from S-mode. However this becomes an issue now with OpenSBI
commit 8b569803475e ("lib: utils/sys: Add CLINT memregion in the root domain")
that the SiFive CLINT register space is protected by PMP for M-mode
access only. U-Boot proper does not boot any more with the latest
OpenSBI, that access exceptions are fired forever from U-Boot when
trying to read the timer value via the SiFive CLINT driver in U-Boot.

To solve this, we need to split current SiFive CLINT support between
SPL and U-Boot proper, using 2 separate Kconfig options.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSean Anderson <seanga2@gmail.com>

This fixes two minor format issues of the ax25-ae350 reST file.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NRick Chen <rick@andestech.com>

Even if only USB gadget is defined, dwc3 generic driver enables
a definition and probe/remove functions for host driver.

This enables the definition if USB_HOST is enabled only.
Signed-off-by: NKunihiko Hayashi <hayashi.kunihiko@socionext.com>

All newer Allwinner SoCs (since about 2013) miss the CONFIGDATA register
in their MUSB implementation, so they need a quirk to hardcode this.

Currently this quirk depends on listing the SoCs affected in musb_reg.h,
which means that this list needs to grow with every new chip.

Move the quirk feature into Kconfig, next to PIO_ONLY, and change the
default to y (for Allwinner builds), while listing the early
implementations as exceptions.

This fixes USB peripheral operation on some newer SoCs, which were not
explicitly listed before.

Tested on H6, H616, R40 (which were broken before), and also on the H5
and A20, for regressions.
Signed-off-by: NAndre Przywara <andre.przywara@arm.com>

This patch adds the base support for the Marvell Octeon TX2 CN913x DB.
Only one defconfig is added with this patch. Other board variants are
available (NAND, MMC booting) and images for these boards can be
generated by following the documentation added in the included README.
Signed-off-by: NKonstantin Porotchkin <kostap@marvell.com>
Signed-off-by: NStefan Roese <sr@denx.de>

This patch adds the dtsi/dts files needed to support the Marvell
Octeon TX2 CN913x DB. This is only the base port with not all
interfaces supported fully.
Signed-off-by: NKonstantin Porotchkin <kostap@marvell.com>
Signed-off-by: NStefan Roese <sr@denx.de>

Rename the misleading cmd "rx_training" to "mvebu_comphy_rx_training" to
avoid confusion and mixup with DDR3/4 training. This makes it clear,
that this command is platform specific and handles the COMPHY RX
training.

Also depend this cmd on ARMADA_8K and not TARGET_MVEBU_ARMADA_8K to make
is available for OcteonTX2 CN913x.
Signed-off-by: NStefan Roese <sr@denx.de>
Cc: Pali Rohár <pali@kernel.org>
Cc: Marek Behun <marek.behun@nic.cz>
Cc: Kostya Porotchkin <kostap@marvell.com>
Cc: Nadav Haklai <nadavh@marvell.com>
Acked-by: NMarek Behún <marek.behun@nic.cz>
Acked-by: NPali Rohár <pali@kernel.org>

The pcie_dw_mvebu configure ATU regions for memory, configuration
and IO space types. However the latter is not obligatory
and when not specified in the device tree, causes wrong
ATU configuration. Fix that by adding a dependency on the
detected PCIE regions count.
Signed-off-by: NMarcin Wojtas <mw@semihalf.com>
Reviewed-on: https://sj1git1.cavium.com/18136Reviewed-by: NKostya Porotchkin <kostap@marvell.com>
Tested-by: NKostya Porotchkin <kostap@marvell.com>

Some of the setups including cn9130 opens mmio window starting from
0xc0000000, reflect it in the u-boot code.
Signed-off-by: NGrzegorz Jaszczyk <jaz@semihalf.com>
Signed-off-by: NKostya Porotchkin <kostap@marvell.com>
Signed-off-by: NStefan Roese <sr@denx.de>

Signed-off-by: NGrzegorz Jaszczyk <jaz@semihalf.com>
Signed-off-by: NStefan Roese <sr@denx.de>

There is region left by ATF, which needs to remain in memory to provide RT
services. To prevent overwriting it by u-boot, do not provide any mapping
for this memory region, so any attempt to access it will trigger
synchronous exception.

Update sr 2021-04-12:
Don't update armada3700/cpu.c mmu table, as this has specific changes
included in mainline.
Signed-off-by: NGrzegorz Jaszczyk <jaz@semihalf.com>
Signed-off-by: NStefan Roese <sr@denx.de>

1. RAM: base address 0x0 size 2Gbytes
2. MMIO: base address 0xf0000000 size 1Gbytes
Signed-off-by: NOfir Fedida <ofedida@marvell.com>
Signed-off-by: NStefan Roese <sr@denx.de>

After commit 1fe929ed497bcc8975be8d37383ebafd22b99dd2
("spi: kirkwood: prevent configuring speed exceeding max controller freq")
the spi frequency could be set to 0 on platform where spi-max-frequency
is not defined (e.g. on armada-388-gp). Prevent limiting speed in
mentioned cases.
Signed-off-by: NGrzegorz Jaszczyk <jaz@semihalf.com>
Tested-by: NKostya Porotchkin <kostap@marvell.com>
Reviewed-by: NMarcin Wojtas <marcin@marvell.com>
Reviewed-by: NKostya Porotchkin <kostap@marvell.com>
Signed-off-by: NStefan Roese <sr@denx.de>