Merge tag 'ti-v2021.07-rc1' of https://source.denx.de/u-boot/custodians/u-boot-ti

- Support for pinmux status command on beaglebone
- Updates for MMC speed modes for J721e-evm
- Fix MMC booting on omap35_logic_somlv board

Merge branch '2021-04-16-env-updates'

- SPI Flash ENV improvements / cleanups
- Redundant support for FAT
- Assorted bugfixes

env: sf: remove the static env_flash variable

As the the SPI flash is probed and is released in each ENV sf function
the env_flash no more need to be static.

This patch move this device handle as local variable of each function and
simplify the associated code (env_flash is never == NULL when
setup_flash_device is called).

Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

env: sf: add missing spi_flash_free

Free the SPI resources by calling spi_flash_free() in each env sf
function to avoid issue for other SPI users.

Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

env: sf: add support of command env erase

Add support of opts erase for env in SPI flash;
this opts is used by command 'env erase'.

This command only fills the env offset by 0x0 (bit flip to 0) and
the saved environment becomes invalid (with bad CRC).

It doesn't erase the sector here to avoid issue when the sector
is larger than the env (i.e. embedded when
CONFIG_ENV_SECT_SIZE > CONFIG_ENV_SIZE).

The needed sector erase will be managed in the next "env save" command,
using the opt ".save", before to update the environment in SPI flash.

Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

env: sf: update the use of macro ENV_SAVE_PTR

Remove CONFIG_IS_ENABLED(SAVEENV) as it is already tested in
the ENV_SAVE_PTR macro.

Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

env: add ENV_ERASE_PTR macro

Add ENV_ERASE_PTR macro to handle erase opts and remove the associated
ifdef.

This patch is a extension of previous commit 82b2f4135719 ("env_internal.h:
add alternative ENV_SAVE_PTR macro").

Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

env: Fix invalid env handling in env_init()

This fixes the case where there are multiple environment drivers, one of
them is the default environment one, and it is followed by an environment
driver which does not implement .init() callback. The default environment
driver sets gd->env_valid to ENV_INVALID and returns 0 from its .init()
callback implementation, which is valid behavior for default environment.

Since the subsequent environment driver does not implement .init(), it
also does not modify the $ret variable in the loop. Therefore, the loop
is exited with gd->env_valid=ENV_INVALID and ret=0, which means that the
code further down in env_init() will not reset the environment to the
default one, which is incorrect.

This patch sets the $ret variable back to -ENOENT in case the env_valid
is set to ENV_INVALID by an environment driver, so that the environment
would be correctly reset back to default one, unless a subsequent driver
loads a valid environment.

Signed-off-by: Marek Vasut <marex@denx.de>
Tested-By: Tim Harvey <tharvey@gateworks.com>

env/fat.c: support redund environment

Signed-off-by: Brandon Maier <brandon.maier@rockwellcollins.com>
CC: Joe Hershberger <joe.hershberger@ni.com>
CC: Wolfgang Denk <wd@denx.de>

env: Fix warning when forcing environment without ENV_ACCESS_IGNORE_FORCE

Since commit 0f036bf4b87e ("env: Warn on force access if ENV_ACCESS_IGNORE_FORCE set")
a warning message is displayed when setenv -f is used WITHOUT
CONFIG_ENV_ACCESS_IGNORE_FORCE, but the variable is set anyway, resulting
in lots of log pollution.

env_flags_validate() returns 0 if the access is accepted, or non zero
if it is refused.

So the original code
#ifndef CONFIG_ENV_ACCESS_IGNORE_FORCE
if (flag & H_FORCE)
return 0;
#endif

was correct, it returns 0 (accepts the modification) if forced UNLESS
IGNORE_FORCE is set (in which case access checks in the following code
are applied). The broken patch just added a printf to the force accepted
case.

To obtain the intent of the patch we need this:
if (flag & H_FORCE) {
#ifdef CONFIG_ENV_ACCESS_IGNORE_FORCE
printf("## Error: Can't force access to \"%s\"\n", name);
#else
return 0;
#endif
}

Fixes: 0f036bf4b87e ("env: Warn on force access if ENV_ACCESS_IGNORE_FORCE set")

Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group>

env: increment redund flag on read fail

If one of the reads fails when importing redundant environments (a
single read failure), the env_flags wouldn't get initialized in
env_import_redund(). If a user then calls saveenv, the new environment
will have the wrong flags value. So on the next load the new environment
will be ignored.

While debugging this, I also noticed that env/sf.c was not correctly
handling a single read failure, as it would not check the crc before
assigning it to gd->env_addr.

Having a special error path for when there is a single read failure
seems unnecessary and may lead to future bugs. Instead collapse the
'single read failure' error to be the same as a 'single crc failure'.
That way env_check_redund() either passes or fails, and if it passes we
are guaranteed to have checked the CRC.

Signed-off-by: Brandon Maier <brandon.maier@rockwellcollins.com>
CC: Joe Hershberger <joe.hershberger@ni.com>
CC: Wolfgang Denk <wd@denx.de>
CC: Heiko Schocher <hs@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>

env: add CONFIG_ENV_SECT_SIZE_AUTO

This is roughly the U-Boot side equivalent to commit
e282c422e0 (tools: fw_env: use erasesize from MEMGETINFO ioctl). The
motivation is the case where one has a board with several revisions,
where the SPI flashes have different erase sizes.

In our case, we have an 8K environment, and the flashes have erase
sizes of 4K (newer boards) and 64K (older boards). Currently, we must
set CONFIG_ENV_SECT_SIZE to 64K to make the code work on the older
boards, but for the newer ones, that ends up wasting quite a bit of
time reading/erasing/restoring the last 56K.

At first, I wanted to allow setting CONFIG_ENV_SECT_SIZE to 0 to mean
"use the erase size the chip reports", but that config
option is used in a number of preprocessor conditionals, and shared
between ENV_IS_IN_FLASH and ENV_IS_IN_SPI_FLASH.

So instead, introduce a new boolean config option, which for now can
only be used with ENV_IS_IN_SPI_FLASH. If left off, there's no change
in behaviour.

The only slightly annoying detail is that, when selected, the compiler
is apparently not smart enough to see that the the saved_size and
saved_offset variables are only used under the same "if (sect_size >
CONFIG_ENV_SIZE)" condition as where they are computed, so we need to
initialize them to 0 to avoid "may be used uninitialized" warnings.

