Merge branch '2022-03-10-platform-updates' into next

- Assorted TI omap3, j7 platform updates
- Phytium Pomelo board

arm: add initial support for the Phytium Pomelo Board

This adds platform code and the device tree for the Phytium Pomelo Board.
The initial support comprises the UART and the PCIE.

Signed-off-by: weichangzheng <nicholas_zheng@outlook.com>

ARM: mach-omap2: omap3: Make clock functions static

get_osc_clk_speed and get_sys_clkin_sel are only used in
one file.  Make them static.

Tested on OMAP3530, DM3730, AM3517.

Signed-off-by: Adam Ford <aford173@gmail.com>

ARM: am3517_evm: Remove hard-coded pin muxing

With updated device trees now supporting pinmuxing for USB,
ethernet, MMC, and other peripherals necessary to start MLO
and U-Boot, the hard-coded pinmux options can be removed since
they are now handed by DM and only muxed when the respective
peripheral needs it.

Signed-off-by: Adam Ford <aford173@gmail.com>
Tested-by: Derald D. Woods <woods.technical@gmail.com>

ARM: dts: am3517-evm: Sync DTS with Linux 5.17-rc5

Sync the am3517-evm device tree files with those from Linux
5.17-rc5 with some additional fixes for pinmuxing Ethernet and
moving the pinmux references to the respective peripherals.

Signed-off-by: Adam Ford <aford173@gmail.com>
Tested-by: Derald D. Woods <woods.technical@gmail.com>

ARM: dts: logicpd-torpedo: Resyc DTS files with Linux 5.17-rc5

Resyc DTS files with Linux 5.17-rc5.

Signed-off-by: Adam Ford <aford173@gmail.com>

ARM: omap3_logic: Remove hard-coded USB muxing

With recent fixes to USB pinmuxing in the device trees, there
is no need to hard-code the pinmuxing in this table.  It is
all handled in DM now.

Signed-off-by: Adam Ford <aford173@gmail.com>

ARM: dts: logicpd-som-lv: Resync DTS files with Linux 5.17-rc5

Resync the DTS files for the Logic PD SOM-LV with Linux 5.17-rc5
with some additional pending changes to address issues with
wrong pin-muxing on the OMAP35.

Signed-off-by: Adam Ford <aford173@gmail.com>

ARM: am3517-evm: Remove more non-DM legacy ethernet reset code

The ethernet controller is DM compliant, and the device tree
defines it.  There is no need to manually handle pulling
the ethernet out of reset.

Signed-off-by: Adam Ford <aford173@gmail.com>
Tested-by: Derald D. Woods <woods.technical@gmail.com>

configs: j721e_hs_evm_a72_defconfig: Add command for initializing QSGMII PHY

QSGMII PHY present on the j721e common processor board requires
to be initialized before the core boots up. Therefore, run the
corresponding command during boot to do the same.

Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>

configs: j721e_evm_a72_defconfig: Fix the bootcmd

Add the command "boot_rprocs" that is required for booting remote
processors in U-Boot.

Fixes: 5980925e2a5a ("include: configs: j721e_evm: Add support to boot ethfw core in j721e")
Reported-by: Jesse Villarreal <jesse.villarreal@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>

include: configs: j721e_evm.h: Fix the env variable corresponding to QSGMII PHY init

QSGMII PHY initialization should only be done for J721E EVMs and not for
J721E-SK boards. Therefore, fix the environment variables accordingly.

Also, by default remote processors should not be booted in U-Boot but
rather be left to the users to enable this by setting dorprocboot.
Therefore, remove dorprocboot that is being set by default.

Fixes: 5980925e2a5a ("include: configs: j721e_evm: Add support to boot ethfw core in j721e")
Reported-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>

ram: aspeed: Rework kconfig options

Ensure the ASPEED related options are grouped together under the RAM
option when enabling support.

This also makes some minor grammar corrections and renames options so
they present cleanly in menuconfig.

There should be no functional change to the configuration or binary.

Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Dylan Hung <dylan_hung@aspeedtech.com>

