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>

board: freescale: p1_p2_rdb_pc: Add env commands norlowerboot, norupperboot, sd2boot and defboot

All *boot env commands overrides default boot source location via i2c.
After board reset without power off, BootROM then starts booting U-Boot
from this specified location instead of the default one.

Add new env command defboot which reverts boot location to the default
value, which in most cases is configurable by HW DIP switches.

And add new env commands norlowerboot, norupperboot, sd2boot to boot from
other locations. norlowerboot would instruct BootROM to boot from lower NOR
bank, norupperboot from upper NOR bank and sd2boot from SD card with
alternative configuration.

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

ARM: dts: stm32mp15: remove hwlocks from pinctrl

Removes hwlocks properties from stm32mp151 pinctrl node. These locks
could be used for other purpose, depending on board and software
configuration hence do not enforce their use to protect pinctrl
devices.

This patch is an alignment with Linux device tree with v6.0 as the
hwsem support wasn’t yet added in pincontrol in kernel. It avoids
issues when the Linux kernel is started with the U-Boot device tree.

Cc: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Patrick Delaunay <patrick.delaunay@foss.st.com>
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

ARM: stm32: Switch DHSOM to FMC2 EBI driver

Perform long overdue conversion of ad-hoc FMC2 EBI bus initialization
to upstream FMC2 EBI driver. No functional change.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

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

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

Reset fixes for p1_p2_rdb_pc
Fix use after free issue fix in fsl_enetc.c
Fix for fsl ddr: make bank_addr_bits reflect actual bits
sl28 board update

configs: stih410-b2260: Fix SYS_HZ_CLOCK value

SYS_HZ_CLOCK was wrongly set to 1GHz whereas it's set to 750MHz
by default by bootrom.

Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Grzegorz Szymaszek <gszymaszek@short.pl>

configs: stm32: Enable CONFIG_DM_REGULATOR for stm32f769-disco

Since commit 5bc6f8c2a97e("video: stm32: remove test on CONFIG_DM_REGULATOR")
backlight was broken with the following message at boot:
stm32-display-dsi dsi@40016c00: Warning: cannot get phy dsi supply
stm32_display display-controller@40016800: panel panel enable backlight error -38

DM_REGULATOR flag must be enabled to fix this issue

Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

ARM: dts: stm32: Fix display-timings settings for stm32f746-disco

Since commit ef4ce6df3289 "video: stm32: stm32_ltdc: fix data enable polarity"
The panel display output wasn't functional anymore.
Device tree display-timings de-active property value must be updated
to 1.

Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

clk: stm32mp: handle ck_usbo_48m clock provided by USBPHYC

Handle the input clock of RCC USB_PHY_48, provided by USBPHYC
and named "ck_usbo_48m".

Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>

phy: stm32-usbphyc: usbphyc is a clock provider of ck_usbo_48m clock

ck_usbo_48m is generated by usbphyc PLL and used by OTG controller
for Full-Speed use cases with dedicated Full-Speed transceiver.

ck_usbo_48m is available as soon as the PLL is enabled.

Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>

phy: stm32-usbphyc: add counter of PLL consumer

Add the counter of the PLL user n_pll_cons managed by the 2 functions
stm32_usbphyc_pll_enable / stm32_usbphyc_pll_disable.

This counter allow to remove the function stm32_usbphyc_is_init
and it is a preliminary step for ck_usbo_48m introduction.

Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>

board: stm32mp1: remove test on CONFIG_DM_REGULATOR

The tests on CONFIG_DM_REGULATOR, added to avoid compilation issues, can
now be removed, they are no more needed since the commit 16cc5ad0b439
("power: regulator: add dummy helper").

Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>

stm32mp: simplify the STM32MP15x package parsing code

Simplify the package parsing code for STM32MP15X as package can be
affected with get_cpu_package() result.

Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>

board: freescale: p1_p2_rdb_pc: Turn off watchdog before reset

P1/P2 RDB boards have external max6370 watchdog connected to CPLD and this
watchdog is not deactivated on board reset. So if it is active during board
reset, it can trigger another reset when CPU is booting U-Boot. To prevent
possible infinite reset loop caused by external watchdog, turn it off
before reset.