On our newer boards with the 4K erase size, saving the environment now
takes 0.080 seconds instead of 0.53 seconds, which directly translates
to that much faster boot time since our logic always causes the
environment to be written during boot.

Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>

env/sf.c: use a variable to hold the sector size

As preparation for the next patch, use a local variable to represent
the sector size. No functional change.

Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>

arm: dts: k3-j721e-main: Update the speed modes supported and their itap delay values for MMCSD subsystems

According to latest errata of J721e [1], HS400 mode is not supported
in MMCSD0 subsystem (i2024) and SDR104 mode is not supported in MMCSD1/2
subsystems (i2090). Therefore, replace mmc-hs400-1_8v with mmc-hs200-1_8v
in MMCSD0 subsystem and add a sdhci mask to disable SDR104 speed mode.

Also, update the itap delay values for all the MMCSD subsystems according
the latest J721e data sheet[2]

[1] - https://www.ti.com/lit/er/sprz455/sprz455.pdf
[2] - https://www.ti.com/lit/ds/symlink/tda4vm.pdf

Fixes: 70e167495ab2 ("arm: dts: k3-j721e: Sync Linux v5.11-rc6 dts into U-Boot")
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>

Merge https://gitlab.denx.de/u-boot/custodians/u-boot-sunxi

This adds support for devices with R40 dual rank DRAM, and asymmetric
A64 DRAM devices like the Pinephone/3GB.
Also we enable automatic gzipped kernel support, and allow scripted
DT overlay support. The rest of the patches are cleanups, but also
some sunxi-specific preparatory patches for USB3.0 and improved HDMI
support. The bulk of those changes will go through other trees, though.

Build-tested for all 156 sunxi boards, and boot tested on a A64, A20, R40,
H5, H6 and H616 board. USB, SD card, eMMC, HDMI and Ethernet all work
there (where applicable), with the exception of Ethernet on the H5. Since
this is already broken in v2021.04, I will send a separate fix.

sunxi: video: select dw-hdmi in Kconfig, not Makefile

Currently sunxi Makefile manually specifies full path to dw-hdmi common
code. However, that is not needed because it can be selected in Kconfig
instead.

Select proper symbol in Kconfig and drop path from Makefile.

Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

sunxi: arm64: Add addresses for compressed kernel load

The "booti" command to load arm64 Linux kernels supports automatic
decompression of zipped kernel images, but relies on some environment
variables to point to usable buffer RAM.

Add those variables and let them point to some default values, that
should cover most use-cases.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>

sunxi: binman: Do not hardcode U-Boot load address

The FIT description has access to the configuration variables. Use the
appropriate variable instead of hardcoding the address.

Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

sunxi: binman: Respect the default FIT configuration

binman can fill in the default FIT configuration index as selected by
the "default-dt" argument, which is set to CONFIG_DEFAULT_DEVICE_TREE.
Let's respect the user's configuration by taking advantage of this
feature, instead of always defaulting to the first device tree in
CONFIG_OF_LIST.

Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

clk: sunxi: h6: Add XHCI clocks

The XHCI controller has its own clock and reset. Add them.

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

clk: sunxi: Add a dummy clock driver for the RTC

The 32kHz clock ("LOSC") on sunxi SoCs is provided by the RTC. It is
used, among other things, by the XHCI controller in the H6. To be able
to call clk_get_bulk() on the XHCI controller, some device needs to
provide all referenced clocks.