ARM: omap3_beagle: Enable DM_PMIC and DM_REGULATOR

Enabling DM_PMIC, DM_REGULATOR_FIXED, and DM_REGULATOR_GPIO
gives us the ability to better monitor voltages and enable
hardware through the device tree. The TL4030 (TPS65950) is
not yet migrated to DM, so this patch only enables the fixed
and GPIO controlled regulators.

Based on commit [1][2].

[1] a40d3cc845756e1e38af5ac31986539417e64abb
[2] 2448e42d73fb91e4b56bb41b2677e18ab99a6c83

Signed-off-by: Romain Naour <romain.naour@gmail.com>

ARM: omap3_beagle: Enable Pinctrl

The simple pinctrl driver currently available works with the omap3.
Enabling this will use the device tree to automatically set the
pin-muxing for various drivers.

Based on commit: 57dbf754e37d3347cad441f3869bf72c0d726a71

Signed-off-by: Romain Naour <romain.naour@gmail.com>

ARM: omap3_beagle: Power on MMC when setting up PMIC

The PMIC enables power to the MMC card by default, but depending
on the state it was left when restarted, it's possible the MMC
may be powered down.

This patch patch explicitly tells the twl4030 to power the MMC.

Based on commits [1][2].

[1] 64fd2d26140aa72b43428d079974f7c0e7f88353
[2] 27b653449178e80b333e7bc5a81eed3bd1bd6861

Signed-off-by: Romain Naour <romain.naour@gmail.com>

ARM: omap3_beagle: Remove non-DM initialization

With DM_MMC working for both SPL and U-Boot, this patch removes
the legacy style of initializing the MMC driver.

Based on omap3_logic: 42140dd0962bc134c0aad27524d0f4cc3955f255.

Signed-off-by: Romain Naour <romain.naour@gmail.com>

Merge branch '2022-03-09-events-subsystem' into next

To quote the author:
It is a common need in U-Boot to have one subsystem notify another
when something happens. An example is reading a partition table when a
new block device is set up.

It is also common to add weak functions and 'hook' functions to modify
how U-Boot works. See for example ft_board_setup() and the like.

U-Boot would benefit from a generic mechanism to handle these cases,
with the ability to hook into various 'events' in a
subsystem-independent and transparent way.

This series provides a way to create and dispatch events, with a way of
registering a 'spy' which watches for events of different types. This
allows 'hook' functions to be created in a generic way.

It also includes a script to list the hooks in an image, which is a bit
easier to debug than weak functions, as well as an 'event' command to
do the same from within U-Boot.

These 'static' events can be used to replace hooks like misc_init_f(),
for example. Also included is basic support for 'dynamic' events, where
a spy can be registered at runtime. The need for this is still being
figured out.

event: Add documentation

Add documentation for events, including the event command.

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

event: Add a script to decode the event-spy list

For debugging and dicoverability it is useful to be able to see a list of
each event spy in a U-Boot ELF file. Add a script which shows this, along
with the event type and the source location. This makes events a little
easier to use than weak functions, for example.

Add a basic sandbox test as well. We could provide a test for other
boards, but for now, few use events.

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

event: Add a command

Add a command to show the available events.

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

event: Convert arch_cpu_init_dm() to use events

Instead of a special function, send an event after driver model is inited
and adjust the boards which use this function.

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

event: Convert misc_init_f() to use events

This hook can be implmented using events, for the three boards that
actually use it.

Add the event type and event handlers. Drop CONFIG_MISC_INIT_F since we
can just use CONFIG_EVENT to control this. Since sandbox always enables
CONFIG_EVENT, we can drop the defconfig lines there too.

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

event: Add events for device probe/remove

Generate events when devices are probed or removed, allowing hooks
to be added for these situations.

This is controlled by the DM_EVENT config option.

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

event: Set up the event system on start-up

Call event_init() before relocation to get the event system running.

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

event: Add a simple test

Add a test for event registration and activation.

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

