The current set method is broken; a simple test case is to first set
the date to something in April, then change the date to 31st May:

=> date 040412122020.34
Date: 2020-04-04 (Saturday)    Time: 12:12:34
=> date 053112122020.34
Date: 2020-05-01 (Friday)    Time: 12:12:34

or via the amending of the existing rtc_set_get test case similarly:

$ ./u-boot -T -v
=> ut dm rtc_set_get
Test: dm_test_rtc_set_get: rtc.c
expected: 31/08/2004 18:18:00
actual: 01/08/2004 18:18:00

The problem is that after each register write,
sandbox_i2c_rtc_complete_write() gets called and sets the internal
time from the current set of registers. However, when we get to
writing 31 to mday, the registers are in an inconsistent state (mon is
still 4), so the mktime machinery ends up translating April 31st to
May 1st. Upon the next register write, the registers are populated by
sandbox_i2c_rtc_prepare_read(), so the 31 we just wrote to mday gets
overwritten by a 1.

Fix it by writing all registers at once, and for consistency, update
the get method to retrieve them all with one "i2c transfer".
Reviewed-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NHeiko Schocher <hs@denx.de>
Signed-off-by: NRasmus Villemoes <rasmus.villemoes@prevas.dk>

Mostly as an aid for debugging RTC drivers, provide a command that can
be used to read/write arbitrary registers (assuming the driver
provides the read/write methods or their single-register-at-a-time
variants).
Reviewed-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NHeiko Schocher <hs@denx.de>
Signed-off-by: NRasmus Villemoes <rasmus.villemoes@prevas.dk>

Reviewed-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NHeiko Schocher <hs@denx.de>
Signed-off-by: NRasmus Villemoes <rasmus.villemoes@prevas.dk>

This simply consists of renaming the existing pcf2127_read_reg()
helper to follow the naming of the other
methods (i.e. pcf2127_rtc_<method name>) and changing the type of its
"len" parameter.
Reviewed-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NHeiko Schocher <hs@denx.de>
Signed-off-by: NRasmus Villemoes <rasmus.villemoes@prevas.dk>

Similar to how the dm_rtc_{read,write} functions fall back to using
the {read,write}8 methods, do the opposite in the rtc_{read,write}8
functions.

This way, each driver only needs to provide either ->read8 or ->read
to make both rtc_read8() and dm_rtc_read() work - without this, a
driver that provides ->read() would most likely just duplicate the
logic here for implementing a ->read8() method in term of its ->read()
method. The same remarks of course apply to the write case.
Reviewed-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NHeiko Schocher <hs@denx.de>
Signed-off-by: NRasmus Villemoes <rasmus.villemoes@prevas.dk>

Similar to dm_rtc_read(), introduce a helper that allows the caller to
write multiple consecutive 8-bit registers with one call. If the
driver provides the ->write method, use that, otherwise loop using
->write8.
Reviewed-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NHeiko Schocher <hs@denx.de>
Signed-off-by: NRasmus Villemoes <rasmus.villemoes@prevas.dk>

Some users may want to read multiple consecutive 8-bit
registers. Instead of each caller having to implement the loop,
provide a dm_rtc_read() helper. Also, allow a driver to provide a
->read method, which can be more efficient than reading one register
at a time.
Reviewed-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NHeiko Schocher <hs@denx.de>
Signed-off-by: NRasmus Villemoes <rasmus.villemoes@prevas.dk>

Current driver calls the devfdt_get_addr to get the base address
of lpi2c controller in each sub-functions. Since the devfdt_get_addr
accesses the DTB and translate the address, it introduces much
overhead.
Improve the codes to use private variable which has recorded the
base address from probe.
Signed-off-by: NYe Li <ye.li@nxp.com>
Reviewed-by: NPeng Fan <peng.fan@nxp.com>

Add I2C board support for Cortina Access Presidio Engineering Board
Signed-off-by: NAlex Nemirovsky <alex.nemirovsky@cortina-access.com>
CC: Heiko Schocher <hs@denx.de>
Reviewed-by: NHeiko Schocher <hs@denx.de>

Add I2C controller support for Cortina Access CAxxxx SoCs
Signed-off-by: NArthur Li <arthur.li@cortina-access.com>
Signed-off-by: NAlex Nemirovsky <alex.nemirovsky@cortina-access.com>
CC: Heiko Schocher <hs@denx.de>
Reviewed-by: NHeiko Schocher <hs@denx.de>

hs: fixed build error, add include log.h

Add support for I2C controllers found on Octeon II/III and Octeon TX
TX2 SoC platforms.
Signed-off-by: NAaron Williams <awilliams@marvell.com>
Signed-off-by: NSuneel Garapati <sgarapati@marvell.com>
Signed-off-by: NStefan Roese <sr@denx.de>
Cc: Heiko Schocher <hs@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Cc: Aaron Williams <awilliams@marvell.com>
Cc: Chandrakala Chavva <cchavva@marvell.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NHeiko Schocher <hs@denx.de>
Reviewed-by: NRayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>