Since LOSC is a fixed-rate always-on clock, implementation is trivial.

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

sunxi: enable dual rank memory on R40

Previously we do not have proper dual rank memory detection on R40
(because we omitted PIR_QSGATE, which does not work on R40 with our
configuration), and dual rank memory is just simply disabled as early
R40 boards available (Banana Pi M2 Ultra and Berry) have single rank
memory.

As a board with dual rank memory (Forlinx OKA40i-C) is now known to us,
we need to have a way to do memory rank detection to support that board.

Add some routine to detect memory rank by trying to access the memory
in rank 1 and check for error status of the memory controller, and then
enable dual rank memory on R40.

Similar routine can be used to detect half DQ width (which is also
detected by PIR_QSGATE on other SoCs), but it's left unimplemented
because there's no known R40 board with half DQ width now.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
[Andre: Move R40 detect code call into sunxi_dram_init()]
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

sunxi: support asymmetric dual rank DRAM on A64/R40

Previously we have known that R40 has a configuration register for its
rank 1, which allows different configuration than rank 0. Reverse
engineering of newest libdram of A64 from Allwinner shows that A64 has
this register too. It's bit 0 (which enables dual rank in rank 0
configuration register) means a dedicated rank size setup is used for
rank 1.

Now, Pine64 scheduled to use a 3GiB LPDDR3 DRAM chip (which has 2GiB
rank 0 and 1GiB rank 1) on PinePhone, that makes asymmetric dual rank
DRAM support necessary.

Add this support. The code could support both A64 and R40, but because
dual rank detection is broken on R40 now, we cannot really use it on R40
currently.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

sunxi: add fdtoverlay_addr_r environment variable

Commit 69076dff2284 ("cmd: pxe: add support for FDT overlays") added
support for loading DT overlay files to PXE boot. However, it needs
additional environment variable which points to memory location which
can be used to temporary store overlay data.

Add it and in the process unify alignment using spaces and fix comment.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

Merge branch '2021-04-14-assorted-vboot-improvements'

- Add ECDSA support to FIT images
- Improve FIT image loadables (incl fpga) support
- Further FIT improvements with SPL

Merge https://gitlab.denx.de/u-boot/custodians/u-boot-fsl-qoriq

update ls1028aqds networking protocol, config in ls1021atwr, env in ls1012a
Add seli3 board support, booke watchdog, update eTSEC support in ppc-qemu
Add DM_SERIAL and lpuart in sl28, add DM_ETH support for some of powerpc platforms

Signed-off-by: Priyanka Jain <priyanka.jain@nxp.com>

Merge https://source.denx.de/u-boot/custodians/u-boot-x86

- Minor fix to Apollo Lake devicetree bindings for FSP
- Refactor Designware PCIe drivers to core and SoC parts
- Add Amlogic Meson Designware PCIe controller driver

configs: T1042D4RDB: enable DM_ETH

Enable DM_ETH and DM_MDIO for the T1042D4RDB.

Signed-off-by: Camelia Groza <camelia.groza@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

powerpc: dts: t1042d4rdb: add FMan v3 nodes

Add the FMan v3 nodes for the T1042D4RDB. The nodes are copied over with
little modification from the Linux kernel source code.

Signed-off-by: Camelia Groza <camelia.groza@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

powerpc: dts: t1042: add QorIQ DPAA 1 FMan v3 nodes

Add the QorIQ DPAA 1 FMan v3 device tree nodes for the T1042 SoC.
The device tree nodes are copied over with little modification
from the Linux kernel source code.

Signed-off-by: Camelia Groza <camelia.groza@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

configs: T4240RDB: enable DM_ETH

Enable DM_ETH and DM_MDIO for the T4240RDB.

Signed-off-by: Camelia Groza <camelia.groza@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

powerpc: dts: qoriq: update the mdio offsets under the second FMan v3

When two FMan's are present on a board, the MDIO nodes are found at the
same offsets inside each FMan. This causes "non unique device name"
errors when registering the MDIO nodes under the second FMan. Fix this
by updating the offsets of the MDIO nodes to include the parent FMan's
offset.

Signed-off-by: Camelia Groza <camelia.groza@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

powerpc: dts: t4240rdb: add FMan v3 nodes

Add the FMan v3 nodes for the T4240RDB. The nodes are copied over with
little modification from the Linux kernel source code.

Signed-off-by: Camelia Groza <camelia.groza@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

powerpc: dts: t4240: add QorIQ DPAA 1 FMan v3 nodes

Add the QorIQ DPAA 1 FMan v3 device tree nodes for the T4240 SoC.
The device tree nodes are copied over with little modification
from the Linux kernel source code.

Signed-off-by: Camelia Groza <camelia.groza@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

configs: T2080RDB: enable DM_ETH

Enable DM_ETH and DM_MDIO for the T2080RDB.

Signed-off-by: Camelia Groza <camelia.groza@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