event: Add basic support for events

Add a way to create and dispatch events without needing to allocate
memory. Also add a way to 'spy' on events, thus allowing 'hooks' to be
created.

Use a linker list for static events, which we can use to replace functions
like arch_cpu_init_f(). Allow an EVENT_DEBUG option which makes it
easier to see what is going on at runtime, but uses more code space.

Dynamic events allow the creation of a spy at runtime. This is not always
necessary, but can be enabled with EVENT_DYNAMIC if needed.

A 'test' event is the only option for now.

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

binman: Expand elf support a little

Allow finding a symbol by its address. Also export the function to get
the file offset of a particular address, so it can be used by a script to
be added.

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

sandbox: start: Sort the header files

These header files don't follow the correct order. Fix this.

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

Merge branch '2022-03-07-add-platforms' into next

- bcm6753 support
- Aspeed GPIO driver
- AM33xx DT-related MMC updates

configs: evb-ast2[56]00: Enable GPIO control

Build in the driver for the Aspeed GPIO controller and turn on the
`gpio` shell command.

Signed-off-by: Andrew Jeffery <andrew@aj.id.au>

ARM: dts: ast2500: Add ngpios property to GPIO node

Populate gpio_count in the gpio subsystem for the AST2500.

Signed-off-by: Andrew Jeffery <andrew@aj.id.au>

gpio: Add Aspeed GPIO driver

The Aspeed GPIO driver supports the GPIO controllers found in the
AST2400, AST2500 and AST2600 BMC SoCs. The implementation is a cut-down
copy of the upstream Linux kernel driver, adapted for u-boot.

Signed-off-by: Andrew Jeffery <andrew@aj.id.au>

arm: dts: Add DTS description for MMC2 am33xx devices

This code has been ported from Linux v5.16.9 arch/arm/boot/dts/am33xx.dtsi
file to allow correct usage of MMC2 controller in U-Boot.

This IP block is a bit specific as it is connected to L3 interconnect bus,
whereas mmc[01] are connected to L4.

Proper configuration of this block (including providing clock) is handled
in ti-sysc.c driver.

Signed-off-by: Lukasz Majewski <lukma@denx.de>

arm: dts: Add mmc[01] aliases to am33xx.dtsi

This change provides similar aliases definitions as now present in
Linux kernel v5.16.9 for am33xx.dtsi file.

Signed-off-by: Lukasz Majewski <lukma@denx.de>

arm: mmc: Add "ti, am335-sdhci" compatible for TI's omap_hsmmc driver

In the Linux kernel (v5.16) for this SoC there are two separate drivers
- namely sdhci-omap.c and omap_hsmmc.c which have separate set of
compatibles.

The U-Boot's drivers/mmc/omap_hsmmc.c driver supports both eMMC and
SD devices - hence the compatible for SDHCI can be added.

After this change the am335x DTS description can be easier ported
from Linux kernel.

Signed-off-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>

configs: bcm96753ref_ram_defconfig: enable led support

Enable the led support on the refboard bcm96753ref.

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

arch: arm: dts: bcm96753ref: enable led support

Enable the led in the device tree of the refboard bcm96753ref.
It also defines two leds (led_red ad led_green).

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

arch: arm: dts: bcm6753: add led support

Add a node leds to support the LED IP in the
device tree of the bcm6753.

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

drivers: led: led_bcm6753: initial support

Add the support of the LED IP for bcm6357. This
LED IP supports blinking, fading and pulsating,
but for the moment, only blinking is supported.

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

bcm96753ref: add initial support

This add the initial support of the broadcom reference
board bcm96753ref with a bcm6753 SoC.

This board has 1 GB of RAM, 256 MB of flash (nand),
2 USB port, 1 UART, and 4 ethernet ports.

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

watchdog: bcm6345: allow to use this driver on arm bcm6753

This IP is also used on some arm SoC, so we allow to
use it on arm bcm6753 too.

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

nand: brcmnand: add bcm6753 support

This adds the nand support for chipset bcm6753.

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