- mem cmd improvements
- TPM fixes
- SPL/NAND/FIT fixes
- RSA improvements

rsa_verify() expects a memory region and wants to do the hashing itself,
but there may be cases where the hashing is done via other means,
like hashing a squashfs rootfs.

So add rsa_verify_hash() to allow verifiying a signature against
an existing hash. As this entails the same verification routines
we can just move the relevant code over from rsa_verify() and also
call rsa_verify_hash() from there.
Signed-off-by: NHeiko Stuebner <heiko.stuebner@theobroma-systems.com>

It is useful to be able to find hex values and strings in a memory range.
Add a command to support this.

cmd: Fix 'md' and add a memory-search command
At present 'md.q' is broken. This series provides a fix for this. It also
implements a new memory-search command called 'ms'. It allows searching
memory for hex and string data.
END
Signed-off-by: NSimon Glass <sjg@chromium.org>

This is defined only when __lp64__ is defined. That means that ulong is
64 bits long. Therefore we don't need to use a separate u64 type on those
architectures.

Fix up the code to take advantage of that, removing the preprocessor
conditions.

Also include the header file that defines MEM_SUPPORT_64BIT_DATA. It is
included by env.h in this file, but that might not last forever.
Signed-off-by: NSimon Glass <sjg@chromium.org>

This is defined only when __lp64__ is defined. That means that ulong is
64 bits long. Therefore we don't need to use a separate u64 type on those
architectures.

Fix up the code to take advantage of that, removing the preprocessor
conditions.

Also include the missing header file that defines MEM_SUPPORT_64BIT_DATA

Fixes: 09140113 ("command: Remove the cmd_tbl_t typedef")
Signed-off-by: NSimon Glass <sjg@chromium.org>

This is defined only when __lp64__ is defined. That means that ulong is
64 bits long. Therefore we don't need to use a separate u64 type on those
architectures.

Fix up the code to take advantage of that, removing the preprocessor
conditions.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NStefan Roese <sr@denx.de>

It is a bit painful to have #ifdefs in the middle of the help for each
command. Add a macro to avoid this.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NStefan Roese <sr@denx.de>

Define this macro always so we don't need the preprocessor to check it.
Convert the users to #if instead of #ifdef.

Note that '#if MEM_SUPPORT_64BIT_DATA' does not give an error if the
macro is not define. It just assumes zero.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NStefan Roese <sr@denx.de>

Replacing the ret variable with err and handling first the error
condition about the value returned by the spl_nand_fit_read routine,
improves the code readability.
Furthermore, the 'else' int the 'else return ret' instruction was
useless.

cc: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: NDario Binacchi <dariobin@libero.it>

The offset at which the image to be loaded from NAND is located is
retrieved from the itb header. The presence of bad blocks in the area
of the NAND where the itb image is located could invalidate the offset
which must therefore be adjusted taking into account the state of the
sectors concerned.

cc: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: NDario Binacchi <dariobin@libero.it>
Reviewed-by: NMichael Trimarchi <michael@amarulasolutions.com>

If uboot does not embed its device tree and the FIT loading function
returns error in case of failure in the FDT append, the redundant itb
image could be loaded.

cc: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: NDario Binacchi <dariobin@libero.it>
Reviewed-by: NMichael Trimarchi <michael@amarulasolutions.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

U-Boot adopted the kernel-doc annotation style.

cc: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: NDario Binacchi <dariobin@libero.it>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Verifying FIT images obviously needs the rsa parts of crypto
support and while main uboot always compiles crypto support,
it's optional for SPL and we should thus select the necessary
option to not end up in compile errors like:

    u-boot/lib/rsa/rsa-verify.c:328: undefined reference to `rsa_mod_exp'

So select SPL_CRYPTO_SUPPORT in SPL_FIT_SIGNATURE.
Signed-off-by: NHeiko Stuebner <heiko.stuebner@theobroma-systems.com>
Reviewed-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

rsa-checsum needs support for hash functions or else will run into
compile errors like:
u-boot/lib/rsa/rsa-checksum.c:28: undefined reference to `hash_progressive_lookup_algo'

So similar to the main FIT_SIGNATURE entry selects HASH,
select SPL_HASH_SUPPORT for SPL_FIT_SIGNATURE.

Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: NHeiko Stuebner <heiko.stuebner@theobroma-systems.com>
Reviewed-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

padding_pss_verify only works with the default pss salt setting of -2
(length to be automatically determined based on the PSS block structure)
not -1 (salt length set to the maximum permissible value), which makes
verifications of signatures with that saltlen fail.

Until this gets implemented at least document this behaviour.
Signed-off-by: NHeiko Stuebner <heiko.stuebner@theobroma-systems.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