board: freescale: t208xrdb: fdt fixups under DM_ETH

Disable the FMan mEMAC 5 and 6 nodes from the fdt since they are not
available under the supported RCW. Also disable the associated
"fsl,dpa-ethernet" nodes that reference them.

This is a simplified version of the fdt_fixup_fman_ethernet call for
use under DM_ETH.

Signed-off-by: Camelia Groza <camelia.groza@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

powerpc: dts: t2080rdb: add FMan v3 nodes

Add the FMan v3 nodes for the T2080RDB. The nodes are copied over with
little modification from the Linux kernel source code.

Signed-off-by: Camelia Groza <camelia.groza@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

powerpc: dts: t2080: add QorIQ DPAA 1 FMan v3 nodes

Add the QorIQ DPAA 1 FMan v3 device tree nodes for the T2080 SoC.
The device tree nodes are copied over with little modification from
the Linux kernel source code.

Signed-off-by: Camelia Groza <camelia.groza@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

ls1012a: use default scan_dev_for_boot

scan_dev_for_efi is supposed to be called from scan_dev_for_boot.
However, this call is missing for ls1012a boards. As a result EFI
boot doesn’t work. Fix this issue by removing custom definition of
scan_dev_for_boot and use the default definition instead.

Signed-off-by: Mian Yousaf Kaukab <ykaukab@suse.de>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

board: sl28: add config to enable console output on SER0

Sometimes it is desireable to have the console output on the first
serial line. Introduce a configuration option for it (in the board
scope).

Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

board: sl28: enable DM_SERIAL

With all preparations in place, switch over to DM_SERIAL.

Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

board: sl28: move DM_* configs to Kconfig

Move the CONFIG_DM_* from the defconfig to the TARGET_SL28 config.

Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

armv8: fsl-layerscape: spl: call spl_early_init()

DM_SERIAL needs both the device tree as well as an early heap. Thus, we
have to call spl_early_init() to initialize the memory allocator and the
setup the device tree.

Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

armv8: fsl-layerscape: spl: add debug UART support

To use the debug UART we have to call debug_uart_init() in the SPL. Do
so as soon as possible.

As an example, here is how you can use it on a LS1028A SoC:
CONFIG_DEBUG_UART=y
CONFIG_DEBUG_UART_BASE=0x21c0500
CONFIG_DEBUG_UART_CLOCK=200000000

Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

freescale: ls1021atwr: Drop use of CONFIG_RESET

It is not recommended to use CONFIG_xxx defines for things which are not
Kconfig options. Rename this.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

doc: board: qemu-ppce500: Document eTSEC usage

Document how to launch a QEMU session with eTSEC as a network device.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

ppc: qemu: Enable eTSEC support

QEMU ppce500 target can dynamically instantiate an eTSEC device
if "-device eTSEC" is given to QEMU. This commit enables eTSEC
driver and the required fixed PHY driver to create a usable
network configuration using eTSEC.

Unlike a real world 85xx board that usually stores the eTSEC MAC
address in an EEPROM, CONFIG_NET_RANDOM_ETHADDR is required for
QEMU otherwise U-Boot ethernet initialization complains no valid
ethernet address is set.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

ppc: qemu: Create a virtual memory mapping of the platform bus

QEMU ppce500 target can dynamically instantiate an eTSEC device on
a platform bus if "-device eTSEC" is given to QEMU. It is presented
as a "simple-bus" in the device tree, with an additional compatible
string "qemu,platform".

Let's create a virtual memory mapping for it in misc_init_r(), in
preparation to adding eTSEC support.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

test: dm: Add a test case for simple-bus <ranges>

This adds a test case to verify reading <ranges> of a simple-bus is
working as expected.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

dm: core: Correctly read <ranges> of simple-bus

At present we decode simple bus <ranges> using the following assumption:

- parent #address-cells 1
- child #address-cells 1
- child #size-cells 1

However this might not always be the case.

Update to use fdt_addr_t and fdt_size_t in 'struct simple_bus_plat', and
use fdt_read_ranges() to correctly decode it according to the actual
parent and child #address-cells / #size-cells under a Kconfig option
CONFIG_SIMPLE_BUS_CORRECT_RANGE which can be turned on for any board
that needs it.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

net: tsec: Support <reg> property from the subnode "queue-group"

At present the tsec driver uses a non-standard DT bindings to get
its <reg> base / size. The upstream Linux kernel seems to require
the <reg> base / size to be put under a subnode of the eTSEC node
with a name prefix "queue-group". This is not documented in the
kernel DT bindings, but it looks every dtsi file that contains the
eTSEC node was written like this.

This commit updates the tsec driver to handle this case.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

dt-bindings: net: Update Freescale TSEC to support "queue-group"