gpio: bcm6345: allow to use this driver on arm bcm6753

This IP is also used on some arm SoC, so we allow to
use it on arm bcm6753 too.

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

bcm6753: add initial support

This add the initial support of the broadcom bcm6753 SoC family.

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

Merge branch '2022-03-03-Kconfig-migrations' into next

- Assorted Kconfig migrations and related cleanups.

Convert CONFIG_CHIP_SELECTS_PER_CTRL to Kconfig

This converts the following to Kconfig:
   CONFIG_CHIP_SELECTS_PER_CTRL

Cc: Alison Wang <alison.wang@nxp.com>
Cc: Pramod Kumar <pramod.kumar_1@nxp.com>
Cc: Priyanka Jain <priyanka.jain@nxp.com>
Cc: Rajesh Bhagat <rajesh.bhagat@nxp.com>
Cc: Vladimir Oltean <olteanv@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>

Convert CONFIG_CFI_FLASH_USE_WEAK_ACCESSORS to Kconfig

This converts the following to Kconfig:
   CONFIG_CFI_FLASH_USE_WEAK_ACCESSORS

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

net: Remove CONFIG_BOOTP_DHCP_REQUEST_DELAY

This option is not in use anywhere and the documentation implies it's
for some very old and unlikely to be seen currently issues.  Rather than
update the code so the CONFIG symbol could be easily in Kconfig, remove
the code.

Cc: Ramon Fried <rfried.dev@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Acked-by: Ramon Fried <rfried.dev@gmail.com>

Convert CONFIG_BOOTP_MAY_FAIL et al to Kconfig

This converts the following to Kconfig:
   CONFIG_BOOTP_MAY_FAIL
   CONFIG_BOOTP_VENDOREX
   CONFIG_BOOTP_BOOTFILESIZE
   CONFIG_BOOTP_NISDOMAIN
   CONFIG_BOOTP_TIMEOFFSET

Cc: Ramon Fried <rfried.dev@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>

powerpc: P1010RDB: Move CONFIG_BOOTMODE out of CONFIG namespace

This slight environment modification shouldn't be in the CONFIG
namespace, change it.

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

Convert CONFIG_BOOTFILE to Kconfig

This converts the following to Kconfig:
   CONFIG_BOOTFILE

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

Convert CONFIG_BOARD_POSTCLK_INIT to Kconfig

This converts the following to Kconfig:
   CONFIG_BOARD_POSTCLK_INIT

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

Convert CONFIG_BOARD_ECC_SUPPORT to Kconfig

This converts the following to Kconfig:
   CONFIG_BOARD_ECC_SUPPORT

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

Convert CONFIG_BIOSEMU to Kconfig

This converts the following to Kconfig:
   CONFIG_BIOSEMU

Cc: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>

Convert CONFIG_BOARD_COMMON to Kconfig

This converts the following to Kconfig:
   CONFIG_BOARD_COMMON

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

arm: exynos: Move BL1/2 SPI flash defines to their user, drop CONFIG

These particular values are not configurable and today we always set
CONFIG_SECURE_BL1_ONLY.  Move these to where they're used in the code,
and drop from the CONFIG namespace.

Cc: Minkyu Kang <mk7.kang@samsung.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Minkyu Kang <mk7.kang@samsung.com>

Convert CONFIG_BTB to Kconfig

This converts the following to Kconfig:
   CONFIG_BTB

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

powerpc: Remove unused MPC8540/60ADS code

Remove some code, primarily CPM2 related, that is now unused since the
removal of MPC8540/60ADS.

Fixes 3913191c8a6b ("powerpc: mpc8540ads: mpc8560ads: Drop support for MPC8540/60ADS")
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Merge branch '2022-03-02-scmi-updates' into next

- A small set of scmi updates

clk: scmi: register scmi clocks with CCF

Implements SCMI APIs to retrieve the number exposed SCMI clocks using
SCMI_PROTOCOL_ATTRIBUTES messages and the names of the clocks using
SCMI_CLOCK_ATTRIBUTES messages.

