The files arch/arm/lib/*_efi.* are only relevant for the UEFI sub-system.

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

William Zhang authored 2 years ago and Tom Rini committed 2 years ago

STI timer is actually ARM Cortex A9 global timer. Convert the driver to
use generic global timer name and make it consistent with Linux kernel
global timer driver. This also allows any A9 based device to use this
driver.

Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Tested-by: Patrice Chotard <patrice.chotard@foss.st.com>

William Zhang authored 2 years ago and Tom Rini committed 2 years ago

BCM6855 is a Broadcom ARM A7 based PON Gateway SoC. It is part of the
BCA (Broadband Carrier Access origin) chipset family. Like other
broadband SoC, this patch adds it under CONFIG_BCM6855 chip config and
CONFIG_ARCH_BCMBCA platform config.

This initial support includes a bare-bone implementation and dts with
CPU subsystem, memory and ARM PL101 uart. This SoC is supported in the
linux-next git repository so the dts and dtsi files are copied from linux.

The u-boot image can be loaded from flash or network to the entry point
address in the memory and boot from there to the console.

Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Philippe Reynes <philippe.reynes@softathome.com>

William Zhang authored 2 years ago and Tom Rini committed 2 years ago

BCM6858 is a Broadcom B53 based PON Gateway SoC. It is part of the BCA
(Broadband Carrier Access origin) chipset family. Like other broadband
SoC, this patch adds it under CONFIG_BCM6858 chip config and
CONFIG_ARCH_BCMBCA platform config.

This initial support includes a bare-bone implementation and the
original dts is updated with the one from linux next git repository.

The u-boot image can be loaded from flash or network to the entry point
address in the memory and boot from there to the console.

Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Philippe Reynes <philippe.reynes@softathome.com>

William Zhang authored 2 years ago and Tom Rini committed 2 years ago

BCM6856 is a Broadcom B53 based PON Gateway SoC. It is part of the BCA
(Broadband Carrier Access origin) chipset family. Like other Broadband
SoC, this patch adds it under CONFIG_BCM6856 chip config and
CONFIG_ARCH_BCMBCA platform config.

This initial support includes a bare-bone implementation and dts with
CPU subsystem, memory and Broadcom uart. This SoC is supported in the
linux-next git repository so the dts and dtsi files are copied from
linux.

The u-boot image can be loaded from flash or network to the entry point
address in the memory and boot from there to the console.

Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Philippe Reynes <philippe.reynes@softathome.com>

William Zhang authored 2 years ago and Tom Rini committed 2 years ago

Since ARCH_BCM63158 SoC support is merged into ARCH_BCMBCA, add BCM63158
maintainer Philippe to bcmbca maintainer list.

Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Philippe Reynes <philippe.reynes@softathome.com>

William Zhang authored 2 years ago and Tom Rini committed 2 years ago

BCM63158 is a Broadcom B53 based DSL Gateway SoC. It is part of the
BCA (Broadband Carrier Access origin) chipset family. Like other
Broadband SoC, this patch adds it under CONFIG_BCM63158 chip
config and CONFIG_ARCH_BCMBCA platform config.

This initial support includes a bare-bone implementation and dts with
CPU subsystem, memory and ARM PL011 uart. This SoC is supported in the
linux-next git repository so the dts and dtsi files are copied from
linux.

The u-boot image can be loaded from flash or network to the entry
point address in the memory and boot from there to the console.

Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Philippe Reynes <philippe.reynes@softathome.com>

William Zhang authored 2 years ago and Tom Rini committed 2 years ago

BCM4908 is a Broadcom B53 based WLAN AP router SoC. It is part of the
BCA (Broadband Carrier Access origin) chipset family so it's added
under ARCH_BCMBCA platform. This initial support includes a bare-bone
implementation and dts with CPU subsystem, memory and Broadcom uart.

This SoC is supported in the linux git repository so the dts and dtsi
files are stripped down version of linux copies with mininum blocks
needed by u-boot.

The u-boot image can be loaded from flash or network to the entry point
address in the memory and boot from there to the console.

Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>

William Zhang authored 2 years ago and Tom Rini committed 2 years ago

BCM6813 is a Broadcom B53 based PON and WLAN AP router SoC. It is part
of the BCA (Broadband Carrier Access origin) chipset family so it's
added under ARCH_BCMBCA platform. This initial support includes a
bare-bone implementation and dts with CPU subsystem, memory and ARM
PL011 uart.

This SoC is supported in the linux-next git repository so the dts and
dtsi files are copied from linux.

The u-boot image can be loaded from flash or network to the entry point
address in the memory and boot from there to the console.

Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>

William Zhang authored 2 years ago and Tom Rini committed 2 years ago

BCM4912 is a Broadcom B53 based WLAN AP router SoC. It is part of the
BCA (Broadband Carrier Access origin) chipset family so it's added under
ARCH_BCMBCA platform. This initial support includes a bare-bone
implementation and dts with CPU subsystem, memory and ARM PL011 uart.

This SoC is supported in the linux-next git repository so the dts
and dtsi files are copied from linux.

The u-boot image can be loaded from flash or network to the entry
point address in the memory and boot from there to the console.

Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>

William Zhang authored 2 years ago and Tom Rini committed 2 years ago

BCM63146 is a Broadcom B53 based DSL Broadband SoC. It is part of the
BCA (Broadband Carrier Access origin) chipset family so it's added under
ARCH_BCMBCA platform. This initial support includes a bare-bone
implementation and dts with CPU subsystem, memory and ARM PL011 uart.

This SoC is supported in the linux-next git repository so the dts and
dtsi files are copied from linux.

The u-boot image can be loaded from flash or network to the entry point
address in the memory and boot from there to the console.

Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>

William Zhang authored 2 years ago and Tom Rini committed 2 years ago

BCM63138 is an ARM A9 based DSL Broadband SoC. It is part of the BCA
(Broadband Carrier Access origin) chipset family so it's added under
ARCH_BCMBCA platform. This initial support includes a bare-bone
implementation and dts with CPU subsystem, memory, ARM A9 global timer
and Broadcom uart.

This SoC is supported in the linux-next git repository so the dts and
dtsi files are stripped down version of linux copies with mininum blocks
needed by u-boot.

The u-boot image can be loaded from flash or network to the entry point
address in the memory and boot from there to the console.

This patch applies on top of the my previous patch [1].

[1] https://lists.denx.de/pipermail/u-boot/2022-August/490570.html



Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Philippe Reynes <philippe.reynes@softathome.com>

William Zhang authored 2 years ago and Tom Rini committed 2 years ago

BCM63148 is an Broadcom B15 based DSL Broadband SoC. It is part of the
BCA (Broadband Carrier Access origin) chipset family so it's added under
ARCH_BCMBCA platform. This initial support includes a bare-bone
implementation and dts with CPU subsystem, memory and Broadcom uart.

This SoC is supported in the linux-next git repository so the dts and
dtsi files are copied from linux.

The u-boot image can be loaded from flash or network to the entry point
address in the memory and boot from there.

Signed-off-by: William Zhang <william.zhang@broadcom.com>

William Zhang authored 2 years ago and Tom Rini committed 2 years ago

BCM6756 is an ARM A7 based WLAN Gateway and Access Point Broadband SoC.
It is part of the BCA(Broadband Carrier Access origin) chipset family so
it's added under ARCH_BCMBCA platform. This initial support includes a
bare-bone implementation and dts with CPU subsystem, memory and ARM
PL011 uart.

This SoC is supported in the linux-next git repository so the dts and
dtsi files are copied from linux.

The u-boot image can be loaded from flash or network to the entry
point address in the memory and boot from there.

Signed-off-by: William Zhang <william.zhang@broadcom.com>

William Zhang authored 2 years ago and Tom Rini committed 2 years ago

BCM6878 is an ARM A7 based PON Broadband SoC. It is part of the BCA
(Broadband Carrier Access origin) chipset family so it's added under
ARCH_BCMBCA platform. This initial support includes a bare-bone
implementation and dts with CPU subsystem, memory and ARM PL011
uart.

This SoC is supported in the linux-next git repository so the dts and
dtsi files are copied from linux with minor fix-up that needs to be
upstreamed to linux as well.

The u-boot image can be loaded from flash or network to the entry point
address in the memory and boot from there.

Signed-off-by: William Zhang <william.zhang@broadcom.com>

William Zhang authored 2 years ago and Tom Rini committed 2 years ago

BCM6846 is an ARM A7 based PON Broadband SoC. It is part of the BCA
(Broadband Carrier Access origin) chipset family so it's added under
ARCH_BCMBCA platform. This initial support includes a bare-bone
implementation and dts with CPU subsystem, memory and Broadcom uart.

This SoC is supported in the linux-next git repository so the dts and
dtsi files are copied from linux with minor fix-up that needs to be
upstreamed to linux as well.

The u-boot image can be loaded from flash or network to the entry point
address in the memory and boot from there.

Signed-off-by: William Zhang <william.zhang@broadcom.com>

William Zhang authored 2 years ago and Tom Rini committed 2 years ago

BCM63178 is an ARM A7 based DSL Broadband SoC. It is part of the BCA
(Broadband Carrier Access origin) chipset family so it's added under
ARCH_BCMBCA platform. This initial support includes a bare-bone
implementation and dts with CPU subsystem, memory and ARM PL011 uart.

This SoC is supported in the linux-next git repository so the dts and
dtsi files are copied from linux with minor fix-up that needs to be
upstreamed to linux as well.

The u-boot image can be loaded from flash or network to the entry
point address in the memory and boot from there.

Signed-off-by: William Zhang <william.zhang@broadcom.com>

Simon Glass authored 2 years ago and Anatolij Gustschin committed 2 years ago

This code is no-longer used. Drop it.

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

Roger Knecht authored 2 years ago and Tom Rini committed 2 years ago

Add xxd command to print file content as hexdump to standard out

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Roger Knecht <rknecht@pm.me>

Roger Knecht authored 2 years ago and Tom Rini committed 2 years ago

Add cat command to print file content to standard out

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Roger Knecht <rknecht@pm.me>

Ilias Apalodimas authored 2 years ago and Heinrich Schuchardt committed 2 years ago

Since I am co-maintaining EFI with Heinrich remove the special
entry for EFI variable storage via OP-TEE

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

For future DM based FPGA drivers and for now to have a meaningful
logging class for old FPGA drivers.

Suggested-by: Michal Simek <michal.simek@amd.com>
Suggested-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Alexander Dahl <post@lespocky.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Link: https://lore.kernel.org/r/20220930120430.42307-2-post@lespocky.de


Signed-off-by: Michal Simek <michal.simek@amd.com>

Versal NET platform is based on Versal chip which is reusing a lot of IPs.
For more information about new IPs please take a look at DT which describe
currently supported devices.
The patch is adding architecture and board support with soc detection
algorithm. Generic setting should be very similar to Versal but it will
likely diverge in longer run.

Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/320206853dc370ce290a4e7b6d0bb26b05206021.1663589964.git.michal.simek@amd.com

Weijie Gao authored 2 years ago and Tom Rini committed 2 years ago

Add new files for MediaTek ARM platform

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>

Fabio Estevam authored 2 years ago and Stefano Babic committed 2 years ago

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>

Jayesh Choudhary authored 2 years ago and Tom Rini committed 2 years ago

Add j721s2 High Security EVM defconfig.

These configs are same as for the non-secure part, except for:
        CONFIG_TI_SECURE_DEVICE option set to 'y'
        CONFIG_FIT_IMAGE_POST_PROCESS option set to 'y'
        CONFIG_SPL_FIT_IMAGE_POST_PROCESS option set to 'y'
        CONFIG_BOOTCOMMAND uses FIT images for booting

Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>

Andrew Davis authored 2 years ago and Tom Rini committed 2 years ago

Add J7200 High Security EVM defconfig.

These defconfigs are the same as for the non-secure part, except for:
    CONFIG_TI_SECURE_DEVICE option set to 'y'
    CONFIG_BOOTCOMMAND uses FIT images for booting

Signed-off-by: Andrew Davis <afd@ti.com>
[j-choudhary@ti.com: add few configs from GP variant which were missing]
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>

Stefan Roese authored 2 years ago and Tom Rini committed 2 years ago

This patch adds the cyclic command, which currently only supports the
'list' subcommand, to list all currently registered cyclic functions.
Here an example:

=> cyclic list
function: cyclic_demo, cpu-time: 7010 us, frequency: 99.80 times/s
function: cyclic_demo2, cpu-time: 1 us, frequency: 1.13 times/s

As you can see, the cpu-time is accounted, so that cyclic functions
that take too long might be discovered. Additionally the frequency is
logged.

The 'cyclic demo' commands registers the cyclic_demo() function to
be executed all 'cycletime_ms' milliseconds. The only thing this
function does is delaying by 'delay_us' microseconds.

Signed-off-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>

Stefan Roese authored 2 years ago and Tom Rini committed 2 years ago

Add the basic infrastructure to periodically execute code, e.g. all
100ms. Examples for such functions might be LED blinking etc. The
functions that are hooked into this cyclic list should be small timewise
as otherwise the execution of the other code that relies on a high
frequent polling (e.g. UART rx char ready check) might be delayed too
much. This patch also adds the Kconfig option
CONFIG_CYCLIC_MAX_CPU_TIME_US, which configures the max allowed time
for such a cyclic function. If it's execution time exceeds this time,
this cyclic function will get removed from the cyclic list.

How is this cyclic functionality executed?
The following patch integrates the main function responsible for
calling all registered cyclic functions cyclic_run() into the
common WATCHDOG_RESET macro. This guarantees that cyclic_run() is
executed very often, which is necessary for the cyclic functions to
get scheduled and executed at their configured periods.

This cyclic infrastructure will be used by a board specific function on
the NIC23 MIPS Octeon board, which needs to check periodically, if a
PCIe FLR has occurred.

Signed-off-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>

Chin-Ting Kuo authored 2 years ago and Tom Rini committed 2 years ago

Add ASPEED BMC FMC/SPI memory controller driver with
spi-mem interface for AST2500 and AST2600 platform.

There are three SPI memory controllers embedded in an ASPEED SoC.
- FMC: Named as Firmware Memory Controller. After AC on, MCU ROM
       fetches initial device boot image from FMC chip select(CS) 0.

- SPI1: Play the role of a SPI Master controller. Or, there is a
        dedicated path for HOST(X86) to access its BIOS flash mounted
        under BMC. spi-aspeed-smc.c implements the control sequence when
        SPI1 is a SPI master.

- SPI2: It is a pure SPI flash controller. For most scenarios, flashes
        mounted under it are for pure storage purpose.

ASPEED SPI controller supports 1-1-1, 1-1-2 and 1-1-4 SPI flash mode.
Three types of command mode are supported, normal mode, command
read/write mode and user mode.
- Normal mode: Default mode. After power on, normal read command 03h or
               13h is used to fetch boot image from SPI flash.
               - AST2500: Only 03h command can be used after power on
                          or reset.
               - AST2600: If FMC04[6:4] is set, 13h command is used,
                          otherwise, 03h command.
               The address length is decided by FMC04[2:0].

- Command mode: SPI controller can send command and address
                automatically when CPU read/write the related remapped
                or decoded address area. The command used by this mode
                can be configured by FMC10/14/18[23:16]. Also, the
                address length is decided by FMC04[2:0]. This mode will
                be implemented in the following patch series.

- User mode: It is a traditional and pure SPI operation, where
             SPI transmission is controlled by CPU. It is the main
             mode in this patch.

Each SPI controller in ASPEED SoC has its own decoded address mapping.
Within each SPI controller decoded address, driver can assign a specific
address region for each CS of a SPI controller. The decoded address
cannot overlap to each other. With normal mode and command mode, the
decoded address accessed by the CPU determines which CS is active.
When user mode is adopted, the CS decoded address is a FIFO, CPU can
send/receive any SPI transmission by accessing the related decoded
address for the target CS.

This patch only implements user mode initially. Command read/write
mode will be implemented in the following patches.

Signed-off-by: Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>

Neil Armstrong authored 2 years ago and Tom Rini committed 2 years ago

My professional e-mail will change and the BayLibre one will
bounce after mid-september of 2022.

This updates the MAINTAINERS files and adds an entry in the
.mailmap file.

Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>

Gaurav Jain authored 2 years ago and Peng Fan committed 2 years ago

caam driver model enabled in spl for secure boot.
fsl_rsa_mod_exp driver enabled in spl for validating uboot image.

Signed-off-by: Gaurav Jain <gaurav.jain@nxp.com>

Joao Marcos Costa authored 2 years ago and Tom Rini committed 2 years ago

Replace former professional address by my personal e-mail.

Signed-off-by: Joao Marcos Costa <jmcosta944@gmail.com>

Marek Behún authored 2 years ago and Tom Rini committed 2 years ago

After a discussion with Tom Rini, we've agreed that I am going to take
over custodianship of the MPC85XX platform, since it seems other people
do not have necessary interest or time and getting things done over
there takes too long.

Since I am only working on one MPC85XX board, Turris 1.x, and do not
have time to do thorough reviews of patches for this entire platform
(other than those concerning Turris 1.x board), for other boards I will
only run patches through CI and checkpatch, and then send them via PR
upwards to Tom.

Signed-off-by: Marek Behún <kabel@kernel.org>
Acked-by: Tom Rini <trini@konsulko.com>

Martyn Welch authored 2 years ago and Stefano Babic committed 2 years ago

The MAINTAINERS file currently lists files in
arch/arm/include/asm/arch-imx/ being part of the IMX maintainers
purview, however the arch/arm/include/asm/ directory also contains the
directories arch-imx8, arch-imx8m, arch-imx8ulp and arch-imxrt which
would also appear to be relevant to the team. Tweak the entry to cover
these directories so that tools like get_maintainers.pl will suggest
relevant maintainers when making changes just in these directories.

Signed-off-by: Martyn Welch <martyn.welch@collabora.com>

Andrew Davis authored 2 years ago and Tom Rini committed 2 years ago

On AM43xx HS devices, QSPI boot is XIP and we use a single stage
bootloader. Add a defconfig for this.

Signed-off-by: Andrew Davis <afd@ti.com>

Marek Behún authored 2 years ago and Stefan Roese committed 2 years ago

Fix diacritics in some instances of my name and change my e-mail address
to kabel@kernel.org.

Add corresponding .mailmap entries.

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

Marek Behún authored 2 years ago and Stefan Roese committed 2 years ago

Fix MAINTAINERS files for Turris devices, add missing files and add Pali
as maintainer.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

Robert Marko authored 2 years ago and Stefan Roese committed 2 years ago

I am currently maintaing the Methode uDPU and eDPU boards so add myself
as the maintainer for them.

Remove the old entry from board/Marvell/mvebu_armada-37xx/MAINTAINERS.

Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Reviewed-by: Stefan Roese <sr@denx.de>

Philippe Boos authored 2 years ago and Stefan Roese committed 2 years ago

Add support for hardware watchdog timer for Amlogic SoCs.
This driver has been heavily inspired by his Linux equivalent
(meson_gxbb_wdt.c).

Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>

Signed-off-by: Philippe Boos <pboos@baylibre.com>
Reviewed-by: Stefan Roese <sr@denx.de>