Prior to introduction of modifications in rsassa_pss functions
related to padding verification, doing a pass to update
const-correctness in targeted functions to comply with
coding-rules and avoid const-cast

Signed-off-by: SESA644425 <gioja.hermann@non.se.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

A big part is the DM pinctrl driver, which allows us to get rid of quite
some custom pinmux code and make the whole port much more robust. Many
thanks to Samuel for that nice contribution! There are some more or less
cosmetic warnings about missing clocks right now, I will send the trivial
fixes for that later.
Another big chunk is the mkimage upgrade, which adds RISC-V and TOC0
(secure images) support. Both features are unused at the moment, but I
have an always-secure board that will use that once the DT lands in the
kernel.
On top of those big things we have some smaller fixes, improving the
I2C DM support, fixing some H6/H616 early clock setup and improving the
eMMC boot partition support.

The gitlab CI completed successfully, including the build test for all
161 sunxi boards. I also boot tested on a A64, A20, H3, H6, and F1C100
board. USB, SD card, eMMC, and Ethernet all work there (where applicable).

Most Allwinner sunxi SoCs have separate boot ROMs in non-secure and
secure mode. The "non-secure" or "normal" boot ROM (NBROM) uses the
existing sunxi_egon image type. The secure boot ROM (SBROM) uses a
completely different image type, known as TOC0.

A TOC0 image is composed of a header and two or more items. One item
is the firmware binary. The others form a chain linking the firmware
signature to the root-of-trust public key (ROTPK), which has its hash
burned in the SoC's eFuses. Signatures are made using RSA-2048 + SHA256.

The pseudo-ASN.1 structure is manually assembled; this is done to work
around bugs/quirks in the boot ROM, which vary between SoCs. This TOC0
implementation has been verified to work with the A50, A64, H5, H6,
and H616 SBROMs, and it may work with other SoCs.

Signed-off-by: Samuel Holland <samuel@sholland.org>
Acked-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

This commit enhances mkimage to update the node
/image/pre-load/sig with the public key.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>

Add a stage pre-load to the command bootm.
Right now, this stage may be used to read a
header and check the signature of the full
image.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>

Add a stage pre-load that could
check or modify an image.

For the moment, only a header with a signature is
supported. This header has the following format:
- magic : 4 bytes
- version : 4 bytes
- header size : 4 bytes
- image size : 4 bytes
- offset image signature : 4 bytes
- flags : 4 bytes
- reserved0 : 4 bytes
- reserved1 : 4 bytes
- sha256 of the image signature : 32 bytes
- signature of the first 64 bytes : n bytes
- image signature : n bytes
- padding : up to header size

The stage uses a node /image/pre-load/sig to
get some informations:
- algo-name (mandatory) : name of the algo used to sign
- padding-name : name of padding used to sign
- signature-size : size of the signature (in the header)
- mandatory : set to yes if this sig is mandatory
- public-key (madatory) : value of the public key

Before running the image, the stage pre-load checks
the signature provided in the header.

This is an initial support, later we could add the
support of:
- ciphering
- uncompressing
- ...

Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>

At present mkimage displays the node information but it is not clear what
signing action was taken. Add a message that shows it. For now it only
supports showing a single signing action, since that is the common case.

Sample:

   Signature written to 'sha1-basic/test.fit',
       node '/configurations/conf-1/signature'
   Public key written to 'sha1-basic/sandbox-u-boot.dtb',
       node '/signature/key-dev'

Signed-off-by: Simon Glass <sjg@chromium.org>

It is useful to know where the verification data was written. Update the
API to return this.

Signed-off-by: Simon Glass <sjg@chromium.org>

At present we rely on the key blob being in the global_data fdt_blob
pointer. This is true in U-Boot but not with tools. For clarity, pass the
parameter around.

Signed-off-by: Simon Glass <sjg@chromium.org>

Add some more comments to explain what is going on in the signing
functions. Fix two repeated typos.

Signed-off-by: Simon Glass <sjg@chromium.org>