This change updates sandbox SCMI clock test driver to manage these
2 new message IDs.

Cc: Lukasz Majewski <lukma@denx.de>
Cc: Sean Anderson <seanga2@gmail.com>
Cc: Clement Leger <clement.leger@bootlin.com>
Cc: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>

firmware: scmi: fix sandbox and related tests for clock discovery

Updates sandbox SCMI clock driver and tests since enabling CCF will
mandate clock discovery that is all exposed SCMI clocks shall be
discovered at initialization. For this reason, sandbox SCMI clock
driver must emulate all clocks exposed by SCMI server, not only those
effectively consumed by some other U-Boot devices.

Therefore the sandbox SCMI test driver exposes 3 clocks (IDs 0, 1 and 2)
and sandbox SCMI clock consumer driver gets 2 of them.

Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>

scmi: change parameter dev in devm_scmi_process_msg

Changes devm_scmi_process_msg() first argument from target parent device
to current SCMI device and lookup the SCMI agent device among SCMI device
parents for find the SCMI agent operator needed for communication with
the firmware.

This change is needed in order to support CCF in clk_scmi driver unless
what CCF will fail to find the right udevice related to exposed SCMI
clocks.

This patch allows to simplify the caller sequence, using SCMI device
reference as parameter instead of knowing SCMI uclass topology. This
change also adds some protection in case devm_scmi_process_msg() API
function is called for an invalid device type.

Cc: Lukasz Majewski <lukma@denx.de>
Cc: Sean Anderson <seanga2@gmail.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Cc: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>

sandbox: scmi: test against a single scmi agent

As per DT bindings since Linux kernel v5.14, the device tree can define
only 1 SCMI agent node that is named scmi [1]. As a consequence, change
implementation of the SCMI driver test through sandbox architecture to
reflect that.

This change updates sandbox test DT and sandbox SCMI driver accordingly
since all these are impacted.

Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>

doc: binding: scmi: link to latest Linux kernel binding

Changes SCMI bindings documentation to relate to Linux kernel
source tree that recently changed the bindings description to YAML
format.

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

Merge branch '2022-03-02-armv8-fixes-and-cleanups' into next

To quote the author:
I was looking into the arm64 boot code lately and stumbled upon some
issues. Also Nishanth brought back memories of a lengthy debug session,
which was caused due to U-Boot keeping SErrors masked. As the resulting
patches are all somewhat related, I gathered this series here to address
those problems.

Patches 1 to 3 address exception handling issues, with the SError
enablement being the most prominent fix here.
Patch 4 cleans up asm/io.h. This was on the list before[1], but was
somehow lost when it was intercepted by a shorter version of itself.
Patches 5 and 6 clean up some unnecessarily complicated AArch64 assembly
code.

armv8: Fix and simplify branch_if_master/branch_if_slave

The branch_if_master macro jumps to a label if the CPU is the "master"
core, which we define as having all affinity levels set to 0. To check
for this condition, we need to mask off some bits from the MPIDR
register, then compare the remaining register value against zero.

The implementation of this was slighly broken (it preserved the upper
RES0 bits), overly complicated and hard to understand, especially since
it lacked comments. The same was true for the very similar
branch_if_slave macro.

Use a much shorter assembly sequence for those checks, use the same
masking for both macros (just negate the final branch), and put some
comments on them, to make it clear what the code does.
This allows to drop the second temporary register for branch_if_master,
so we adjust all call sites as well.

Also use the opportunity to remove a misleading comment: the macro
works fine on SoCs with multiple clusters. Judging by the commit
message, the original problem with the Juno SoC stems from the fact that
the master CPU *can* be configured to be from cluster 1, so the
assumption that the master CPU has all affinity values set to 0 does not
hold there. But this is already mentioned above in a comment, so remove
the extra comment.

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

armv8: Simplify switch_el macro

The switch_el macro is a neat contraption to handle cases where we need
different code depending on the current exception level, but its
implementation was longer than needed.

