Prepare v2022.10-rc5

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

configs: Resync with savedefconfig

Rsync all defconfig files using moveconfig.py

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

imx8m*_venice_defconfig: fix default bootcmd

commit 970bf8603b87 ("Convert CONFIG_USE_BOOTCOMMAND et al to Kconfig")
had an unintended side effect of resulting in a bootcmd env var change
for boards like venice that did not have CONFIG_USE_BOOTCOMMAND defined
and relied on it being defaulted in include/config_distro_bootcmd.h.
Following that patch it instead got defaulted in tools/env/fw_env_private.h

Fix this by enabling CONFIG_USE_BOOTCOMMAND for venice.

Fixes: commit 970bf8603b87 ("Convert CONFIG_USE_BOOTCOMMAND et al to Kconfig")
Signed-off-by: Tim Harvey <tharvey@gateworks.com>

Merge tag 'u-boot-imx-20220919' of https://gitlab.denx.de/u-boot/custodians/u-boot-imx

u-boot-imx-20220919
-------------------

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

- Fix imx8mn-beacon-kit-u-boot
- Merged Purism
- imxrt1170 (already merged in u-boot-imx)
- Fixes in crypto FSL
- Toradex : fixes Verdin
- Serial Driver: fixes when not used as console
- DH Boards : fixes + USB
- Fix CONFIG_SYS_MALLOC_F_LEN (Kconfig)
- Add imx6ulz_smm_m2

powerpc: mpc85xx: Fix incorrect application of patch