n, rr and rrtmp are used for internal calculations, but in the end
the results are copied into separately allocated elements of the
actual key_prop, so the n, rr and rrtmp elements are not used anymore
when returning from the function and should of course be freed.
Signed-off-by: NHeiko Stuebner <heiko.stuebner@theobroma-systems.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

When calculating rrtmp/rr rsa_gen_key_prop() tries to make
(((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and
(((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[]
with rlen being num_bits * 2

On a 4096bit key this comes down to to 257 uint32_t elements
in rr and 256 elements in rrtmp but with the current allocation
rr and rrtmp only have 129 uint32_t elements.

On 2048bit keys this works by chance as the defined max_rsa_size=4096
allocates a suitable number of elements, but with an actual 4096bit key
this results in other memory parts getting overwritten.

So as suggested by Heinrich Schuchardt just use the actual bit-size
of the key as base for the size calculation, in turn making the code
compatible to any future keysizes.
Suggested-by: NHeinrich Schuchardt <xypron.debian@gmx.de>
Signed-off-by: NHeiko Stuebner <heiko.stuebner@theobroma-systems.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements.
Reviewed-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>

The exponent field of struct key_prop gets allocated an uint64_t,
and the contents are positioned from the back, so an exponent of
"0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1"

Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len
to the size returned from the parser, while on the other hand the
when getting the key from the devicetree exp_len always gets set to
sizeof(uint64_t).

So bring that in line with the established code.
Signed-off-by: NHeiko Stuebner <heiko.stuebner@theobroma-systems.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Right now in multiple places there are only checks for the full
CONFIG_RSA_VERIFY_WITH_PKEY option, not split into main,spl,tpl variants.

This breaks when the rsa functions get enabled for SPL, for example to
verify u-boot proper from spl.

So fix this by using the existing helpers to distinguis between
build-steps.
Signed-off-by: NHeiko Stuebner <heiko.stuebner@theobroma-systems.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

While the SPL may want to do signature checking this won't be
the case for TPL in all cases, as TPL is mostly used when the
amount of initial memory is not enough for a full SPL.

So on a system where SPL uses DM but TPL does not we currently
end up with a TPL compile error of:

    lib/rsa/rsa-verify.c:48:25: error: dereferencing pointer to incomplete type ‘struct checksum_algo’

To prevent that change the $(SPL_) to $(SPL_TPL_) to distinguish
between both. If someone really needs FIT signature checking in
TPL as well, a new TPL_RSA_VERIFY config symbol needs to be added.
Signed-off-by: NHeiko Stuebner <heiko.stuebner@theobroma-systems.com>
Reviewed-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Even in boot scripts it may be needed to "panic" when all options
are exhausted and the device specification specifies hanging
instead of resetting the board.

So add a new panic command that just wraps around the core panic
call in U-Boot and can take an optional message.
Signed-off-by: NHeiko Stuebner <heiko.stuebner@theobroma-systems.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NTom Rini <trini@konsulko.com>

Add linefeeds before and after the announce string. This makes the
output easier to read, especially if some text follows the announce
message without a specific additional CR.
Signed-off-by: NStefan Roese <sr@denx.de>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

tpm_tis_spi.c directly includes tpm_tis.h and tpm-v2.h which both
define the same enums (see e.g. TPM_ACCESS_VALID). Add an #ifndef to
prevent redeclaration errors.
Signed-off-by: NJohannes Holland <johannes.holland@infineon.com>

Add support for TPM2 GetRandom command
Signed-off-by: NDhananjay Phadke <dphadke@linux.microsoft.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

This solves a compatibility issue with Linux device trees
that contain TPMv2.x hardware. So it's easier to import DTS
from upstream kernel when migrating board init from C code
to DTS.

The issue is that fallback binding is different between Linux
and u-Boot.

Linux: "tcg,tpm_tis-spi"
U-Boot: "tis,tpm2-spi"

As there are currently no in-tree users of the U-Boot binding,
it makes sense to use Linux fallback binding.
Signed-off-by: NBruno Thomsen <bruno.thomsen@gmail.com>
Reviewed-by: NTom Rini <trini@konsulko.com>

- Add proper Odroid-N2 board support code
- Add support for Odroid-C4 single board computer

commit 2bd261dd ("gpio: search for gpio label if gpio is not found through bank name")

disabled DM_GPIO_LOOKUP_LABEL which is needed
in sandbox defconfigs, as we have tests for this
functionality.
Signed-off-by: NHeiko Schocher <hs@denx.de>

The PHY needs a reset in order to be functionnal for U-Boot, add the old
PHY reset bindings for dwmac until we support the new bindings in the PHY node.
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
Tested-by: NAnand Moon <linux.amoon@gmail.com>

Odroid C4 is an Amlogic SM1 device, the board config and board documentation
are adapted from the Odroid-N2 support from the same vendor.
Signed-off-by: NChristian Hewitt <christianshewitt@gmail.com>
[narmstrong: fix odroid-c4.rst typos and structure]
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
Tested-by: NAnand Moon <linux.amoon@gmail.com>