Simplify it by doing just one comparison, then using the different
condition codes to branch to the desired target. PState.CurrentEL just
holds two bits, and since we don't care about EL0, we can use >, =, < to
select EL3, EL2 and EL1, respectively.

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

arm: Clean up asm/io.h

asm/io.h is the header file containing the central MMIO accessor macros.
Judging by the header and the comments, it was apparently once copied
from the Linux kernel, but has deviated since then *heavily*. There is
absolutely no point in staying close to the original Linux code anymore,
so just remove the old cruft, by:
- removing pointless Linux history
- removing commented code
- removing outdated comments
- removing unused definitions (for mem_isa)

This massively improves the readability of the file.

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

armv8: Force SP_ELx stack pointer usage

In ARMv8 we have the choice between two stack pointers to use: SP_EL0 or
SP_ELx, which is banked per exception level. This choice is stored in
the SP field of PState, and can be read and set via the SPSel special
register. When the CPU takes an exception, it automatically switches to
the SP_ELx stack pointer.

Trusted Firmware enters U-Boot typically with SPSel set to 1, so we use
SP_ELx all along as our sole stack pointer, both for normal operation and
for exceptions.

But if we now for some reason enter U-Boot with SPSel cleared, we will
setup and use SP_EL0, which is fine, but leaves SP_ELx uninitialised.
When we now take an exception, we try to save the GPRs to some undefined
location, which will usually end badly.

To make sure we always have SP_ELx pointing to some memory, set SPSel
to 1 in the early boot code, to ensure safe operation at all times.

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

armv8: Always unmask SErrors

The ARMv8 architecture describes the "SError interrupt" as the fourth
kind of exception, next to synchronous exceptions, IRQs, and FIQs.
Those SErrors signal exceptional conditions from which the system might
not easily recover, and are normally generated by the interconnect as a
response to some bus error. A typical situation is access to a
non-existing memory address or device, but it might be deliberately
triggered by a device as well.
The SError interrupt replaces the Armv7 asynchronous abort.

Trusted Firmware enters U-Boot (BL33) typically with SErrors masked,
and we never enable them. However any SError condition still triggers
the SError interrupt, and this condition stays pending, it just won't be
handled. If now later on the Linux kernel unmasks the "A" bit in PState,
it will immediately take the exception, leading to a kernel crash.
This leaves many people scratching their head about the reason for
this, and leads to long debug sessions, possibly looking at the wrong
places (the kernel, but not U-Boot).

To avoid the situation, just unmask SErrors early in the ARMv8 boot
process, so that the U-Boot exception handlers reports them in a timely
manner. As SErrors are typically asynchronous, the register dump does
not need to point at the actual culprit, but it should happen very
shortly after the condition.

For those exceptions to be taken, we also need to route them to EL2,
if U-Boot is running in this exception level.

This removes the respective code snippet from the Freescale lowlevel
routine, as this is now handled in generic ARMv8 code.

Reported-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

cmd: exception: arm64: fix undefined, add faults

The arm64 version of the exception command was just defining the
undefined exception, but actually copied the AArch32 instruction.

Replace that with an encoding that is guaranteed to be and stay
undefined. Also add instructions to trigger unaligned access faults and
a breakpoint.
This brings ARM64 on par with ARM(32) for the exception command.

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

Merge branch '2022-03-02-enable-pylint-in-CI' into next

To quote the author:
This series adds a new errors-only pylint check and adds it to the CI
systems.

It also fixes the current errors in the U-Boot Python code, disabling
errors where it seems necessary.

A small patch to buildman allows it to build sandbox without any changes
to the default config file

Azure/GitLab CI: Add the pylint checker

Add a check that new Python code does not regress the pylint score for
any module.

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

buildman: Update default config to build for sandbox

At present the default .buildman file written by buildman does not specify
a default toolchain. Add an 'other' line so this works correctly and
sandbox builds run as expected.

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

Makefile: Add a way to check for pylint errors

Add a new 'pylint_err' target which only reports errors, not warnings.

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