I messed up application of patch 5a428e751044 ("mmc: fsl_esdhc_spl: Add
support for builds without CONFIG_SYS_MMC_U_BOOT_OFFS"). I took it from
a work-in-progress branch where I changed usage of
  CONFIG_SDCARD to CONFIG_SD_BOOT
and refactored
  SYS_MPC85XX_NO_RESETVEC
mess.

But these changes aren't in master yet. Fix the wrong usage of these
macros.

Fixes: 5a428e751044 ("mmc: fsl_esdhc_spl: Add support for builds without
CONFIG_SYS_MMC_U_BOOT_OFFS")
Signed-off-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Pali Rohár <pali@kernel.org>

bsh: imx6ulz_smm_m2: Add imx6ulz BSH SMM M2 boards

Introduce BSH SystemMaster (SMM) M2 board family, which consists of:
imx6ulz SMM M2 and imx6ulz SMM M2 PRO boards.

Add support for imx6ulz BSH SMM M2 board:

- 128 MiB DDR3 RAM
- 256MiB Nand
- USBOTG1 peripheral - fastboot.

Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
Reviewed-by: Fabio Estevam <festevam@denx.de>

ARM: imx: Update Data Modul i.MX8M Mini eDM SBC DRAM timing

Adjust the DRAM timing settings for this board per ones provided
by hardware department. The change is applied to the LPDDR4 MR11
register CA ODT configuration, from RZQ/6 to RZQ/3, which fixes
stability issues on subset of boards. The DDR PHY PIE block has
been updated accordingly.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Stefano Babic <sbabic@denx.de>
Reviewed-by: Fabio Estevam <festevam@denx.de>

ARM: imx: Enable SPL GPIO hog on i.MX8M Plus DHCOM

Enable GPIO hog support in SPL to match the GPIO hog support in U-Boot proper.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <festevam@denx.de>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: uboot-imx <uboot-imx@nxp.com>
Reviewed-by: Fabio Estevam <festevam@denx.de>

verdin-imx8mm: various config additions and improvements

- integrate bootcount using SNVS_LP general purpose register LPGPR0
- enable link-time optimisation
- explicitly set a boot delay of one second
- enable CRC32 and MD5
- enable command for low-level access to data in a partition
- enable time commands
- enable PMIC commands
- improve ETHPRIME configuration
- enable eMMC HS400 functionality
- enable fixed PHY and MDIO driver model
- remove stale PFUZE100 PMIC driver
- enable thermal management unit driver
- enable more USB host functionality
- enable hexdump

Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>

Kconfig: enlarge CONFIG_SYS_MALLOC_F_LEN

"alloc space exhausted" happens in very early stage, which could be seen
with DEBUG_UART options enabled and leeds to an non-functional board.

kontron_pitx_imx8m:
CONFIG_DEBUG_UART_BASE=0x30880000   # for serial3
CONFIG_DEBUG_UART_CLOCK=24000000

imx8mqevk:
CONFIG_DEBUG_UART_BASE=0x30860000      # for uart1
CONFIG_DEBUG_UART_CLOCK=24000000

It is because CONFIG_SYS_MALLOC_F_LEN is too small and still leave
CONFIG_SPL_SYS_MALLOC_F_LEN as 0x2000.

Reported-by: Heiko Thiery <heiko.thiery@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Heiko Thiery <heiko.thiery@gmail.com>
Tested-by: Heiko Thiery <heiko.thiery@gmail.com>
Reviewed-by: Fabio Estevam <festevam@denx.de>

serial: mxc: have putc use the TXFIFO

only waiting for TXEMPTY leads to corrupted messages going over the
wire - which is fixed by making use of the FIFO

this change is following the linux kernel uart driver
(drivers/tty/serial/imx.c), which also checks UTS_TXFULL
instead of UTS_TXEMPTY

Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Fabio Estevam <festevam@denx.de>

serial: mxc: enable the RX pipeline

on imx8(mm) the RXDMUXSEL needs to be set for data going over the wire
(as observable on a connected 'scope) to actually make it into the
RXFIFO

the reference manual is not overly clear about this, and only
mentiones that "UCR3_RXDMUXSEL should always be set." - and since the
CR3 register reverts to its reset values after setting the baudrate,
setting this bit is done during '_mxc_serial_setbgr'

Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Fabio Estevam <festevam@denx.de>

MAINTAINERS: imx: Add an entry for the serial driver

Currently, when running ./scripts/get_maintainer.pl on serial_mxc.c
no i.MX maintainer is returned.

Fix it by adding an entry for this driver.

Reported-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Fabio Estevam <festevam@denx.de>
Acked-by: Peng Fan <peng.fan@nxp.com>

board: purism: add the Purism Librem5 phone

Initial commit of Librem5 u-boot and SPL

Signed-off-by: Angus Ainslie <angus@akkea.ca>
Co-developed-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
Signed-off-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
Reviewed-by: Fabio Estevam <festevam@denx.de>

verdin-imx8mp: do not save environment when it's nowhere

This code part is broken, remove it.

Signed-off-by: Andrejs Cainikovs <andrejs.cainikovs@toradex.com>
Signed-off-by: Denys Drozdov <denys.drozdov@toradex.com>

verdin-imx8mm: do not save environment when it's nowhere

This code part is broken, remove it.

Signed-off-by: Andrejs Cainikovs <andrejs.cainikovs@toradex.com>
Signed-off-by: Denys Drozdov <denys.drozdov@toradex.com>

verdin-imx8mm: improve and extend boot devices

- Annotate boot devices available in spl_board_boot_device().
- Drop SD3_BOOT/MMC3_BOOT not available for boot on Verdin iMX8M Mini.

Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>

verdin-imx8mm: prepare for optional job ring driver model

Prepare for optional job ring driver model. Sec may be initialized based
on the job ring information processed from the device tree.

Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>

verdin-imx8mm: verdin-imx8mp: update env memory layout

Update the distro config env memory layout for the Verdin iMX8M Mini and
Verdin iMX8M Plus:

- loadaddr=0x48280000 allows for 128.5MB area for uncompressing (ie FIT
  images, kernel_comp_addr_r, kernel_comp_size)
- fdt_addr_r = loadaddr + 127.5MB : allows for 127.5MB kernel
- scriptaddr = fdt_addr_r + 512KB : allows for 512KB fdt
- ramdisk_addr_r = scriptaddr + 512KB : allows for 512KB script

Memory layout taken from commit fd5c7173ade4
("imx8m{m,n}_venice: update env memory layout") but moved loadaddr by an
additional 0.5MB to avoid "Moving Image from 0x48200000 to 0x48280000"
during booti plus actually defining kernel_comp_size to make booti work.

Note that for our regular BSP Layers and Reference Images for Yocto
Project an updated distro boot script is required (see
meta-toradex-bsp-common/recipes-bsp/u-boot/u-boot-distro-boot).

Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>

ARM: imx: Update DDR frequency on i.MX8M Plus DHCOM

Commit 99c7cc58e12 ("ddr: imx: Add i.MX9 DDR controller driver")
contains an inobvious side-effect which renders all systems using
DRAM controller at 3732 MT/s unbootable. The change is located in
ddrphy_init_set_dfi_clk(), where the switch case statement entry
3732 changed to entry 3733, so any board with DDR calibration data
for 3732 MT/s operations needs to be updated to 3733 MT/s to match
the change.

Since there is currently only one such board, update the board instead
of handling both 3732 and 3733 options in the driver. It is likely the
NXP MX8MP RPA update will follow and use the later value too.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <festevam@denx.de>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Ye Li <ye.li@nxp.com>
Cc: uboot-imx <uboot-imx@nxp.com>
Reviewed-by: Fabio Estevam <festevam@denx.de>

imx8m: ddrphy_utils: Remove unused file

The ddrphy_utils.c is now deduplicated in drivers/ddr/imx/phy/ddrphy_utils.c ,
this drivers/ddr/imx/imx8m/ddrphy_utils.c is a remnant from when the
deduplication was implemented and was not removed. Remove it as it is
unused.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <festevam@denx.de>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Ye Li <ye.li@nxp.com>
Cc: uboot-imx <uboot-imx@nxp.com>
Reviewed-by: Fabio Estevam <festevam@denx.de>
Reviewed-by: Peng Fan <peng.fan@nxp.com>

ARM: imx: dh-imx6: Increase SF erase area for u-boot update

Erase the entire U-Boot area during U-Boot update instead of just
a subset of it. This way, in case u-boot-with-spl.imx grows, the
sf write won't write over non-erased part of the SPI NOR.

Signed-off-by: Marek Vasut <marex@denx.de>

ARM: dts: imx: Fix I2C5 GPIO assignment on i.MX8M Plus DHCOM

Fix copy-paste error of the I2C5 bus recovery GPIO assignment,
the I2C5 GPIOs are on gpio3 instead of gpio5.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <festevam@denx.de>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: uboot-imx <uboot-imx@nxp.com>

ARM: dts: imx: Adjust ECSPI1 pinmux on i.MX8M Plus DHCOM

The ECSPI1 is on I2C1/I2C2 pins of the SoC, update the pinmux accordingly.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <festevam@denx.de>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: uboot-imx <uboot-imx@nxp.com>

ARM: dts: imx: Rename imx8mp-dhcom{-pdk2,}-boot.dtsi

Rename imx8mp-dhcom-pdk2-u-boot.dtsi to imx8mp-dhcom-u-boot.dtsi, since
this file is shared by PDK2, PicoITX and DRC02. No functional change.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <festevam@denx.de>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: uboot-imx <uboot-imx@nxp.com>

ARM: dts: imx: Add SoM compatible to i.MX8M Plus DHCOM PDK2

Add SoM compatible string into i.MX8MP DHCOM PDK2 compatible strings.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <festevam@denx.de>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: uboot-imx <uboot-imx@nxp.com>

ARM: dts: imx: Drop Atheros PHY header from i.MX8M Plus DHCOM PDK2

This PHY is not used on PDK2, the header was added due to copy-paste
error, drop it.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <festevam@denx.de>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: uboot-imx <uboot-imx@nxp.com>

ARM: dts: imx: Add HW variant details to i.MX8M Plus DHCOM PDK2

Add information about which exact SoM variant is used on which PDK2 variant.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <festevam@denx.de>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: uboot-imx <uboot-imx@nxp.com>

ARM: imx: Enable USB ethernet on i.MX8M Plus DHCOM

Enable both USB CDC ethernet and USB host ethernet on i.MX8M Plus DHCOM.
This is useful for bringing up systems without ethernet plug, but with
either USB host or gadget plug.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <festevam@denx.de>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: uboot-imx <uboot-imx@nxp.com>

board: gateworks: venice: add fixup for GW73xx-C+

The GW73xx-C revision and onward replaced the 5-port PCIe switch with a
4-port (dropping PCIe to one of the miniPCIe sockets) due to part
availability. This moved the PCI bus of the GbE eth1 device. Use a fixup
to adjust the dt accordingly so that local-mac-address assigned from dt
works on new revision boards.

While we are at it, rename 'blob' to 'fdt' for clarity.

Signed-off-by: Tim Harvey <tharvey@gateworks.com>

arm: dts: imx8mn-beacon-kit-u-boot: Fix broken booting

When the imx8mm.dtsi file was pulled in from Linux, the UARTs
were moved into an spba sub-node which wasn't being included
in the SPL device tree.  This meant the references to the UART
weren't being handled properly and when booting the system would
constantly reboot.  Fix this by adding the spba node to the spl
device tree to restore normal booting.

Fixes: 4e5114daf9eb ("imx8mn: synchronise device tree with linux")
Signed-off-by: Adam Ford <aford173@gmail.com>

crypto/fsl: fsl_hash: Fix crash in flush dcache

wrong end address passed to flush_dcache_range.
modified the flush_dache logic for scatter list elements.

Fixes: 1919f58a8f (crypto/fsl: fsl_hash: Fix dcache issue in caam_hash_finish)
Signed-off-by: Gaurav Jain <gaurav.jain@nxp.com>

imx: romapi: fix spurious ampersand in address print

Fix spurious ampersand in address print e.g.

Find img info 0x&480331a0, size 855

Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com>"

doc: imx: habv4: Add Secure Boot guide for i.MX8M SPL targets

Add HABv4 documentation extension for SPL targets covering the
following topics:

- How to sign an securely boot an flash.bin container image.
- How to extend the root of trust for additional boot images.
- Add SPL and fitImage CSF examples.
- Add signature generation script example.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Breno Lima <breno.lima@nxp.com>
Cc: Fabio Estevam <festevam@denx.de>
Cc: Heiko Schocher <hs@denx.de>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Utkarsh Gupta <utkarsh.gupta@nxp.com>
Cc: Ye Li <ye.li@nxp.com>

ARM: imxrt1170_defconfig: Add i.MXRT1170 defconfig

Add a base defconfig for the i.MXRT1170

Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com>

RAM: Add changes for i.MXRT11xx series

The i.MXRT11 series has different offsets for IOCR_MUX, it also can
address 64MiB of SDRAM so add a macro for that.

Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com>

clk: imx: Add initial support for i.MXRT1170 clock driver

Add clock driver support for i.MXRT1170.

Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com>

clk: imx: Add i.MXRT11xx pllv3 variant

The i.MXRT11 series has two new pll types but are variants of existing.
This patch adds the ability to read one of the pll types' frequency
as it can't be changed unlike the generic pll it also has the
division factors swapped.

Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com>

dt-bindings: imx: Add clock binding for i.MXRT1170

Add the clock binding doc for i.MXRT1170.

Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com>

ARM: dts: imx: add i.MXRT1170-EVK support

The NXP i.MXRT1170 Evaluation Kit (EVK) provides a platform for rapid
evaluation of the i.MXRT, which features NXP's implementation of the Arm
Cortex-M7 and Cortex-M4 core.

The EVK provides 64 MB SDRAM, Micro SD card socket,
USB 2.0 OTG.

This patch aims to support the preliminary booting up features
as follows:
GPIO
LPUART
SD/MMC
SDRAM

Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com>

ARM: dts: imxrt11170-pinfunc: Add pinctrl binding header

Add binding header for i.MXRT1170 pinctrl device tree.

Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com>

imx: imxrt1170-evk: Add support for the NXP i.MXRT1170-EVK

This commit adds board support for i.MXRT1170-EVK from NXP. This board
is an evaluation kit provided by NXP for i.MXRT117x processor family.

Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com>

Merge branch 'mpc85xx-for-v2022.10-rc5' of https://source.denx.de/u-boot/custodians/u-boot-mpc85xx

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

- mvebu: turris_omnia: Fix setting switch CONFIG pins on new board
  design (Marek)
- orion-timer: Use timer_conv_64() to fix timer wrap around (Stefan)

timer: orion-timer: Use timer_conv_64() to fix timer wrap around

While testing on some Kirkwood platforms it was noticed that the timer
did not function correctly all the time. The driver did not correctly
handle 32bit timer value wrap arounds. Using the timer_conv_64()
conversion function fixes this issue.

Fixes: e9e73d78a8fb ("timer: add orion-timer support")
Suggested-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier-oss@weidmueller.com>
Signed-off-by: Stefan Roese <sr@denx.de>
Tested-by: Tony Dinh <mibodhi@gmail.com>

arm: mvebu: turris_omnia: Fix setting switch CONFIG pins on new board design

It seems that waiting only 10 ms after releasing LAN switch from reset
is not enough for the strapping pins to latch the requested values.
P6_MODE[0] is latched to 0 instead of 1.

Increasing the delay to 50 ms fixes this issue.

Signed-off-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

mmc: fsl_esdhc_spl: Add support for builds without CONFIG_SYS_MMC_U_BOOT_OFFS

When fixed offset via CONFIG_SYS_MMC_U_BOOT_OFFS is not specified then
expects that U-Boot proper is placed immediately after SPL without any
additional padding.

This allows to generate smaller SPL+U-Boot final binary as it is not
required to specify fixed offset to U-Boot proper at SPL compile time.

In this case offset to U-Boot proper is calculated at SPL compile time in
linker script.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Marek Behún <kabel@kernel.org>

powerpc: mpc85xx: Fix loading U-Boot proper from SD card in SPL

Change 8-byte alignment of SPL binary to just 4-byte alignment as objcopy
trims trailing zero bytes when converting ELF file to RAW binary.

This is same fix for SPL linker script as was done fix for U-Boot linker
script in commit e8c0e0064c8a ("powerpc: mpc85xx: Fix CONFIG_OF_SEPARATE
support").

It is required for the patch "mmc: fsl_esdhc_spl: Add support for builds
without CONFIG_SYS_MMC_U_BOOT_OFFS" which triggered this issue in SPL.

Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <kabel@kernel.org>

mmc: fsl_esdhc_spl: Add support for loading proper U-Boot from unaligned location

This allows to concatenate SPL and proper U-Boot without extra alignment.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Marek Behún <kabel@kernel.org>

powerpc: mpc85xx: Fix check for CONFIG_SDCARD

Commit d433c74eecdc ("Convert CONFIG_SDCARD et al to Kconfig") converted
SYS_EXTRA_OPTIONS=SDCARD or SPIFLASH to config options CONFIG_SDCARD and
CONFIG_SPIFLASH, but left one occurance unchanged.

Fix this.

Fixes: d433c74eecdc ("Convert CONFIG_SDCARD et al to Kconfig")
Signed-off-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Pali Rohár <pali@kernel.org>

Makefile: Unify condition for mpc85xx reset vector

Use 'CONFIG_MPC85XX_HAVE_RESET_VECTOR && CONFIG_OF_SEPARATE' pattern
instead of 'CONFIG_MPC85XX_HAVE_RESET_VECTOR && !CONFIG_OF_EMBED' also in
OBJCOPYFLAGS_u-boot-nodtb.bin as this pattern is used in rest of Makefile.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Marek Behún <kabel@kernel.org>

Makefile: Reduce usage of custom mpc85xx u-boot.bin target

Building of final u-boot.bin binary for mpc85xx via binman is needed only
when inserting DTB binary in the middle of the u-boot ELF binary (before
.bootpg and .resetvec ELF sections).

These requirements are met when CONFIG_MPC85XX_HAVE_RESET_VECTOR is enabled
(= generating .bootpg/.resetvec sections) and CONFIG_OF_SEPARATE is enabled
(= inserting DTB binary).

So in all other cases use standard build procedure instead of custom
mpc85xx u-boot.bin Makefile target via binman.

Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <kabel@kernel.org>

Makefile: Build final mpc85xx non-SPL image in standard file u-boot.bin

Currently Makefile produces final mpc85xx image when SPL is not used in
custom file u-boot-with-dtb.bin. It is quite confusing name as build
process produce also intermediate file standard file u-boot-dtb.bin (which
is just intermediate and not bootable). Other platforms use u-boot.bin
(UBOOT_BIN) as standard name for final bootable raw image.

So change Makefile rules and binman to produce final bootable file for
mpc85xx also into file u-boot.bin. There is just need for mpc85xx to not
define default rule for u-boot.bin then instruct binman (via DTS file) to
store final image into u-boot.bin (instead of u-boot-with-dtb.bin) and
finally rename target u-boot-with-dtb.bin to u-boot.bin.

With this change are also removed custom Makefile hacks for mpc85xx that it
produced non-standard output file. And also updated documentation.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Marek Behún <kabel@kernel.org>

Makefile: Fix dependency for u-boot-with-dtb.bin

Makefile uses binman to produce u-boot-with-dtb.bin target. As its input it
takes DTB file and u-boot binary without DTB, which is stored in file
u-boot-nodtb.bin. So fix target dependency.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Marek Behún <kabel@kernel.org>

Merge tag 'u-boot-stm32-20220915' of https://source.denx.de/u-boot/custodians/u-boot-stm

- Fixes on STM32 I2C drivers
- Activate SCMI regulator for STM32MP15 defconfig, fix the usb start command
  for scmi device tree

i2c: stm32: fix usage of rise/fall device tree properties

These two device tree properties were not being applied.

Fixes: 1fd9eb68d6 ("i2c: stm32f7: move driver data of each instance in a privdata")
Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Reviewed-by: Alain Volmat <alain.volmat@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Tested-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

i2c: stm32: do not set the STOP condition on error

Current function stm32_i2c_message_xfer is sending a STOP
whatever the result of the transaction is.  This can cause issues
such as making the bus busy since the controller itself is already
sending automatically a STOP when a NACK is generated.

Thanks to Jorge Ramirez-Ortiz for diagnosing and proposing a first
fix for this. [1]

[1] https://lore.kernel.org/u-boot/20220815145211.31342-2-jorge@foundries.io/

Reported-by: Jorge Ramirez-Ortiz, Foundries <jorge@foundries.io>
Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Tested-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

i2c: stm32: remove unused stop parameter in start & reload handling

Functions stm32_i2c_message_start and stm32_i2c_handle_reload
both get a stop boolean indicating if the transfer should end with
a STOP or not.  However no specific handling is needed in those
functions hence remove the parameter.

Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>

i2c: stm32: fix comment and remove unused AUTOEND bit

Comment within stm32_i2c_message_start is misleading, indicating
that AUTOEND bit is setted while it is actually cleared.
Moreover, the bit is actually never setted so there is no need
to clear it hence get rid of this bit clear and the bit macro
as well.

Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>

i2c: stm32f7: fix clearing the control register

Bits should be set to 0, not 1.

Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

configs: stm32mp15: activate DM_REGULATOR_SCMI

Activate the support of SCMI regulator to support the scmi_reg11,
scmi_reg18 and scmi_usb33 regulators present in the scmi device tree of
STMicroelectronics boards with stm32mp15-scmi.dtsi

Fixes: 6cccc8d396bf ("ARM: dts: stm32: add SCMI version of STM32 boards (DK1/DK2/ED1/EV1)")
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>

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

- mvebu: Armada 32bit: Cache setup fixes (Pali)
- cmd: mvebu/bubt: Misc enhancements (Pali)
- kirkwood: Add CONFIG_SUPPORT_PASSING_ATAGS (Tony)
- board: turris: Misc improvements (Pali)
- tools: kwboot: Change KWBOOT_MSG_RSP_TIMEO_AXP to 10ms (Stefan)
- tools: termios_linux.h: Fix compilation on non-glibc systems (Pali)

arm: mvebu: Fix moving internal registers

Commit 5bb2c550b11e ("arm: mvebu: Move internal registers in
arch_very_early_init() function") moved code from file cpu.c to lowlevel.c,
which moves Marvell internal registers from address INTREG_BASE_ADDR_REG to
SOC_REGS_PHY_BASE.

But the steps describing how to do it correctly were documented only in
older U-Boot versions and commit cefd764222ee ("arm: mvebu: Fix internal
register config on A38x") probably unintentionally removed important
details about MMU from code comments around.

Commit 5bb2c550b11e ("arm: mvebu: Move internal registers in
arch_very_early_init() function") implemented code movement according to
(now incomplete) comments which resulted in semi-broken code.

The result is that I-cache is currently disabled for all Armada 38x boards
and maybe there are some other (unreported / undetected) issues.

Reimplement it correctly. First flush all caches, then disable MMU and L2
cache and then move Marvell internal registers. There is no need to
explicitly disable I-cache.

After this change lzmadec command with lzma image of 0x7000000 bytes is
doing decompression just 5 seconds. Before this change it was 30 seconds.

To make lowlevel.S code more readable, extend asm/pl310.h header file to be
compatible with assembler and use macros from this file.

Fixes: 5bb2c550b11e ("arm: mvebu: Move internal registers in arch_very_early_init() function")
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: mvebu: Enable L2 cache also on Armada 38x

For some unknown reason when L2 cache is disabled on Armada 385 then loadb,
loadx and loady commands do not work with higher baudrates than 115200
(they just abort transfer) and lzmadec command with lzma image of size
0x7000000 (maybe even smaller, we tested this one) is doing decompression
for more than 2 minutes. After enabling L2 cache decompression takes only
30s and loadb, loadx and loady are stable and working fine.

git bisect identified problematic commit 3308933d2fe9 ("arm: mvebu: Avoid
reading MVEBU_REG_PCIE_DEVID register too many times"). Before this commit
above issues were not present.

But investigation showed that above issue was possible to reproduce also by
reverting that commit and forcing compiler to do inline optimization of
mvebu_soc_family() function. Which seems that the root of this issue is in
caches and position of instruction of segments. So currently it is unknown
what is or was broken, but code movement, code inlining or other compiler
optimization triggered it.

Commit 3e5ce7ceeb94 ("arm: mvebu: Enable L2 cache on Armada XP") mentioned
that enabling L2 cache on Armada XP improved performance and that Armada
38x has L2 disabled (which is default state) and if needed it has to be
enabled in separate patch. As enabling L2 cache also improve performance
on Armada 38x, enable it.

Note that Aurora cache in no outer mode is available only on Armada XP,
hence it is not touched for Armada 38x code.

Fixes: 3308933d2fe9 ("arm: mvebu: Avoid reading MVEBU_REG_PCIE_DEVID register too many times")
Reported-by: Marek Behún <kabel@kernel.org>
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: mvebu: lowlevel.S: Use CR_M from asm/system.h

Replace magic constant 1 when disabling MMU by macro CR_M from include
header file asm/system.h.

Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: mvebu: Guard non-AXP code by checking for AXP

Commit c86d53fd88df ("arm: mvebu: Don't disable cache at startup on Armada
XP at all") introduced branch for non-AXP code which was guarded by A38X
condition. Fix this issue by checking for AXP platform, not by A38X.

Fixes: c86d53fd88df ("arm: mvebu: Don't disable cache at startup on Armada XP at all")
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: mvebu: Fix function enable_caches

Commit 3308933d2fe9 ("arm: mvebu: Avoid reading MVEBU_REG_PCIE_DEVID
register too many times") broke support for caches on all Armada SoCs.

Before that commit there was code:

    if (mvebu_soc_family() != MVEBU_SOC_A375) {
        dcache_enable();
    }

And after that commit there is code:

    if (IS_ENABLED(CONFIG_ARMADA_375)) {
        dcache_enable();
    }

Comment above this code says that d-cache should be disabled on Armada 375.
But new code inverted logic and broke Armada 375 and slowed down all other
Armada SoCs (including A38x).

Fix this issue by changing logic to:

    if (!IS_ENABLED(CONFIG_ARMADA_375)) {
        dcache_enable();
    }

Which matches behavior prior that commit.

Fixes: 3308933d2fe9 ("arm: mvebu: Avoid reading MVEBU_REG_PCIE_DEVID register too many times")
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: mvebu: Mark constant data with const keyword

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: mvebu: turris_omnia: Allow to use second serial port

Turris Omnia has two serial ports. Both are already specified in device
tree file. But U-Boot by default does not allow to use more than one serial
port unless CONFIG_SERIAL_PROBE_ALL is not enabled.

After enabling CONFIG_SERIAL_PROBE_ALL, U-Boot see also second serial port
(but is inactive by default):

    => coninfo
    List of available devices:
    serial@12000 00000007 IO stdin stdout stderr
    serial@12100 00000007 IO

To allow simultaneously to use more input / output devices it is needed to
enable CONFIG_CONSOLE_MUX option.

With CONFIG_CONSOLE_MUX it is possible to call:

    => setenv stdout 'serial@12000,serial@12100'

And U-Boot output is then visible on both serial ports.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

tools: termios_linux.h: Fix compilation on non-glibc systems

TCGETS2 is defined in header file asm/ioctls.h provided by linux kernel.
On glib systems it is automatically included by some other glibc include
header file and therefore TCGETS2 is present in termios_linux.h when
linux kernel provides it.

On non-glibc systems (e.g. musl) asm/ioctls.h is not automatically included
which results in the strange error that BOTHER is supported, TCGETS2 not
defined and struct termios does not provide c_ispeed member.

    tools/kwboot.c: In function 'kwboot_tty_change_baudrate':
    tools/kwboot.c:662:6: error: 'struct termios' has no member named 'c_ospeed'
      662 |   tio.c_ospeed = tio.c_ispeed = baudrate;
          |      ^

Fix this issue by explicitly including asm/ioctls.h file which provides
TCGETS2 macro (if supported on selected architecture) to not depending on
glibc auto-include behavior and because termios_linux.h requires it.

With this change it is possible compile kwboot with musl libc.

Reported-by: Michal Vasilek <michal.vasilek@nic.cz>
Signed-off-by: Pali Rohár <pali@kernel.org>

arm: mvebu: turris_mox: Add support for distroboot $fdt_addr

$fdt_addr is mandatory for systems which provides DTB in HW (e.g. ROM) and
wishes to pass that DTB to Linux.

Turris Mox contains DTB binary in SPI NOR memory at "dtb" partition which
starts at offset 0x7f0000 and is 0x10000 bytes long.

Armada 3700 CPU does not allow mapping SPI NOR memory into physical address
space like on other architectures and therefore set $fdt_addr variable to
memory range in RAM and loads this DTB binary from SPI NOR in misc_init_r()
function.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: mvebu: turris_{omnia, mox}: Reset bootdelay env for rescue

When rescue mode was activated reset also bootdelay env variable to its
default value. This will ensure that reset button works and starts rescue
mode also in the case when user changed bootdelay env variable to -1 (which
has meaning to not start autoboot).

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

board: turris: Initialize serial# env

Store serial number from atsha cryptochip into the serial# env variable.
U-Boot automatically puts content of this variable into the root device
tree property serial-number when booting Linux kernel. Refactor turris
atsha code and from turris_atsha_otp_get_serial_number() function returns
directly string suitable for printing or storing into device tree. Because
during different boot stages is env storage read-only, it is not possible
to always store serial number into env storage. So introduce a new function
turris_atsha_otp_init_serial_number() which is called at later stage and
which ensures that serial number is correctly stored into env.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: mvebu: Espressobin: When emmc is not present disable it also in OF_LIVE

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

cmd: mvebu/bubt: Check for A38x/A37xx OTP secure bits and secure boot

For obvious reasons BootROMS rejects unsigned images when secure boot is
enabled in OTP secure bits. So check for OPT secure bits and do not allow
flashing unsigned images when secure boot is enabled. Access to OTP via
U-Boot fuse API is currently implemented only for A38x and A37xx SoCs.

Additionally Armada 3700 BootROM rejects signed trusted image when secure
boot is not enabled in OTP. So add also check for this case. On the other
hand Armada 38x BootROM acceps images with secure boot header when secure
boot is not enabled in OTP.

OTP secure bits may have burned also boot device source. Check it also and
reject flashing images to target storage which does not match OTP.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

cmd: mvebu/bubt: Check for A38x image data checksum

Currently for A38x image is checked only header checksum.
So check also for image data checksum to prevent flashing broken image.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

tools: kwboot: Change KWBOOT_MSG_RSP_TIMEO_AXP to 10ms

Testing on the theadorable Armada XP platform has shown, thaz using the
current value of 1000ms as response timeout does not result in reliable
booting via kwboot. Using 10ms seems to be much better. So let's change
this value to this 10ms instead.

Signed-off-by: Stefan Roese <sr@denx.de>
Acked-by: Pali Rohár <pali@kernel.org>

arm: kirkwood: Add CONFIG_SUPPORT_PASSING_ATAGS

Add CONFIG_SUPPORT_PASSING_ATAGS and friends to support legacy
image method of booting. Debian and OpenWrt installer use uImage
with appended DTB for these Kirkwood boards.

Signed-off-by: Tony Dinh <mibodhi@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>

Merge tag 'dm-pull-12sep22' of https://source.denx.de/u-boot/custodians/u-boot-dm

Binman VPL support (patch was lost)
Add board_rng_seed() as a temporary solution

binman: Add VPL support

Add support for U-Boot's Verifying Program Loader phase.

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

fdt_support: add optional board_rng_seed() hook

A recurring theme on LKML is the boot process deadlocking due to some
process blocking waiting for random numbers, while the kernel's
Cryptographic Random Number Generator (crng) is not initalized yet,
but that very blocking means no activity happens that would generate
the entropy necessary to finalize seeding the crng.

This is not a problem on boards that have a good hwrng (when the
kernel is configured to trust it), whether in the CPU or in a TPM or
elsewhere. However, that's far from all boards out there. Moreover,
there are consumers in the kernel that try to obtain random numbers
very early, before the kernel has had any chance to initialize any
hwrng or other peripherals.

Allow a board to provide a board_rng_seed() function, which is
responsible for providing a value to be put into the rng-seed property
under the /chosen node.

The board code is responsible for how to actually obtain those
bytes.

- One possibility is for the board to load a seed "file" from
  somewhere (it need not be a file in a filesystem of course), and
  then ensure that that the same seed file does not get used on
  subsequent boots.

  * One way to do that is to delete the file, or otherwise mark it as
    invalid, then rely on userspace to create a new one, and living
    with the possibility of not finding a seed file during some boots.

  * Another is to use the scheme used by systemd-boot and create a new
    seed file immediately, but in a way that the seed passed to the
    kernel and the new (i.e. next) seed cannot be deduced from each
    other, see the explanation at
    https://lore.kernel.org/lkml/20190929090512.GB13049@gardel-login/
    and the current code at
    https://github.com/systemd/systemd/blob/main/src/boot/efi/random-seed.c

- The board may have an hwrng from which some bytes can be read; while
  the kernel can also do that, doing it in U-Boot and providing a seed
  ensures that even very early users in the kernel get good random
  numbers.

- If the board has a sensor of some sort (temperature, humidity, GPS,
  RTC, whatever), mixing in a reading of that doesn't hurt.

- etc. etc.

These can of course be combined.

The rng-seed property is mixed into the pool used by the linux
kernel's CRNG very early during boot. Whether it then actually
contributes towards the kernel considering the CRNG initialized
depends on whether the kernel has been configured with
CONFIG_RANDOM_TRUST_BOOTLOADER (nowadays overridable via the
random.trust_bootloader command line option). But that's for the BSP
developer to ultimately decide.

So, if the board needs to have all that logic, why not also just have
it do the actual population of /chosen/rng-seed in ft_board_setup(),
which is not that many extra lines of code?

I considered that, but decided handling this logically belongs in
fdt_chosen(). Also, apart from saving the board code from the few
lines of boilerplate, doing it in ft_board_setup() is too late for at
least some use cases. For example, I want to allow the board logic to
decide

  ok, let's pass back this buffer and use that as seed, but also let's
  set random.trust_bootloader=n so no entropy is credited.

This requires the rng-seed handling to happen before bootargs
handling. For example, during the very first boot, the board might not
have a proper seed file, but the board could still return (a hash of)
some CPU serial# or whatnot, so that at least no two boards ever get
the same seed - the kernel always mixes in the value passed in
rng-seed, but if it is not "trusted", the kernel would still go
through the same motions as it would if no rng-seed was passed before
considering its CRNG initialized. I.e., by returning that
unique-to-this-board value and setting random.trust_bootloader=n, the
board would be no worse off than if board_rng_seed() returned nothing
at all.

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

Merge tag 'efi-2022-10-rc5' of https://source.denx.de/u-boot/custodians/u-boot-efi

Pull request for efi-2022-10-rc5

Documentation:

* man-page for tftpput

UEFI:

* fix driver binding protocol for block IO devices
* don't delete invalid handles
* add a unit test for the EFI Conformance Profile Table

Other:

* correct short text for tftpboot

efi_driver: don't bind internal block devices

UEFI block devices can either mirror U-Boot's internal devices or be
provided by an EFI application like iPXE.

When ConnectController() is invoked for the EFI_BLOCK_IO_PROTOCOL
interface for such an application provided device we create a virtual
U-Boot block device of type "efi_blk".

Currently we do not call ConnectController() when handles for U-Boot's
internal block devices are created. If an EFI application calls
ConnectController() for a handle relating to an internal block device,
we erroneously create an extra "efi_blk" block device.

E.g. the UEFI shell has a command 'connect -r' which calls
ConnectController() for all handles with device path protocol.

In the Supported() method of our EFI_DRIVER_BINDING_PROTOCOL return
EFI_UNSUPPORTED when dealing with an U-Boot internal device.

Reported-by: Etienne Carriere <etienne.carriere@linaro.org>
Fixes: commit 05ef48a2484b ("efi_driver: EFI block driver")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>
Tested-by: Etienne Carriere <etienne.carriere@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

lib: efi_loader: don't delete invalid handles

Change efi_delete_handle() to not free EFI handles twice.

This change tries to resolved an issue seen since U-Boot v2022.07
in which ExitBootService() attempts to release some EFI handles twice.

The issue was seen booting a EFI shell that invokes 'connect -r' and
then boots a Linux kernel. Execution of connect command makes EFI
subsystem to bind a block device for each root block devices EFI handles.
However these EFI device handles are already bound to a driver and we
can have 2 registered devices relating to the same EFI handler. On
ExitBootService(), the loop removing the devices makes these EFI handles
to be released twice which corrupts memory.

This patch prevents the memory release operation caused by the issue but
but does not resolve the underlying problem.

Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
Add log message.
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

efi_selftest: unit test for EFI Conformance Profile Table

Add a new unit test to test the integrity of the
EFI Conformance Profile Table.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

efi_selftest: export efi_st_get_config_table()

We can use efi_st_get_config_table() in multiple unit tests.
Export the function.

Export system-table and boot-services.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

doc: man-page for tftpput

Provide a man-page for the tftpput command.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

cmd: correct short text for tftpboot

The command's name is a misnomer.
The command loads a file but does not run (boot) it.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

cmd: fix tftpput command

Calling tftpput with less than 2 arguments must lead to a failure.

If tftpput is called with two arguments, these are the address and
the size of the file to be transferred.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Merge tag 'u-boot-stm32-20220907' of https://source.denx.de/u-boot/custodians/u-boot-stm

- simplify the STM32MP15x package parsing code
- remove test on CONFIG_DM_REGULATOR in stm32mp1 board
  and enable CONFIG_DM_REGULATOR for stm32f769-disco
- handle ck_usbo_48m clock provided by USBPHYC to fix the command 'usb start'
  after alignment with Linux kernel v5.19 DT (clocks = <&usbphyc>)
- Fix SYS_HZ_CLOCK value for stih410-b2260 board
- Switch STMM32MP15x DHSOM to FMC2 EBI driver
- Remove hwlocks from pinctrl in STM32MP15x to avoid issue with kernel

Merge tag 'fsl-qoriq-2022-9-7' of https://source.denx.de/u-boot/custodians/u-boot-fsl-qoriq

- Pali's patch not in my patchwork, got missed.
- Sean's patch pending for sometime, I just fix conflict when apply
  Sean's patch, so pick up.

Merge tag 'dm-pull-7sep22' of https://source.denx.de/u-boot/custodians/u-boot-dm

binman fixes for bintool support

net: fm: Add support for FIT firmware

Fman microcode is executable code (AFAICT) loaded into a
coprocessor. As such, if verified boot is enabled, it must be verified
like other executable code. However, this is not currently done.

This commit adds verified boot functionality by encapsulating the
microcode in a FIT, which can then be signed/verified as normal. By
default we allow fallback to unencapsulated firmware, but if
CONFIG_FIT_SIGNATURE is enabled, then we make it mandatory. Because
existing Layerscape do not use this config (instead enabling
CONFIG_CHAIN_OF_TRUST), this should not break any existing boards.

An example (mildly-abbreviated) its is provided below:

/ {
    #address-cells = <1>;

    images {
        firmware {
            data = /incbin/(/path/to/firmware);
            type = "firmware";
            arch = "arm64";
            compression = "none";
    signature {
                algo = "sha256,rsa2048";
                key-name-hint = "your key name";
            };
        };
    };

    configurations {
        default = "conf";
        conf {
            description = "Load FMAN microcode";
            fman = "firmware";
        };
    };
};

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>

net: Convert fit verification to use fit_get_data_*

Several ethernet drivers load firmware from FIT images. Convert them to
use the fit_get_data helpers.

Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>

cmd: fpga: Convert to use fit_get_data_node

This converts the FIT loading process of the fpga command to use
fit_get_data_node.

Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>

ARMv8/sec_firmware: Convert to use fit_get_data_conf_prop

This reduces sec_firmware_get_data to a single call to
fit_get_data_conf_prop. I think sec_firmware_check_copy_loadable could also
be converted, but it does not map as straightforwardly, so I have left it
for a future cleanup.

Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>

image: fit: Add some helpers for getting data

Several different firmware users have repetitive code to extract the
firmware data from a FIT. Add some helper functions to reduce the amount
of repetition. fit_conf_get_prop_node (eventually) calls
fdt_check_node_offset_, so we can avoid an explicit if. In general, this
version avoids printing on error because the callers are typically
library functions, and because the FIT code generally has (debug)
prints of its own. One difference in these helpers is that they use
fit_image_get_data_and_size instead of fit_image_get_data, as the former
handles external data correctly.

Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>

ARMv8/sec_firmware: Remove SEC_FIRMWARE_FIT_CNF_NAME

The config to use for FIT images can be better specified by enabling
CONFIG_MULTI_DTB_FIT and implementing board_fit_config_name_match.

Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>

board: freescale: p1_p2_rdb_pc: Calculate offsets for eSDHC boot sector

Correctly calculate offsets between SPL and proper U-Boot when new config
option CONFIG_FSL_PREPBL_ESDHC_BOOT_SECTOR for generating eSDHC boot sector
is enabled. Otherwise SPL would not be able to boot proper U-Boot.

Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>

board: freescale: p1_p2_rdb_pc: Delete watchdog max6370 node in load_default mode

CPLD in load_default mode ignores watchdog reset signal. It does not reset
board when watchdog triggers reset signal.

Detect load_default mode by GPIO7 - LOAD_DEFAULT_N and delete watchdog
max6370 node from device to prevent registering driver for non-working
watchdog.

Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>