Do it via a new board_reset_prepare() callback which is called from
do_reset() function before any reset sequence.

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

board: freescale: p1_p2_rdb_pc: Avoid usage of CPLD's system reset register

CPLD's system reset register is buggy and requires workaround in U-Boot.
So use this kind of board reset only when there is no other reset option.

Introduce a new board_reset_last() callback which is last-stage
board-specific reset and implement CPLD's system reset in this new
board_reset_last() callback instead of board_reset() callback.

Fixes: 20fb58fc5a1c ("board: freescale: p1_p2_rdb_pc: Implement board_reset()")
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>

board: freescale: p1_p2_rdb_pc: Add workaround for non-working watchdog

If watchdog timer was already set to non-disabled value then it means that
watchdog timer was already activated, has already expired and caused CPU
reset. If this happened then due to CPLD firmware bug, writing to wd_cfg
register has no effect and therefore it is not possible to reactivate
watchdog timer again. Watchdog starts working again after CPU reset via
non-watchdog method.

Implement this workaround (reset CPU when it was reset by watchdog) to make
watchdog usable again. Watchdog timer logic on these P1/P2 RDB boards is
connected to CPLD, not to SoC itself.

Note that reset does not occur immediately after calling do_reset(), but
after few ms later as real reset is done by CPLD. So it is normal that
function do_reset() returns. Therefore hangs after calling do_reset() to
prevent CPU execution of the rest U-Boot code.

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

board: freescale: p1_p2_rdb_pc: Add workaround for board reset reboot loop

CPLD's system reset register on P1/P2 RDB boards is not autocleared after
flipping it. If this register is set to one in 100ms after reset starts
then CPLD triggers another CPU reset.

This means that trying to reset board via CPLD system reset register cause
reboot loop. To prevent this reboot loop, the only workaround is to try to
clear CPLD's system reset register as early as possible. U-Boot is already
doing it in its board_early_init_f() function, which seems to be enough as
register is cleared prior CPLD triggers another reset.

But board_early_init_f() is not called from SPL and therefore usage of SPL
can cause reboot loop.

To prevent reboot loop when using SPL, call board_early_init_f() function
in SPL too. For accessing CPLD memory space it is needed to have CPLD entry
in TLB.

With this change it is possible to trigger board reset via CPLD's system
reset register on P2020 RDB board.

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

RISC-V: enable CONFIG_SYSRESET_SBI by default

System reset via the SRST extension in the SBI should be the default.
The driver checks if the extension is available when probing.
So there is no risk in enabling it.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>

cmd/sbi: format KVM version

Format the KVM implementation number in a human readable form.

With the patch output of the sbi command for Linux 5.19.1 looks like:

    => sbi
    SBI 0.3
    KVM 5.19.1
    Machine:
      Vendor ID 0
      Architecture ID 7005c
      Implementation ID 7005c
    Extensions:
      SBI Base Functionality
      Timer Extension
      IPI Extension
      RFENCE Extension
      Hart State Management Extension
      System Reset Extension

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>

riscv: dts: sifive: Synchronize FU740 and Unmatched DT

These DT files are synchronized from Linux 5.19.

Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>

dt-bindings: clock: sifive: sync FU740 PRCI clock binding header

This commit sychronizes the header file for FU740 PRCI clocks with the
one from Linux 5.19.

The constant values are the same, but all constant names are changed
(most are just prefixed with FU740_).

Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>

net: enetc: Fix use after free issue in fsl_enetc.c

If ethernet connected to SFP, like this:

&enetc_port0 {
            phy-connection-type = "sgmii";
            sfp = <&sfp0>;
            managed = "in-band-status";
            status = "okay";
};

Then enetc_config_phy returns -ENODEV and the memory containing the mdio interface is freed.
It's better to unregister and free mdio resources.

Signed-off-by: Siarhei Yasinski <siarhei.yasinski@sintecs.eu>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>

ddr: fsl: Make bank_addr_bits reflect actual bits