test: Correct pylint errors

Fix pylint errors in all test.

This requires adding a get_spawn() method to the ConsoleBase base, so that
its subclass is happy.

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

moveconfig: Correct pylint errors

Fix two pylint errors in this file.

Note ACTION_SPL_NOT_EXIST is not defined so the dead code can be removed.

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

binman: Correct pylint errors

Fix pylint errors that can be fixed and mask those that seem to be
incorrect.

A complication with binman is that it tries to avoid importing libfdt
(or anything that imports it) unless needed, so that things like help
still work if it is missing.

Note that two tests are duplicated in binman and two others have
duplicate names, so both of these issues are fixed also.

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

dtoc: Correct pylint errors

Fix pylint errors in this directory.

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

buildman: Correct pylint errors

Fix pylint errors that can be fixed and mask those that seem to be
incorrect.

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

patman: Correct pylint errors

Fix pylint errors that can be fixed and mask those that seem to be
incorrect.

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

Prepare v2022.04-rc3

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

Merge branch '2022-02-28-bugfixes'

- Assorted bugfixes

board: stemmy: Detect board variants and patch DTB

This patch scans the cmdline from the Samsung SBL (second stage
bootloader) and stores the parameters board_id=N and lcdtype=N
in order to augment the DTB for different board and LCD types.

We then add a custom ft_board_setup() callback that will inspect
the DTB and patch it using the stored LCD type. At this point
we know which product we are dealing with, so using the passed
board_id we can also print the board variant for diagnostics.

We patch the Codina, Skomer and Kyle DTBs to use the right
LCD type as passed in lcdtype from the SBL.

This also creates an infrastructure for handling any other
Samsung U8500 board variants that may need a slightly augmented
DTB.

Cc: Markuss Broks <markuss.broks@gmail.com>
Cc: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

arm: apple: Switch to fully dynamic mem layout

Support for Apple M1 Pro and Max will allow using a single binary for
all M1 SoCs. The M1 Pro/Max have a different memory layout. The RAM
start address is 0x100_0000_0000 instead of 0x8_0000_0000.
Replace the hardcoded memory layout with dynamic initialized
environment variables in board_late_init().

Tested on Mac Mini (2020) and Macbook Pro 14-inch (2021).

Signed-off-by: Janne Grunau <j@jannau.net>
Reviewed-by: Mark Kettenis <kettenis@openbsd.org>

arm: pdu001: Setup pinmux for console UART as early as possible

To make sure we get a working console as soon as possible in the SPL the
UART pins require to be configured earlier. This is especially
true for the pins of UART3, since the PDU001 board uses this UART for
the console by default.

Signed-off-by: Felix Brack <fb@ltec.ch>

arm: pdu001: Fix early debugging UART

The changes from commit 0dba45864b2a ("arm: Init the debug UART")
prevent the early debug UART from being initialized correctly.
To fix this we not just configure the pin multiplexer but add setting up
early clocks.

Signed-off-by: Felix Brack <fb@ltec.ch>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

tools: mkimage/dumpimage: Allow to use -l with -T

Currently -l option for mkimage and dumpimage ignores option -T and always
tries to autodetect image type.

With this change it is possible to tell mkimage and dumpimage to parse
image file as specific type (and not random autodetected type). This allows
to use mkimage -l or dumpimage -l as tool for validating image.

params.type for -l option is now by default initialized to zero
(IH_TYPE_INVALID) instead of IH_TYPE_KERNEL. imagetool_get_type() for
IH_TYPE_INVALID returns NULL, which is assigned to tparams. mkimage and
dumpimage code is extended to handle tparams with NULL for -l option. And
imagetool_verify_print_header() is extended to do validation via tparams if
is not NULL.

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

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

Pull request for efi-2022-04-rc3

Documentation:

* add man-page for fatload
* add SMBIOS table page

UEFI:

* partial fix for UEFI secure boot with intermediate certs
* disable watchdog when returning to command line
* reset system after capsule update

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