At present the Freescale TSEC node DT bindings doc requires a <reg>
property in the TSEC node. But this might not always be the case.
In the upstream Linux kernel, there is no DT bindings doc for it
but the kernel driver tests a subnode of a name prefixed with
"queue-group", as we can see from gfar_of_init():

  for_each_available_child_of_node(np, child) {
      if (!of_node_name_eq(child, "queue-group"))
  ...

in drivers/net/ethernet/freescale/gianfar.c

Update our DT bindings to describe this alternate description.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

net: tsec: Use map_physmem() directly instead of dev_remap_addr()

dev_remap_addr() eventually calls dev_read_addr_index(), while
pdata->iobase holds the return value of dev_read_addr() that calls
dev_read_addr_index() too. Such duplication can be avoided by using
map_physmem() directly.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

test: dm: Add a case to test ofnode_phy_is_fixed_link()

This adds a test case to test the new ofnode_phy_is_fixed_link() API.
Both the new and old DT bindings are covered.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

sandbox: Add a DSA sandbox driver and unit test

The DSA sandbox driver is used for unit testing the DSA class code.
It implements a simple 2 port switch plus 1 CPU port, and uses a
very simple tag to identify the ports.

The DSA sandbox device is connected via CPU port to a regular Ethernet
sandbox device, called 'dsa-test-eth, managed by the existing eth
sandbox driver.  The 'dsa-test-eth' is not intended for testing the
eth class code however, but it is used to emulate traffic through the
'lan0' and 'lan1' front pannel switch ports.  To achieve this the dsa
sandbox driver registers a tx handler for the 'dsa-test-eth' device.
The switch ports, labeled as 'lan0' and 'lan1', are also registered
as eth devices by the dsa class code this time.  So pinging through
these switch ports is as easy as:

=> setenv ethact lan0
=> ping 1.2.3.5

Unit tests for the dsa class code were also added.  The 'dsa_probe'
test exercises most API functions from dsa.h.  The 'dsa' unit test
simply exercises ARP/ICMP traffic through the two switch ports,
including tag injection and extraction, with the help of the dsa
sandbox driver.

I took care to minimize the impact on the existing eth unit tests,
though some adjustments needed to be made with the addition of
extra eth interfaces used by the dsa unit tests. The additional eth
interfaces also require MAC addresses, these have been added to the
sandbox default environment.

Signed-off-by: Alex Marginean <alexandru.marginean@nxp.com>
Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Message-Id: <20210216224804.3355044-5-olteanv@gmail.com>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

net: tsec: Use dm_eth_phy_connect() directly for the DM case

Now that the fixed phy driver has been fully adapted to OF APIs,
and dm_eth_phy_connect() already can handle the fixed phy, call
dm_eth_phy_connect() directly in the DM tsec driver.

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Message-Id: <20210216224804.3355044-4-olteanv@gmail.com>
[bmeng: split from "net: mdio: teach dm_eth_phy_connect to connect to fixed PHY"]
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

net: phy: fixed: Support the old DT binding

Update fixedphy_probe() to support the old DT binding.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

net: phy: fixed: Add the missing ending newline

The printf statement doesn't end with a newline. Add it.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

net: phy: fixed: Make driver ops static

The PHY driver ops should be made static.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

net: phy: Simplify the logic of phy_connect_fixed()

Simplify the logic of phy_connect_fixed() by using the new API
ofnode_phy_is_fixed_link(), which brings additional bonus of
supporting the old DT bindings.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

net: phy: xilinx: Drop #ifdef CONFIG_DM_ETH around phy_connect_gmii2rgmii()

At present phy_connect_gmii2rgmii() is implemented using a DM API
dev_of_offset() hence it cannot support a non-DM configuration.
Remove the non-DM version prototype of phy_connect_gmii2rgmii()
and make the driver depend on CONFIG_DM_ETH.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

net: phy: xilinx: Be compatible with live OF tree

Following the same updates that were done to the fixed phy driver,
use ofnode_ APIs instead of fdt_ APIs so that the Xilinx PHY driver
can support live DT.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

net: phy: fixed: Drop #ifdef CONFIG_DM_ETH around phy_connect_fixed

In drivers/net/phy/Kconfig, CONFIG_PHY_FIXED already depends on
CONFIG_DM_ETH, so the function prototype definition when
CONFIG_DM_ETH=n does nothing, so it can be dropped. It is also
never reachable, since the whole function is already under #ifdef
CONFIG_PHY_FIXED (which again, as I said, depends on CONFIG_DM_ETH=y).

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Message-Id: <20210216224804.3355044-3-olteanv@gmail.com>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

net: phy: fixed: Be compatible with live OF tree

On systems that use CONFIG_OF_LIVE, the "ofnode" type is defined
as const struct device_node *np, while on the flat DT systems it
is defined as a long of_offset into gd->fdt_blob.

It is desirable that the fixed PHY driver uses the higher-level
ofnode abstraction instead of parsing gd->fdt_blob directly,
because that enables it to work on live OF systems.

The fixed PHY driver has used a nasty hack since its introduction in
commit db40c1aa1c10 ("drivers/net/phy: add fixed-phy /
fixed-link support"),
which is to pass the long gd->fdt_blob offset inside int phydev->addr
(a value that normally holds the MDIO bus address at which the PHY
responds). Even ignoring the fact that the types were already
mismatched leading to a potential truncation (flat OF offset was
supposed to be a long and not an int), we really cannot extend this
hack any longer, because there's no way an int will hold the other
representation of ofnode, the struct device_node *np.

So we unfortunately need to do the right thing, which is to use the
framework introduced by Grygorii Strashko in
commit eef0b8a930d1 ("net: phy: add ofnode node to struct phy_device").
This will populate phydev->node for the fixed PHY.

Note that phydev->node will not be valid in the probe function, since
that is called synchronously from phy_device_create and we really have
no way of passing the ofnode directly through the phy_device_create API.
So we do what other drivers do too: we move the OF parsing logic from
the .probe to the .config method of the PHY driver. The new function
will be called at phy_config() time.

I do believe I've converted all the possible call paths for creating
a PHY with PHY_FIXED_ID, so there is really no reason to maintain
compatibility with the old logic of retrieving a flat OF tree offset
from phydev->addr. We just pass 0 to phydev->addr now.

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Message-Id: <20210216224804.3355044-2-olteanv@gmail.com>
[bmeng: keep fixedphy_probe(); update mdio-uclass.c to handle fixed phy]
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

dm: mdio: Use ofnode_phy_is_fixed_link() API

Switch to use the ofnode_phy_is_fixed_link() API which can support
both the new and old DT bindings.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

of: extra: Introduce ofnode_phy_is_fixed_link() API

Introduce a helper API ofnode_phy_is_fixed_link() to detect whether
the ethernet controller connects to a fixed-link pseudo-PHY device.

Note there are two ways to describe a fixed PHY attached to an
Ethernet device:

- the new DT binding, where 'fixed-link' is a sub-node of the
  Ethernet device
- the old DT binding, where 'fixed-link' is a property with 5
  cells encoding various information about the fixed PHY

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

dt-bindings: net: Add the old DT bindings for "fixed-link"

Per the upstream Linux kernel doc:

  Documentation/devicetree/bindings/net/ethernet-controller.yaml

There are two ways to describe a fixed PHY attached to an Ethernet
device. This updates our dt-bindings doc to add the old DT bindings.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

watchdog: Add booke watchdog driver

Add a driver for the PowerPC Book E watchdog driver that is present on a
number of Freescale/NXP SoCs.

Signed-off-by: Chris Packham <judge.packham@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

board/km: add support for seli8 design based on nxp ls102x

The SELI8 design is a new tdm service unit card for Hitachi-Powergrids
XMC and FOX product lines.

It is based on NXP LS1021 SoC and it provides following interfaces:
 - IFC interface for NOR, NAND and external FPGA's
 - 1 x RGMII ETH for debug purposes
 - 2 x SGMII ETH for management communication via back-plane
 - 1 x uQE HDLC for management communication via back-plane
 - 1 x I2C for peripheral devices
 - 1 x SPI for peripheral devices
 - 1 x UART for debug logging

It is foreseen that the design will be later re-used for another XMC and
FOX service cards with similar SoC requirements.

Signed-off-by: Rainer Boschung <rainer.boschung@hitachi-powergrids.com>
Signed-off-by: Matteo Ghidoni <matteo.ghidoni@hitachi-powergrids.com>
Signed-off-by: Aleksandar Gerasimovski <aleksandar.gerasimovski@hitachi-powergrids.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

arm: dts: ls1028a: define QDS networking protocol combinations

Includes DT definition for the following serdes protocols using various
PHY cards: 85xx, 13xx, 65xx, 9999, 7777.

Note that the default device tree for QDS now uses 85xx.
Enabling any of the others requires patching the fsl-ls1028a-qds.dtsi
file (the includes at the bottom of the file).

The phy-handle is specified as a path rather than a label because it is
possible to use the #include multiple times (meaning that more than one
PHY riser card of one type is inserted), and therefore, there would be
duplicate labels with the same name.

LBRW means that the board needs lane B rework before using this dtsi.

Signed-off-by: Alex Marginean <alexandru.marginean@nxp.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

pci: add Amlogic Meson Designware PCIe controller

Add support for the DW PCIe controller found in the Amlogic Meson AXG and
G12 (G12A, G12B, SM1) SoCs.
This uses the common DW PCIe helpers introducted previously.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>

pci: pcie_dw_rockchip: migrate to common Designware PCIe functions

Migrate the dw_rockchip driver to use the common DW PCIe helpers.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>

pci: pcie_dw_ti: migrate to common Designware PCIe functions

Migrate the dw_ti driver to use the common DW PCIe helpers.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>

pci: add common Designware PCIe functions

With the introduction of pcie_dw_rockchip, and need to support the DW PCIe in the
Amlogic AXG & G12 SoCs, most of the DW PCIe helpers would be duplicated.

This introduce a "common" DW PCIe helpers file with common code merged from the
dw_ti and dw_rockchip drivers and adapted to fit with the upcoming dw_meson.

The following changes will switch the dw_ti and dw_rockchip to use these helpers.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Tested-by: Green Wan <green.wan@sifive.com>
[bmeng: remove the blank line at EOF of drivers/pci/pcie_dw_common.c]
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

x86: mtrr: Fix function descriptions

Fix copy/paste errors in the descriptions of mtrr_close () and mtrr_set().

Signed-off-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

dt-bindings: fsp: Fix Apollo Lake FSP-S devicetree bindings

An entry is missing in the FSP-S devicetree bindings, and as a result
the description for the next few following entries is off by one line.

Signed-off-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

lib/rsa: Use EVP_PKEY instead of RSA

Most modern OpenSSL engines have methods overridden at the EVP level rather
than at RSA level, to make these engines work properly with mkimage, the RSA
signing code needs to switch to using EVP_* APIs as much as possible.

Signed-off-by: Donald Chan <hoiho@lab126.com>
[trini: Rebase on top of keyfile changes]
Signed-off-by: Tom Rini <trini@konsulko.com>

image-fit: Accept OP-TEE images when booting a FIT

OP-TEE images are normally packaged with
type = "tee;
os = "tee";

However, fit_image_load() thinks that is somehow invalid. However if
they were declared as type = "kernel", os = "linux", fit_image_load()
would happily accept them and allow the boot to continue. There is no
technical limitation to excluding "tee".

Allowing "tee" images is useful in a boot flow where OP-TEE is
executed before linux.

In fact, I think it's unintuitive for a "load"ing function to also do
parsing and contain a bunch ad-hoc heuristics that only its caller
might know. But I don't make the rules, I just write fixes. In more
polite terms: refactoring the fit_image API is beyond the scope of
this change.

Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

image-fit: Accept IH_TYPE_FIRMWARE in fit_image_load() as valid

Consider the following FIT:

images {
whipple {};
};
configurations {
conf-1 {
firmware = "whipple";
};
};

Getting the 'firmware' image with fit_image_load() is not possible, as
it doesn't understand 'firmware =' properties. Although one could pass
IH_TYPE_FIRMWARE for 'image_type', this needs to be converted to a
"firmware" string for FDT lookup -- exactly what this change does.

Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

spl: LOAD_FIT_FULL: Support 'kernel' and 'firmware' properties

The 'firmware' property of a config node takes precedence over the
'kernel' property. 'standalone' is deprecated. However, give users a
couple of releases where 'standalone' still works, but warns loudly.

Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>

spl: LOAD_FIT_FULL: Relocate FDT for u-boot payloads

U-Boot expects the FDT to be located right after the _end
linker symbol (see fdtdec.c: board_fdt_blob_setup())

The "basic" LOAD_FIT path is aware of this limitation, and relocates
the FDT at the expected location. Guessing the expected location
probably only works reliably on 32-bit arm, and it feels like a hack.
One proposal would be to pass the FDT address to u-boot
(e.g. using 'r2' on arm platforms).

The variable is named "fdt_hack" to remind future contributors that,
"hey! we should fix the underlying problem". However, that is beyond
the scope of this patch.

Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>

spl: LOAD_FIT_FULL: Do not hard-code os to IH_OS_U_BOOT

The information on the OS should be contained in the FIT, as the
self-explanatory "os" property of a node under /images. Hard-coding
this to U_BOOT might send us down the wrong path later in the boot
process.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>

spl: LOAD_FIT_FULL: Fix selection of the "fdt" node

The correct FDT to use is described by the "fdt" property of the
configuration node. When the fit_unamep argument to fit_image_load()
is "fdt", we get the "/images/fdt" node. This is incorrect, as it
ignores the "fdt" property of the config node, and in most cases,
the "/images/fdt" node doesn't exist.

Use NULL for the 'fit_unamep' argument. With NULL, fit_image_load()
uses the IH_TYPE_FLATDT value to read the config property "fdt",
which points to the correct FDT node(s).

fit_image_load() should probably be split into a function that reads
an image by name, and one that reads an image by config reference. I
don't make those decisions, I just point out the craziness.

Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

common: fit: Add weak board_fit_config_name_match

Several architectures had a default board_fit_config_name_match already;
this provides a generic weak version. We default to rejecting all configs.
This will use the FIT's default config, instead of the first config. This
may result in boot failures if there are multiple configurations and the
first config is *not* the default.

Signed-off-by: Sean Anderson <sean.anderson@seco.com>

doc: FIT image: Update FPGA example to make use of "loadables"

The new correct way to load an FPGA image is to declare it in the list
of "loadables". multi-with-fpga.its used the now deprecated "fpga"
property. Since this example most likely intended to use u-boot's
generic FPGA loading code, compatible = "u-boot,fpga-legacy" is also
appropriate here.

Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Kconfig: Document the limitations of the simple SPL_LOAD_FIT path

The "simple" SPL_LOAD_FIT path is the most compliant with the format
documented in doc/uImage.FIT/source_file_format.txt. The other two
paths to load a FIT are SPL_LOAD_FIT_FULL and the "bootm" command.

Since the Kconfig menu is the most likely place for a new user to see
these options, it seems like the most logical candidate to document
the limitations. This documents the _known_ issues, and is not
intended to be a complete list of all follies.

Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

spl: fit: Support loading FPGA images from list of "loadables"

Commit 4afc4f37c70e ("doc: FIT image: Clarify format and simplify
syntax") and delegated FPGA images to be added via the list of
"loadables" in lieu of the "fpga" property. Now actually implement
this in code.

Note that the "compatible" property is ignored for the time being, as
implementing "compatible" loading is beyond the scope of this change.
However, "u-boot,fpga-legacy" is accepted without warning.

Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>

spl: fit: Warn if FIT contains "fpga" property in config node

Commit 4afc4f37c70e ("doc: FIT image: Clarify format and simplify
syntax") requires that FPGA images be referenced through the
"loadables" in the config node. This means that "fpga" properties in
config nodes are deprecated.

Given that there are likely FIT images which use "fpga", let's not
break those right away. Print a warning message that such use is
deprecated, and give users a couple of releases to update their

Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>

spl: fit: Move FPGA loading code to separate functions

The FPGA loading code in spl_simple_fit_read() can easily be separated
from the rest of the logic. It is split into two functions instead of
one because spl_fit_upload_fpga() is used in a subsequent patch.

Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

doc: FIT image: Introduce "u-boot, fpga-legacy" property

Commit 4afc4f37c70e ("doc: FIT image: Clarify format and simplify
syntax") introduced a "compatible" property for loadable images.
It did not define its contents. Use "u-boot,fpga-legacy" compatible
string to specify that fpga_load() should be used to load the image.

Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>

spl: fit: Don't overwrite previous loadable if "load" is missing

spl_load_fit_image() will try to load an image at the address given
in the "load" property. Absent such property, it uses

image_info->load_addr

Correct use of this is demonstrated in spl_fit_append_fdt(), which
resets the 'load_addr' before each spl_load_fit_image() call.

On the other hand loading "loadables" loop in spl_load_simple_fit()
completely ignores this. It re-uses the same structure, but doesn't
reset load_addr. If loadable [i] does not have a "load" property, its
load address defaults to load_addr, which still contains the address
of loadable [i - 1].

A simple solution is to treat NULL as an invalid load address. The
caller can set load_addr = 0 to request an abort if the "load"
property is absent.

Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

test/py: ecdsa: Use mkimage keyfile instead of keydir argument

Originally, the ECDSA code path used 'keydir' as the key filename.
mkimage has since been updated to include a new 'keyfile' argument.
Use the new argument for passing in the key.

Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

lib/ecdsa: Use the 'keydir' argument from mkimage if appropriate

Keys can be derived from keydir, and the "key-name-hint" property of
the FIT. They can also be specified ad-literam via 'keyfile'. Update
the ECDSA signing path to use the appropriate one.

Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

lib/rsa: Use the 'keyfile' argument from mkimage

Keys can be derived from keydir, and the "key-name-hint" property of
the FIT. They can also be specified ad-literam via 'keyfile'. Update
the RSA signing path to use the appropriate one.

Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

mkimage: Add a 'keyfile' argument for image signing

It's not always desirable to use 'keydir' and some ad-hoc heuristics
to get the filename of the signing key. More often, just passing the
filename is the simpler, easier, and logical thing to do.

Since mkimage doesn't use long options, we're slowly running out of
letters. I've chosen '-G' because it was available.

Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

doc: signature.txt: Document the keydir and keyfile arguments

After lots of debating, this documents how we'd like mkimage to treat
'keydir' and 'keyfile' arguments. The rest is in the docs.

Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

test/py: ecdsa: Add test for mkimage ECDSA signing

Add a test to make sure that the ECDSA signatures generated by
mkimage can be verified successfully. pyCryptodomex was chosen as the
crypto library because it integrates much better with python code.
Using openssl would have been unnecessarily painful.

Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

test/py: Add pycryptodomex to list of required pakages

We wish to use pycryptodomex to verify code paths involving ECDSA
signatures. Add it to requirements.txt so that they get picked up
automatically .gitlab and .azure tasks

Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

doc: signature.txt: Document devicetree format for ECDSA keys

Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

lib: Add support for ECDSA image signing

mkimage supports rsa2048, and rsa4096 signatures. With newer silicon
now supporting hardware-accelerated ECDSA, it makes sense to expand
signing support to elliptic curves.

Implement host-side ECDSA signing and verification with libcrypto.
Device-side implementation of signature verification is beyond the
scope of this patch.

Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>