In both the Freescale DDR controller and the SPD spec, bank address bits
are stored as the number of bank address bits minus 2. For example, if a
chip had 8 banks (3 total bank address bits), the value of
bank_addr_bits would be 1. This is rather surprising for users
configuring their memory manually, since they can't set bank_addr_bits
to the actual number of bank address bits. Rectify this.

There is at least one example of this kind of mistake already, in
board/freescale/t102xrdb/ddr.c. The documented MT40A512M8HX has two bank
address bits, but bank_addr_bits was set to 2, implying 4 bank address
bits. Such a value is reserved in BA_BITS_CS, but I suspect the
controller simply ignores the top bit, making this kind of mistake
harmless, if misleading.

Fixes: e8a7f1c32b5 ("powerpc/t1023rdb: Add T1023 RDB board support")
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>

ddr: fsl: Reduce the size of interactive options

The interactive mode uses large several tables of options which can be
configured. However, much of the contents of these tables are
repetetive. For example, no struct is larger than half a kilobyte, so
the offset only takes up 9 bits. Similarly, the size is only ever 4 or
8, and printhex is a boolean. Reduce the size of these fields. This
reduces the size of the options tables by around 10 KiB. However, the
largest contributor to the size of the options tables is the use of a
pointer for the strings. A better approach would be to use a separate
array of strings, and store an integer index in the options tables.
However, this would require a large re-architecting of this file.

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

board: sl28: remove COUNTER_FREQUENCY_REAL

The frequency of the system counter is static which is given by the
COUNTER_FREQUENCY option. Remove COUNTER_FREQUENCY_REAL.

Signed-off-by: Michael Walle <michael@walle.cc>
Signed-off-by: Peng Fan <peng.fan@nxp.com>

board: sl28: support dynamic prompts

Depending on the boot source, set different CLI prompts. This will help
the user to figure out in which mode the bootloader was started. There
are two special modes: failsafe and SDHC boot.

Signed-off-by: Michael Walle <michael@walle.cc>
Signed-off-by: Peng Fan <peng.fan@nxp.com>

board: sl28: add user friendly names for the boot sources

During startup the SPL will print where the u-boot proper is read from.
Instead of using the default names, provide more user friendly names.

Signed-off-by: Michael Walle <michael@walle.cc>
Signed-off-by: Peng Fan <peng.fan@nxp.com>

board: sl28: implement additional bootsources

The board is able to boot from the following source:
 - user-updateble SPI flash
 - write-protected part of the same SPI flash
 - eMMC
 - SD card

Implement the needed function hooks to support all of these boot
sources.

Signed-off-by: Michael Walle <michael@walle.cc>
Signed-off-by: Peng Fan <peng.fan@nxp.com>

armv8: layerscape: spl: mark OCRAM as non-secure

By default the OCRAM is marked as secure. While the SPL runs in EL3 and
thus can access it, DMA devices cannot. Mark the whole OCRAM as
non-secure.
This will fix MMC and SD card boot on LS1028A when using SPL instead of
TF-A.

Signed-off-by: Michael Walle <michael@walle.cc>
Signed-off-by: Peng Fan <peng.fan@nxp.com>

Prepare v2022.10-rc4

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>

riscv: dts: Sync important Unmatched pmic and qspi0 changes from Linux

This adds the onkey, RTC and watchdog children to the DA9063 PMIC node,
fixes the compatible for qspi0's flash node to match the official DT
schema (it being an is25wp256 is discoverable, hence jedec,spi-nor is
the only compatible that should be present) and exposes the card detect
GPIO.