- rzg2_beacon updates

efi_loader: update the timing of enabling and disabling EFI watchdog

UEFI specification requires that 5 minutes watchdog timer is
armed before the firmware's boot manager invokes an EFI boot option.
This watchdog timer is updated as follows, according to the
UEFI specification.

 1) The EFI Image may reset or disable the watchdog timer as needed.
 2) If control is returned to the firmware's boot manager,
    the watchdog timer must be disabled.
 3) On successful completion of EFI_BOOT_SERVICES.ExitBootServices()
    the watchdog timer is disabled.

1) is up to the EFI image, and 3) is already implemented in U-Boot.
This patch implements 2), the watchdog is disabled when control is
returned to U-Boot.

In addition, current implementation arms the EFI watchdog at only
the first "bootefi" invocation. The EFI watchdog must be armed
in every EFI boot option invocation.

Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

efi_loader: test/py: Reset system after capsule update on disk

Add a cold reset soon after processing capsule update on disk.
This is required in UEFI specification 2.9 Section 8.5.5
"Delivery of Capsules via file on Mass Storage device" as;

    In all cases that a capsule is identified for processing the system is
    restarted after capsule processing is completed.

This also reports the result of each capsule update so that the user can
notice that the capsule update has been succeeded or not from console log.

Signed-off-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

test/py: Handle expected reboot while booting sandbox

Add expected_reset optional argument to ConsoleBase::ensure_spawned(),
ConsoleBase::restart_uboot() and ConsoleSandbox::restart_uboot_with_flags()
so that it can handle a reset while the 1st boot process after main
boot logo before prompt correctly.

Signed-off-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

test/py: Handle expected reset by command

Add wait_for_reboot optional argument to ConsoleBase::run_command()
so that it can handle an expected reset by command execution.

This is useful if a command will reset the sandbox while testing
such commands, e.g. run_command("reset", wait_for_reboot = True)

Signed-off-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

efi_loader: use efi_update_capsule_firmware() for capsule on disk

Since the efi_update_capsule() represents the UpdateCapsule() runtime
service, it has to handle the capsule flags and update ESRT. However
the capsule-on-disk doesn't need to care about such things.

Thus, the capsule-on-disk should use the efi_capsule_update_firmware()
directly instead of calling efi_update_capsule().

This means the roles of the efi_update_capsule() and capsule-on-disk
are different. We have to keep the efi_update_capsule() for providing
runtime service API at boot time.

Suggested-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Signed-off-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: fix uefi secure boot with intermediate certs

The general rule of accepting or rejecting an image is
 1. Is the sha256 of the image in dbx
 2. Is the image signed with a certificate that's found in db and
    not in dbx
 3. The image carries a cert which is signed by a cert in db (and
    not in dbx) and the image can be verified against the former
 4. Is the sha256 of the image in db

For example SHIM is signed by "CN=Microsoft Windows UEFI Driver Publisher",
which is issued by "CN=Microsoft Corporation UEFI CA 2011", which in it's
turn is issued by "CN=Microsoft Corporation Third Party Marketplace Root".
The latter is a self-signed CA certificate and with our current implementation
allows shim to execute if we insert it in db.

However it's the CA cert in the middle of the chain which usually ends up
in the system's db.  pkcs7_verify_one() might or might not return the root
certificate for a given chain.  But when verifying executables in UEFI,  the
trust anchor can be in the middle of the chain, as long as that certificate
is present in db.  Currently we only allow this check on self-signed
certificates,  so let's remove that check and allow all certs to try a
match an entry in db.

Open questions:
- Does this break any aspect of variable authentication since
  efi_signature_verify() is used on those as well?

Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

tools: mkeficapsule: remove duplicated code

That code is mistakenly duplicated due to copy-and-paste error.
Just remove it.

Fixes: CID 348360
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

doc: describe fatload command

Man-page for fatload command.

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

doc: describe generation of SMBIOS table

SMBIOS is not x86 specific. So we should have an architecture independent
page describing it.

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