Note that the device trees still diverge in some places (including
important things like the PCIe controller's clock name) and should be
cleaned up so that a common device tree is used in both projects rather
than having different bindings. This patch does not attempt to do that,
merely expose important functionality present in Linux's that is not in
U-Boot's so that it can be used without the OS providing its own bundled
copy.

Signed-off-by: Jessica Clarke <jrtc27@jrtc27.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>

Merge tag 'u-boot-rockchip-20220905' of https://source.denx.de/u-boot/custodians/u-boot-rockchip

- migrate to use binman for U-Boot image generate on rockchip platform;
- Some fixes for rk3399 and rk3308;

clk: rockchip: rk3399: Fix Unknown clock 77 on mmc@fe310000

Adding some debug prints I can see:

MMC:   mmc@fe320000: Got clock clock-controller@ff760000 76
mmc@fe310000: Got clock clock-controller@ff760000 77
Unknown clock 77
rockchip_dwmmc_get_mmc_clk: err=-2
mmc@fe310000: 3, mmc@fe320000: 1, mmc@fe330000: 0

According to kernel code the SDIO clock is identical to SDMMC clock
except for the con 16->15 change.

Add support for the clock to avoid the error.

Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

rockchip: add u-boot-rockchip-spi.bin image for booting from SPI-NOR flash

This new image is similar to u-boot-rockchip.bin except that it's
destined to be flashed on SPI-NOR flashes.

Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

rockchip: allow to build SPI images even without HAS_ROM option

This prepares for the creation of a u-boot-rockchip-spi.bin image
similar to u-boot-rockchip.bin to the exception it's destined for
SPI-NOR flashes instead of MMC storage medium.

Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

rockchip: simplify binman image dependencies addition to INPUTS

By factoring SPL check in the first condition, this makes the checks a
bit less convoluted and more readable.

Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

rockchip: generate u-boot-rockchip.bin with binman for ARM64 boards

This allows to build u-boot-rockchip.bin binary with binman for Rockchip
ARM64 boards instead of the legacy Makefile way.

Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

rockchip: generate idbloader.img content for u-boot-rockchip.bin with binman for ARM

idbloader.img content - currently created by way of Makefile - can be
created by binman directly.

So let's do that for Rockchip ARM platforms.

Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

rockchip: remove binman temporary files when cleaning

Binman mkimage entry generates temporary files so let's remove them
when calling `make clean`.

Fixes: 9b312e26fc77 ("rockchip: Enable building a SPI ROM image on jerry")
Cc: Quentin Schulz <foss+uboot@0leil.net>
Reported-by: Johan Jonker <jbx6244@gmail.com>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

binman: allow user-defined filenames for mkimage entry

mkimage entry currently creates a file whose name is derived from the
section name containing said entry.

Let's allow the user to define a filename for the mkimage-generated
binary by using the 'filename' DT property.

Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

binman: add support for skipping file concatenation for mkimage

Some image types handled by mkimage require the datafiles to be passed
independently (-d data1:data2) for specific handling of each. A
concatenation of datafiles prior to passing them to mkimage wouldn't
work.

That is the case for rkspi for example which requires page alignment
and only writing 2KB every 4KB.

This adds the ability to tell binman to pass the datafiles without
prior concatenation to mkimage, by adding the multiple-data-files
boolean property to the mkimage node.

Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

rockchip: rk3399: sync spl_boot_devices_tbl and boot_devices node paths

While technically not a bug, let's have some consistency in paths
returned by u-boot,spl-boot-order look-up and the one saved in
u-boot,spl-boot-device by syncing spl_boot_devices_tbl and boot_devices
node paths.

Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Tested-by: Xavier Drudis Ferran <xdrudis@tinet.cat>
Reviewed-by: Xavier Drudis Ferran <xdrudis@tinet.cat>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

rockchip: rk3399: fix incorrect boot-device in u-boot, spl-boot-device

On RK3399, mmc0 is eMMC and mmc1 is SD card, c.f. console:
MMC:   mmc@fe320000: 1, mmc@fe330000: 0

In arch/arm/mach-rockchip/spl-boot-order.c:board_boot_order, the
boot_device (BOOT_DEVICE_*) value is gotten from spl_node_to_boot_device
function. Said function returns BOOT_DEVICE_MMC1 for mmc0 (eMMC) and
BOOT_DEVICE_MMC2 for mmc1 (SD card).

Since the SD card controller is at mmc@fe320000, it should be associated
with BOOT_DEVICE_MMC2 and not BOOT_DEVICE_MMC1. Same applies to eMMC.

Let's fix that by swapping the two BOOT_DEVICEs.

Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Tested-by: Xavier Drudis Ferran <xdrudis@tinet.cat>

rockchip: rk3308: fix same-as-spl boot order

Rockchip SoCs need the boot_devices array defined in order to map the
bootloader's value to a U-Boot device.  Implement this for rk3308.

Signed-off-by: John Keeping <john@metanate.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@vrull.eu>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

rockchip: rk3308: fix rockchip_dnl_key_pressed() on roc-cc

Commit 6aa4fe3912 ("dm: core: Rename and fix uclass_get_by_name_len()")
changed uclass_get_device_by_name() to an exact match when previously it
behaved as a prefix match.

The roc-cc code relied on this prefix match by only specifying part of
the device name.  Fix this by using the full name including the address.

Signed-off-by: John Keeping <john@metanate.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

rockchip: rk3399: boot_devices: fix eMMC node name

When idbloader.img is flashed on the eMMC, the SPL still tries to load
from SPI-NOR first.

This is due to an incorrect look-up in the Device Tree. Since commit
822556a93459 ("arm: dts: sync the Rockhip 3399 SoCs from Linux"), the
node name (but not label) changed from sdhci@fe330000 to mmc@fe330000
meaning U-Boot SPL is not looking for the correct node name anymore and
fails to find the "same-as-spl" node when eMMC is the medium from which
the SPL booted.

Fixes: 822556a93459 ("arm: dts: sync the Rockhip 3399 SoCs from Linux")
Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Xavier Drudis Ferran <xdrudis@tinet.cat>
Reviewed-by: Artem Lapkin <email2tema@gmail.com>
Tested-by: Artem Lapkin <email2tema@gmail.com>
Tested-by: Lapkin Artem <email2tema@gmail.com>
Tested-by: Lapkin Artem <email2tema@gmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

ram: rk3399: Conduct memory training at 400MHz

Currently the default initialisation frequency is 50MHz.  Although
this does appear to be suitable for some LPDDR4 RAM chips, training at
this low frequency has been seen to cause Column errors, leading to
Capacity check errors on others.

Here we force RAM initialisation to happen at 400MHz before ramping up
to the final value running value of 800MHz after everything has been
successfully configured.

Link: https://lore.kernel.org/u-boot/Yo4v3jUeHXTovjOH@google.com/
Suggested-by: YouMin Chen <cym@rock-chips.com>
Signed-off-by: Lee Jones <lee@kernel.org>
Tested-by: Xavier Drudis Ferran <xdrudis@tinet.cat>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Tested-by: Michal Suchánek <msuchanek@suse.de>

ram: rk3399: Fix faulty frequency change reports

Frequency changes to 400MHz are presently reported as:

  lpddr4_set_rate_0: change freq to 400000000 mhz 0, 1

This is obviously wrong by 6 orders of magnitude.

Ensure frequency changes are reported accurately.

Signed-off-by: Lee Jones <lee@kernel.org>
Tested-by: Xavier Drudis Ferran <xdrudis@tinet.cat>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

ram: rk3399: Fix .set_rate_index() error handling

Functions pointed to by this op pointer can return non-zero values
indicating an error.  Ensure any error value is propagated back up the
call-chain.

Signed-off-by: Lee Jones <lee@kernel.org>
Tested-by: Xavier Drudis Ferran <xdrudis@tinet.cat>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

drivers: ram: rockchip: Fix dram channels calculation for rk3399

Only add the dram channel when we finally setup it successfully at the
last step.

Signed-off-by: Han Pengfei <pengphei@foxmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

arm: dts: rockchip: rk3288: rename mmc nodenames

The boot_devices constants for rk3288 were changed to match the
binding, but the dtsi file was not synced.
Fix by renaming the rk3288 mmc node names.
Also correct the clock name for "ciu-drive".

Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

Merge tag 'tpm-03092022' of https://source.denx.de/u-boot/custodians/u-boot-tpm

TPM fixes and state reporting

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

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

tpm: Allow committing non-volatile data

Add an option to tell the TPM to commit non-volatile data immediately it
is changed, rather than waiting until later. This is needed in some
situations, since if the device reboots it may not write the data.

Add definitions for the rest of the Cr50 commands while we are here.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

tpm: Implement state command for Cr50

Add a vendor-specific TPM2 command for this and implement it for Cr50.
Note: This is not part of the TPM spec, but is a Cr50 extension.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

tpm: Allow reporting the internal state

It is useful to read information about the current TPM state, where
supported, e.g. for debugging purposes when verified boot fails.

Add support for this to the TPM interface as well as Cr50. Add a simple
sandbox test.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

tpm: sandbox: Allow init of TPM in a different phase

At present the emulator assumes that the TPM is inited in the same phase
where it is used. But in fact SPL may init the TPM, so we don't want to
complain when U-Boot proper later uses it. Remove this check.

It might be best to save this information into the device state for the
TPM, so that we can make sure the TPM was inited at some point. For now,
this seems good enough.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

tpm: Correct the define-space command in TPMv2

The message format is incorrect. Fix it.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

tpm: Correct the permissions command in TPMv1

The offset here is incorrect. Fix it.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

tpm: Require a digest source when extending the PCR

This feature is used for measured boot, so we can add a log entry to the
TCPA with some information about where the digest comes from. It is not
currently supported in the TPM drivers, but add it to the API so that
code which expects it can signal its request.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

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

Pull request of efi-2022-10-rc4-2

UEFI:
* provide EFI Conformance Profile Table
* fix display of NVMe EUI-64
* fixes for Simple Text Input Ex Protocol
* fix exception unit-test on non-x86 sandbox

efi_loader: fix display of NVMe EUI-64

UEFI specification 2.9A requires to display the EUI-64 "in hexadecimal
format with byte 7 first (i.e., on the left) and byte 0 last".

This is in contrast to what the NVMe specification wants.
But it is what EDK II has been implementing.

Here is an example with the patch applied:

    qemu-system-aarch64 -machine virt -cpu cortex-a72 -nographic \
    -bios denx/u-boot.bin \
    -device nvme,id=nvme1,serial=9ff81223 \
    -device nvme-ns,bus=nvme1,drive=nvme1n0,eui64=0x123456789ABCDEF0 \
    -drive file=arm64.img,if=none,format=raw,id=nvme1n0

    => nvme scan
    => efidebug devices
    Device Path
    ====================
    /VenHw(…)/NVMe(0x1,f0-de-bc-9a-78-56-34-12)

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

efi: ECPT add EBBRv2.0 conformance profile

Display the EBBRv2.0 conformance in the ECPT table.

The EBBRv2.0 conformance profile is set in the ECPT if
CONFIG_EFI_EBBR_2_0_CONFORMANCE=y.

Signed-off-by: Jose Marinho <jose.marinho@arm.com>
Add dependencies for CONFIG_EFI_EBBR_2_0_CONFORMANCE.
Enable the setting by default.
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

efi: Create ECPT table

The ECPT table will be included in the UEFI specification 2.9+.
The ECPT table was introduced in UEFI following the code-first path. The
acceptance ticket can be viewed at:
https://bugzilla.tianocore.org/show_bug.cgi?id=3591

The Conformance Profiles table is a UEFI configuration table that contains
GUID of the UEFI profiles that the UEFI implementation conforms with.

The ECPT table is created when CONFIG_EFI_ECPT=y.
The config is set by default.

Signed-off-by: Jose Marinho <jose.marinho@arm.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

efi_selftest: on sandbox use host specific assembly

The selftest checking the handling of exceptions in UEFI binaries is using
assembly to provide an undefined instruction. On the sandbox the correct
form of the instruction depends on the host architecture.

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

efi_loader: support CTRL+\ - CTRL+_

In the extended text input protocol support input of control letters
0x1c - 0x1f.

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

efi_loader: compliance Simple Text Input Ex Protocol

We cannot expect the buffers passed to the input protocols to be zero
filled. If only modifier keys are pressed, we have to return EFI_NOT_READY
but we still have to fill the key structure.

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

efi_loader: printing UEFI revision in helloworld.efi

We need to support multiple digits in the parts of the UEFI verision
number. E.g.

    EFI_SPECIFICATION_VERSION = (123 << 16) | 456

must be printed as

    123.45.6

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

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

Pull request for efi-2022-10-rc4

Documentation:

* add a page on sending patches
* bindings for FWU Metadata mtd storage
* fpio status output fields description

UEFI:

* ensure all block devices are probed

drivers: usb: fastboot: Fix full-speed usb descriptor

The host will report such error message if the fastboot device work in
full-speed mode: "Duplicate descriptor for config 1 interface 0
altsetting 0, skipping"

Fastboot device ack both full and high speed interface descriptors when
work in full-speed mode, that's will cause this issue.

Fix it.

Signed-off-by: qianfan Zhao <qianfanguijin@163.com>
Reviewed-by: John Keeping <john@metanate.com>

renesas: Fix RPC-IF compatible values

The compatible values used for device nodes representing Renesas Reduced
Pin Count Interfaces were based on preliminary versions of the Device
Tree Bindings.

Correct them in both DTSi files and drivers, to match the final DT
Bindings.

Note that there are no DT bindings for RPC-IF on RZ/A1 yet, hence the
most logical SoC-specific value is used, without specifying a
family-specific value.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>

ARM: renesas: Propagate RPC-IF enablement to subsequent software

As the Renesas Reduced Pin Count Interface may be locked by TF-A, it is
disabled by default[1].  When unlocked, TF-A passes a DT fragment to
enable it, which is applied to the U-Boot DT[2].

Unlike the memory layout, the RPC-IF enablement is not propagated to
subsequent software.  Hence e.g. Linux cannot know if the RPC-IF is
locked or not, and will lock-up when trying to access the RPC-IF when
locked.

Fix this by checking if the RPC-IF is enabled in the TF-A DT fragment, and
setting the status of the RPC-IF device node in the target DT, if
present, to "okay".  Do this only when a "flash" subnode is found, to
avoid errors in subsequent software when the RPC-IF is not intended to
be used.

Note that this requires the status of the RPC-IF node to be set to
"disabled" in the target DT, just like in the U-Boot DT.

[1] commit 3d5f45c95c9db73d ("ARM: dts: rmobile: Disable RPC HF by
    default")
[2] commit 361377dbdbc9f0f5 ("ARM: rmobile: Merge prior-stage firmware
    DT fragment into U-Boot DT on Gen3")

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>

ARM: dts: rmobile: Fix RPC-IF device node names

According to the Generic Names Recommendation in the Devicetree
Specification Release v0.3, and the DT Bindings for the Renesas Reduced
Pin Count Interface, the node name for a Renesas RPC-IF device should be
"spi".  Especially on R-Car Gen3 and RZ/G2, the node name matters, as
the node is enabled by passing a DT fragment from TF-A to U-Boot, and
from U-Boot to subsequent software.

Fix this by renaming the device nodes from "rpc" to "spi".

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>

binman: bintool: bzip2: fix version function on non-Debian-based systems

Upstream bzip2 1.0.x actually is stuck when running bzip2 -V and
redirecting the output. This is fixed in Debian for about a decade
already in
https://git.launchpad.net/ubuntu/+source/bzip2/tree/debian/patches/20-legacy.patch?h=ubuntu/jammy
and in bzip2 1.1.x (no release yet, see
https://gitlab.com/bzip2/bzip2/-/commit/65179284ceddc43e6388bf4ed8c2d85cf16e1b2f
).

Fedora notably does not have such a patch.

Since bzip2 --help actually prints the version number too, let's use it
instead so that binman works fine on (hopefully) all distributions.

Fixes: 45aa2798008c ("binman: Add bzip2 bintool")
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

binman: btool: futility: use Bintool.version

Bintool.version can now be passed the binary argument to return the
version text, so there's no need to override it in futility anymore.

Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

binman: btool: fiptool: use Bintool.version

Bintool.version can now be passed the binary argument to return the
version text, so there's no need to override it in fiptool anymore.

Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

binman: bintool: parametrize args to pass to binary for returning version

The code to check the version is very similar between binaries, the most
likely only needed variables are the regex to find the version (already
supported) and the args to pass to the binary so that it prints this
version (e.g. --version, -V or similar).

Let's make it a parameter of Bintool so that code duplication can be
avoided for simple changes.

Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>

binman: btool: mkimage: use Bintool.version

Bintool.version already contains everything required to get the version
out of mkimage binary so let's not override it with its own
implementation.

Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>