Merge tag 'xilinx-for-v2024.07-rc1' of https://source.denx.de/u-boot/custodians/u-boot-microblaze

Xilinx changes for v2024.07-rc1

xilinx:
- Do not call env_get_location when !ENV_IS_NOWHERE
- Add FDT_FIXUP_PARTITIONS support
- Fix legacy format MAC decoding

zynqmp:
- Enable semihosting SPL support
- DT updates
- Kconfig resort/cleanup
- Don't describe second image/capsule if !SPL
- Add support for dfu/capsule description via MTD
- Support JTAG as alternative boot mode
- Add support for TEG soc variant

zynqmp-kria:
- Wire usb4 boot device
- Update SDIO tristate pin configuration
- Disable SPI_FLASH_BAR to avoid issue with SPI after update

mbv:
- Enable SPL and binman
- Small platform changes

zynqmp-nand:
- Error out in case of unsupported SW ECC
- Clean error path

versal-net:
- Support multiple locations for variables

arm64: zynqmp: Do not setup default SPL options without SPL

mach Kconfig file select some options independently of if SPL is actually
enabled. It ends up in situation that SPL is disabled but symbols are still
present in .config. That's why add SPL dependency for them but also group
them with other SPL options in ARCH_ZYNQMP fragment with using imply
option. This should ensure the same behavior as default y.

Also fixed SPL_ZYNQMP_PSU_INIT_ENABLED for the same.

Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/8dc4b799d36f963a3e1ebb5b24793632dc360b61.1710258674.git.michal.simek@amd.com

Kconfig: Centralize prompting for SYS_CONFIG_NAME

Generally speaking, we do not prompt for this value and define it in the
board specific Kconfig file. There are some valid use cases however
today where we do prompt for this value, so instead of having this be
done in a number of locations, do this at the top-level location only.

This removes the question from a number of other locations and makes it
consistent that when we do set the value directly, we always do it the
same way. We don't need to specify the type, it's always string.

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

arm64: zynqmp: Fix Kconfig entry indentation

Use tabs instead of space for entry indentation which is standard coding
style.

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

zynqmp: config: Add proper dependencies for USB

When CONFIG_CMD_USB and CONFIG_USB are disabled, still some compilation
errors are seen as below.

In file included from include/configs/xilinx_zynqmp.h:173,
from include/config.h:3,
from include/common.h:16,
from env/common.c:10:
include/config_distro_bootcmd.h:302:9: error: expected '}' before 'BOOT_TARGET_DEVICES_references_USB_without_CONFIG_CMD_USB'
302 | BOOT_TARGET_DEVICES_references_USB_without_CONFIG_CMD_USB
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/config_distro_bootcmd.h:302:9: note: in definition of macro
'BOOTENV_DEV_NAME_USB'
302 | BOOT_TARGET_DEVICES_references_USB_without_CONFIG_CMD_USB
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/configs/xilinx_zynqmp.h:77:41: note: in expansion of macro
'BOOTENV_DEV_NAME'
77 | # define BOOT_TARGET_DEVICES_USB(func) func(USB, usb, 0)
func(USB, usb, 1)
| ^~~~
include/configs/xilinx_zynqmp.h:168:9: note: in expansion of macro
'BOOT_TARGET_DEVICES_USB'
168 | BOOT_TARGET_DEVICES_USB(func) \
| ^~~~~~~~~~~~~~~~~~~~~~~
include/config_distro_bootcmd.h:454:25: note: in expansion of macro
'BOOT_TARGET_DEVICES'
454 | "boot_targets=" BOOT_TARGET_DEVICES(BOOTENV_DEV_NAME) "\0"
| ^~~~~~~~~~~~~~~~~~~
include/config_distro_bootcmd.h:474:9: note: in expansion of macro
'BOOTENV_BOOT_TARGETS'
474 | BOOTENV_BOOT_TARGETS \
| ^~~~~~~~~~~~~~~~~~~~
include/configs/xilinx_zynqmp.h:179:9: note: in expansion of macro
'BOOTENV'
179 | BOOTENV
| ^~~~~~~
include/env_default.h:120:9: note: in expansion of macro
'CFG_EXTRA_ENV_SETTINGS'
120 | CFG_EXTRA_ENV_SETTINGS
| ^~~~~~~~~~~~~~~~~~~~~~
In file included from env/common.c:32:
include/env_default.h:27:36: note: to match this '{'
27 | const char default_environment[] = {
| ^
scripts/Makefile.build:256: recipe for target 'env/common.o' failed
make[1]: *** [env/common.o] Error 1
Makefile:1853: recipe for target 'env' failed
make: *** [env] Error 2
make: *** Waiting for unfinished jobs....

Add CONFIG_USB_STORAGE as dependency for USB related macro's such as
BOOT_TARGET_DEVICES_USB() and DFU_DEFAULT_POLL_TIMEOUT and
CONFIG_THOR_RESET_OFF.

Remove CONFIG_ZYNQMP_USB from Kconfig and also from defconfig since it
is not used anywhere else.

Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@amd.com>
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Link: https://lore.kernel.org/r/20230904031528.11817-3-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>

arm64: zynqmp: Do not include psu_init to U-Boot by default

The commit ed35de617013 ("Convert CONFIG_ZYNQMP_PSU_INIT_ENABLED to
Kconfig") converted CONFIG_ZYNQMP_PSU_INIT_ENABLED symbol and enabled it by
default which is not correct configuration.
Intention of this config was to have it enabled by default for SPL and
provide an option to users to also do low level initialization directly
from U-Boot.
That's why it is necessary to define second symbol with SPL marking in it
and properly use symbols depends on usage in Makefile.
Also disable ZYNQMP_PSU_INIT_ENABLED from boards which enables it by
default. CONFIG_SPL_ZYNQMP_PSU_INIT_ENABLED is enabled by default when SPL
is enabled.

Reported-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Reviewed-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/d5fcbd66b05bf0d7ef594e66464ee23b48c5e4cc.1669969083.git.michal.simek@amd.com

arm64: zynqmp: Fix dependencies around ZYNQMP_PSU_INIT_ENABLED

ZYNQMP_PSU_INIT_ENABLED is called only when BOARD_EARLY_INIT_F is defined
that's why cover this dependency in Kconfig.
board_early_init_f() is only part related to
CONFIG_ZYNQMP_PSU_INIT_ENABLED which is disabled now that's why disable
BOARD_EARLY_INIT_F and also build board_early_init_f() only when
CONFIG_BOARD_EARLY_INIT_F is enabled.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Link: https://lore.kernel.org/r/d89253ec1590cd513dcd4bfbedebae618bd6d605.1645104518.git.michal.simek@xilinx.com

arm64: zynqmp: allow overriding board name

There is no need to use zynqmp name as SYS_BOARD for all boards.
The patch is adding an option to change it.

Signed-off-by: Liam Beguin <liambeguin@gmail.com>
Link: https://lore.kernel.org/r/20211020152518.3511912-1-liambeguin@gmail.com
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

zynqmp: restore the jtag interface

When boot.bin is configured for secure boot the CSU will disable the
JTAG interface on all cases.

Some boards might rely on this interface for flashing to QSPI in which
case those systems might end up bricked during development.

This commit will restore the interface under CSU control

Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Link: https://lore.kernel.org/r/20211013134800.19452-1-jorge@foundries.io
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

spi: Rename SPI_SUPPORT to SPI

Rename these options so that CONFIG_IS_ENABLED can be used with them.

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

serial: Rename SERIAL_SUPPORT to SERIAL

Rename these options so that CONFIG_IS_ENABLED can be used with them.

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

mmc: Rename MMC_SUPPORT to MMC

Rename these options so that CONFIG_IS_ENABLED can be used with them.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
[trini: Fixup some incorrect renames]
Signed-off-by: Tom Rini <trini@konsulko.com>

zynqmp: spl: support DRAM ECC initialization

Use the ZDMA channel 0 to initialize the DRAM banks. This avoid
spurious ECC errors that can occur when accessing unitialized memory.

The feature is enabled by setting the option
CONFIG_SPL_ZYNQMP_DRAM_ECC_INIT and providing the following data:

SPL_ZYNQMP_DRAM_BANK1_BASE: start of memory to initialize
SPL_ZYNQMP_DRAM_BANK1_LEN : len of memory to initialize (hex)
SPL_ZYNQMP_DRAM_BANK2_BASE: start of memory to initialize
SPL_ZYNQMP_DRAM_BANK2_LEN : len of memory to initialize (hex)

Setting SPL_ZYNQMP_DRAM_BANK_LEN to 0 takes no action.

Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

xilinx: kconfig: Move sourcing of board Kconfig to mach folders

Do not source xilinx board Kconfig by other boards. These configs should be
available only when Xilinx platforms are selected.

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

arm64: zynqmp: Add board_boot_order for MMC boot extension

In past SPL_ZYNQMP_TWO_SDHCI symbol was introduced to handle boards with
two sdhci controllers. The problem was that U-Boot is registering
controllers based on aliases in DT but bootmode targets specific controller
ID. That's why on boards with one "second" sdhci controller bootmode was
pointing to second controller(MMC2) but alias was setup to mmc0 (the first
controller). And SPL requires to point to mmc0 in this case.

Long time ago commit f101e4bd3703
("spl: add support for alternative boot device") added support for handling
multiple bootmodes in SPL. Use this functionality and setup second sdhci
controller as backup boot device.

Below is table with behavior:
HW/bootmode bootorder
sd0/sd0 mmc0/mmc1 (mmc1 never called)
sd1/sd1 mmc1/mmc0 (mmc0 fails and mmc1 is called)
sd0+sd1/sd0 mmc0/mmc1 (mmc1 never called)
sd0+sd1/sd1 mmc1/mmc0 (mmc0 never called)

All other bootmodes are not affected but order can be extended to cover
advance boot flows.

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

arm64: zynqmp: spl: install a PMU firmware config object at runtime

Optionally allow U-Boot to load a configuration object into the Power
Management Unit (PMU) firmware on Xilinx ZynqMP.

The configuration object is required by the PMU FW to enable most SoC
peripherals. So far the only way to boot using U-Boot SPL was to hard-code
the configuration object in the PMU firmware. Allow a different boot
process, where the PMU FW is equal for any ZynqMP chip and its
configuration is passed at runtime by U-Boot SPL.

All the code for Inter-processor communication with the PMU is isolated in
a new file (pmu_ipc.c). The code is inspired by the same feature as
implemented in the Xilinx First Stage Bootloader (FSBL) and Arm Trusted
Firmware:

* https://github.com/Xilinx/embeddedsw/blob/fb647e6b4c00f5154eba52a88b948195b6f1dc2b/lib/sw_apps/zynqmp_fsbl/src/xfsbl_misc_drivers.c#L295
* https://github.com/ARM-software/arm-trusted-firmware/blob/c48d02bade88b07fa7f43aa44e5217f68e5d047f/plat/xilinx/zynqmp/pm_service/pm_api_sys.c#L357

SPL logs on the console before loading the configuration object:

U-Boot SPL 2019.07-rc1-00511-gaec224515c87 (May 15 2019 - 08:43:41 +0200)
Loading PMUFW cfg obj (2008 bytes)
EL Level: EL3
...

Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

arm64: zynqmp: Fix logic around CONFIG_ZYNQ_SDHCI

Replace SDHCI controller listing by Kconfig symbol to let SPL know that
this board is using multiple SDHCIs controllers.
Kconfig help message should explain why this is needed.
Origin symbols were used in full u-boot but with moving to distro boot
this was fixed already.

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

spl: Kconfig: Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT

Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT so
obj-$(CONFIG_$(SPL_)FS_FAT) can be used to control the build in both
SPL and U-Boot.

Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

arm64: zynqmp: Move SoC sources to mach-zynqmp

Similar changes was done for Zynq in past and this patch just follow
this pattern to separate cpu code from SoC code.

Move arch/arm/cpu/armv8/zynqmp/* -> arch/arm/mach-zynqmp/*
And also fix references to these files.

Based on
"ARM: zynq: move SoC sources to mach-zynq"
(sha1: 0107f2403669f764ab726d0d404e35bb9447bbcc)

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

Kconfig: Centralize prompting for SYS_CONFIG_NAME

Generally speaking, we do not prompt for this value and define it in the
board specific Kconfig file. There are some valid use cases however
today where we do prompt for this value, so instead of having this be
done in a number of locations, do this at the top-level location only.

This removes the question from a number of other locations and makes it
consistent that when we do set the value directly, we always do it the
same way. We don't need to specify the type, it's always string.

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

arm64: zynqmp: Fix Kconfig entry indentation

Use tabs instead of space for entry indentation which is standard coding
style.

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

zynqmp: config: Add proper dependencies for USB

When CONFIG_CMD_USB and CONFIG_USB are disabled, still some compilation
errors are seen as below.

In file included from include/configs/xilinx_zynqmp.h:173,
from include/config.h:3,
from include/common.h:16,
from env/common.c:10:
include/config_distro_bootcmd.h:302:9: error: expected '}' before 'BOOT_TARGET_DEVICES_references_USB_without_CONFIG_CMD_USB'
302 | BOOT_TARGET_DEVICES_references_USB_without_CONFIG_CMD_USB
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/config_distro_bootcmd.h:302:9: note: in definition of macro
'BOOTENV_DEV_NAME_USB'
302 | BOOT_TARGET_DEVICES_references_USB_without_CONFIG_CMD_USB
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/configs/xilinx_zynqmp.h:77:41: note: in expansion of macro
'BOOTENV_DEV_NAME'
77 | # define BOOT_TARGET_DEVICES_USB(func) func(USB, usb, 0)
func(USB, usb, 1)
| ^~~~
include/configs/xilinx_zynqmp.h:168:9: note: in expansion of macro
'BOOT_TARGET_DEVICES_USB'
168 | BOOT_TARGET_DEVICES_USB(func) \
| ^~~~~~~~~~~~~~~~~~~~~~~
include/config_distro_bootcmd.h:454:25: note: in expansion of macro
'BOOT_TARGET_DEVICES'
454 | "boot_targets=" BOOT_TARGET_DEVICES(BOOTENV_DEV_NAME) "\0"
| ^~~~~~~~~~~~~~~~~~~
include/config_distro_bootcmd.h:474:9: note: in expansion of macro
'BOOTENV_BOOT_TARGETS'
474 | BOOTENV_BOOT_TARGETS \
| ^~~~~~~~~~~~~~~~~~~~
include/configs/xilinx_zynqmp.h:179:9: note: in expansion of macro
'BOOTENV'
179 | BOOTENV
| ^~~~~~~
include/env_default.h:120:9: note: in expansion of macro
'CFG_EXTRA_ENV_SETTINGS'
120 | CFG_EXTRA_ENV_SETTINGS
| ^~~~~~~~~~~~~~~~~~~~~~
In file included from env/common.c:32:
include/env_default.h:27:36: note: to match this '{'
27 | const char default_environment[] = {
| ^
scripts/Makefile.build:256: recipe for target 'env/common.o' failed
make[1]: *** [env/common.o] Error 1
Makefile:1853: recipe for target 'env' failed
make: *** [env] Error 2
make: *** Waiting for unfinished jobs....

Add CONFIG_USB_STORAGE as dependency for USB related macro's such as
BOOT_TARGET_DEVICES_USB() and DFU_DEFAULT_POLL_TIMEOUT and
CONFIG_THOR_RESET_OFF.

Remove CONFIG_ZYNQMP_USB from Kconfig and also from defconfig since it
is not used anywhere else.

Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@amd.com>
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Link: https://lore.kernel.org/r/20230904031528.11817-3-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>

arm64: zynqmp: Do not include psu_init to U-Boot by default

The commit ed35de617013 ("Convert CONFIG_ZYNQMP_PSU_INIT_ENABLED to
Kconfig") converted CONFIG_ZYNQMP_PSU_INIT_ENABLED symbol and enabled it by
default which is not correct configuration.
Intention of this config was to have it enabled by default for SPL and
provide an option to users to also do low level initialization directly
from U-Boot.
That's why it is necessary to define second symbol with SPL marking in it
and properly use symbols depends on usage in Makefile.
Also disable ZYNQMP_PSU_INIT_ENABLED from boards which enables it by
default. CONFIG_SPL_ZYNQMP_PSU_INIT_ENABLED is enabled by default when SPL
is enabled.

Reported-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Reviewed-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/d5fcbd66b05bf0d7ef594e66464ee23b48c5e4cc.1669969083.git.michal.simek@amd.com

arm64: zynqmp: Fix dependencies around ZYNQMP_PSU_INIT_ENABLED

ZYNQMP_PSU_INIT_ENABLED is called only when BOARD_EARLY_INIT_F is defined
that's why cover this dependency in Kconfig.
board_early_init_f() is only part related to
CONFIG_ZYNQMP_PSU_INIT_ENABLED which is disabled now that's why disable
BOARD_EARLY_INIT_F and also build board_early_init_f() only when
CONFIG_BOARD_EARLY_INIT_F is enabled.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Link: https://lore.kernel.org/r/d89253ec1590cd513dcd4bfbedebae618bd6d605.1645104518.git.michal.simek@xilinx.com

arm64: zynqmp: allow overriding board name

There is no need to use zynqmp name as SYS_BOARD for all boards.
The patch is adding an option to change it.

Signed-off-by: Liam Beguin <liambeguin@gmail.com>
Link: https://lore.kernel.org/r/20211020152518.3511912-1-liambeguin@gmail.com
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

zynqmp: restore the jtag interface

When boot.bin is configured for secure boot the CSU will disable the
JTAG interface on all cases.

Some boards might rely on this interface for flashing to QSPI in which
case those systems might end up bricked during development.

This commit will restore the interface under CSU control

Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Link: https://lore.kernel.org/r/20211013134800.19452-1-jorge@foundries.io
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

spi: Rename SPI_SUPPORT to SPI

Rename these options so that CONFIG_IS_ENABLED can be used with them.

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

serial: Rename SERIAL_SUPPORT to SERIAL

Rename these options so that CONFIG_IS_ENABLED can be used with them.

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

mmc: Rename MMC_SUPPORT to MMC

Rename these options so that CONFIG_IS_ENABLED can be used with them.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
[trini: Fixup some incorrect renames]
Signed-off-by: Tom Rini <trini@konsulko.com>

zynqmp: spl: support DRAM ECC initialization

Use the ZDMA channel 0 to initialize the DRAM banks. This avoid
spurious ECC errors that can occur when accessing unitialized memory.

The feature is enabled by setting the option
CONFIG_SPL_ZYNQMP_DRAM_ECC_INIT and providing the following data:

SPL_ZYNQMP_DRAM_BANK1_BASE: start of memory to initialize
SPL_ZYNQMP_DRAM_BANK1_LEN : len of memory to initialize (hex)
SPL_ZYNQMP_DRAM_BANK2_BASE: start of memory to initialize
SPL_ZYNQMP_DRAM_BANK2_LEN : len of memory to initialize (hex)

Setting SPL_ZYNQMP_DRAM_BANK_LEN to 0 takes no action.

Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

xilinx: kconfig: Move sourcing of board Kconfig to mach folders

Do not source xilinx board Kconfig by other boards. These configs should be
available only when Xilinx platforms are selected.

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

arm64: zynqmp: Add board_boot_order for MMC boot extension

In past SPL_ZYNQMP_TWO_SDHCI symbol was introduced to handle boards with
two sdhci controllers. The problem was that U-Boot is registering
controllers based on aliases in DT but bootmode targets specific controller
ID. That's why on boards with one "second" sdhci controller bootmode was
pointing to second controller(MMC2) but alias was setup to mmc0 (the first
controller). And SPL requires to point to mmc0 in this case.

Long time ago commit f101e4bd3703
("spl: add support for alternative boot device") added support for handling
multiple bootmodes in SPL. Use this functionality and setup second sdhci
controller as backup boot device.

Below is table with behavior:
HW/bootmode bootorder
sd0/sd0 mmc0/mmc1 (mmc1 never called)
sd1/sd1 mmc1/mmc0 (mmc0 fails and mmc1 is called)
sd0+sd1/sd0 mmc0/mmc1 (mmc1 never called)
sd0+sd1/sd1 mmc1/mmc0 (mmc0 never called)

All other bootmodes are not affected but order can be extended to cover
advance boot flows.

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

arm64: zynqmp: spl: install a PMU firmware config object at runtime

Optionally allow U-Boot to load a configuration object into the Power
Management Unit (PMU) firmware on Xilinx ZynqMP.

The configuration object is required by the PMU FW to enable most SoC
peripherals. So far the only way to boot using U-Boot SPL was to hard-code
the configuration object in the PMU firmware. Allow a different boot
process, where the PMU FW is equal for any ZynqMP chip and its
configuration is passed at runtime by U-Boot SPL.

All the code for Inter-processor communication with the PMU is isolated in
a new file (pmu_ipc.c). The code is inspired by the same feature as
implemented in the Xilinx First Stage Bootloader (FSBL) and Arm Trusted
Firmware:

* https://github.com/Xilinx/embeddedsw/blob/fb647e6b4c00f5154eba52a88b948195b6f1dc2b/lib/sw_apps/zynqmp_fsbl/src/xfsbl_misc_drivers.c#L295
* https://github.com/ARM-software/arm-trusted-firmware/blob/c48d02bade88b07fa7f43aa44e5217f68e5d047f/plat/xilinx/zynqmp/pm_service/pm_api_sys.c#L357

SPL logs on the console before loading the configuration object:

U-Boot SPL 2019.07-rc1-00511-gaec224515c87 (May 15 2019 - 08:43:41 +0200)
Loading PMUFW cfg obj (2008 bytes)
EL Level: EL3
...

Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

arm64: zynqmp: Fix logic around CONFIG_ZYNQ_SDHCI

Replace SDHCI controller listing by Kconfig symbol to let SPL know that
this board is using multiple SDHCIs controllers.
Kconfig help message should explain why this is needed.
Origin symbols were used in full u-boot but with moving to distro boot
this was fixed already.

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

spl: Kconfig: Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT

Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT so
obj-$(CONFIG_$(SPL_)FS_FAT) can be used to control the build in both
SPL and U-Boot.

Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

arm64: zynqmp: Move SoC sources to mach-zynqmp

Similar changes was done for Zynq in past and this patch just follow
this pattern to separate cpu code from SoC code.

Move arch/arm/cpu/armv8/zynqmp/* -> arch/arm/mach-zynqmp/*
And also fix references to these files.

Based on
"ARM: zynq: move SoC sources to mach-zynq"
(sha1: 0107f2403669f764ab726d0d404e35bb9447bbcc)

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

arm64: zynqmp: Fix Kconfig entry indentation

Use tabs instead of space for entry indentation which is standard coding
style.

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

zynqmp: config: Add proper dependencies for USB

When CONFIG_CMD_USB and CONFIG_USB are disabled, still some compilation
errors are seen as below.

In file included from include/configs/xilinx_zynqmp.h:173,
from include/config.h:3,
from include/common.h:16,
from env/common.c:10:
include/config_distro_bootcmd.h:302:9: error: expected '}' before 'BOOT_TARGET_DEVICES_references_USB_without_CONFIG_CMD_USB'
302 | BOOT_TARGET_DEVICES_references_USB_without_CONFIG_CMD_USB
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/config_distro_bootcmd.h:302:9: note: in definition of macro
'BOOTENV_DEV_NAME_USB'
302 | BOOT_TARGET_DEVICES_references_USB_without_CONFIG_CMD_USB
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/configs/xilinx_zynqmp.h:77:41: note: in expansion of macro
'BOOTENV_DEV_NAME'
77 | # define BOOT_TARGET_DEVICES_USB(func) func(USB, usb, 0)
func(USB, usb, 1)
| ^~~~
include/configs/xilinx_zynqmp.h:168:9: note: in expansion of macro
'BOOT_TARGET_DEVICES_USB'
168 | BOOT_TARGET_DEVICES_USB(func) \
| ^~~~~~~~~~~~~~~~~~~~~~~
include/config_distro_bootcmd.h:454:25: note: in expansion of macro
'BOOT_TARGET_DEVICES'
454 | "boot_targets=" BOOT_TARGET_DEVICES(BOOTENV_DEV_NAME) "\0"
| ^~~~~~~~~~~~~~~~~~~
include/config_distro_bootcmd.h:474:9: note: in expansion of macro
'BOOTENV_BOOT_TARGETS'
474 | BOOTENV_BOOT_TARGETS \
| ^~~~~~~~~~~~~~~~~~~~
include/configs/xilinx_zynqmp.h:179:9: note: in expansion of macro
'BOOTENV'
179 | BOOTENV
| ^~~~~~~
include/env_default.h:120:9: note: in expansion of macro
'CFG_EXTRA_ENV_SETTINGS'
120 | CFG_EXTRA_ENV_SETTINGS
| ^~~~~~~~~~~~~~~~~~~~~~
In file included from env/common.c:32:
include/env_default.h:27:36: note: to match this '{'
27 | const char default_environment[] = {
| ^
scripts/Makefile.build:256: recipe for target 'env/common.o' failed
make[1]: *** [env/common.o] Error 1
Makefile:1853: recipe for target 'env' failed
make: *** [env] Error 2
make: *** Waiting for unfinished jobs....

Add CONFIG_USB_STORAGE as dependency for USB related macro's such as
BOOT_TARGET_DEVICES_USB() and DFU_DEFAULT_POLL_TIMEOUT and
CONFIG_THOR_RESET_OFF.

Remove CONFIG_ZYNQMP_USB from Kconfig and also from defconfig since it
is not used anywhere else.

Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@amd.com>
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Link: https://lore.kernel.org/r/20230904031528.11817-3-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>

arm64: zynqmp: Do not include psu_init to U-Boot by default

The commit ed35de617013 ("Convert CONFIG_ZYNQMP_PSU_INIT_ENABLED to
Kconfig") converted CONFIG_ZYNQMP_PSU_INIT_ENABLED symbol and enabled it by
default which is not correct configuration.
Intention of this config was to have it enabled by default for SPL and
provide an option to users to also do low level initialization directly
from U-Boot.
That's why it is necessary to define second symbol with SPL marking in it
and properly use symbols depends on usage in Makefile.
Also disable ZYNQMP_PSU_INIT_ENABLED from boards which enables it by
default. CONFIG_SPL_ZYNQMP_PSU_INIT_ENABLED is enabled by default when SPL
is enabled.

Reported-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Reviewed-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/d5fcbd66b05bf0d7ef594e66464ee23b48c5e4cc.1669969083.git.michal.simek@amd.com

arm64: zynqmp: Fix dependencies around ZYNQMP_PSU_INIT_ENABLED

ZYNQMP_PSU_INIT_ENABLED is called only when BOARD_EARLY_INIT_F is defined
that's why cover this dependency in Kconfig.
board_early_init_f() is only part related to
CONFIG_ZYNQMP_PSU_INIT_ENABLED which is disabled now that's why disable
BOARD_EARLY_INIT_F and also build board_early_init_f() only when
CONFIG_BOARD_EARLY_INIT_F is enabled.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Link: https://lore.kernel.org/r/d89253ec1590cd513dcd4bfbedebae618bd6d605.1645104518.git.michal.simek@xilinx.com

arm64: zynqmp: allow overriding board name

There is no need to use zynqmp name as SYS_BOARD for all boards.
The patch is adding an option to change it.

Signed-off-by: Liam Beguin <liambeguin@gmail.com>
Link: https://lore.kernel.org/r/20211020152518.3511912-1-liambeguin@gmail.com
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

zynqmp: restore the jtag interface

When boot.bin is configured for secure boot the CSU will disable the
JTAG interface on all cases.

Some boards might rely on this interface for flashing to QSPI in which
case those systems might end up bricked during development.

This commit will restore the interface under CSU control

Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Link: https://lore.kernel.org/r/20211013134800.19452-1-jorge@foundries.io
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

spi: Rename SPI_SUPPORT to SPI

Rename these options so that CONFIG_IS_ENABLED can be used with them.

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

serial: Rename SERIAL_SUPPORT to SERIAL

Rename these options so that CONFIG_IS_ENABLED can be used with them.

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

mmc: Rename MMC_SUPPORT to MMC

Rename these options so that CONFIG_IS_ENABLED can be used with them.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
[trini: Fixup some incorrect renames]
Signed-off-by: Tom Rini <trini@konsulko.com>

zynqmp: spl: support DRAM ECC initialization

Use the ZDMA channel 0 to initialize the DRAM banks. This avoid
spurious ECC errors that can occur when accessing unitialized memory.

The feature is enabled by setting the option
CONFIG_SPL_ZYNQMP_DRAM_ECC_INIT and providing the following data:

SPL_ZYNQMP_DRAM_BANK1_BASE: start of memory to initialize
SPL_ZYNQMP_DRAM_BANK1_LEN : len of memory to initialize (hex)
SPL_ZYNQMP_DRAM_BANK2_BASE: start of memory to initialize
SPL_ZYNQMP_DRAM_BANK2_LEN : len of memory to initialize (hex)

Setting SPL_ZYNQMP_DRAM_BANK_LEN to 0 takes no action.

Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

xilinx: kconfig: Move sourcing of board Kconfig to mach folders

Do not source xilinx board Kconfig by other boards. These configs should be
available only when Xilinx platforms are selected.

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

arm64: zynqmp: Add board_boot_order for MMC boot extension

In past SPL_ZYNQMP_TWO_SDHCI symbol was introduced to handle boards with
two sdhci controllers. The problem was that U-Boot is registering
controllers based on aliases in DT but bootmode targets specific controller
ID. That's why on boards with one "second" sdhci controller bootmode was
pointing to second controller(MMC2) but alias was setup to mmc0 (the first
controller). And SPL requires to point to mmc0 in this case.

Long time ago commit f101e4bd3703
("spl: add support for alternative boot device") added support for handling
multiple bootmodes in SPL. Use this functionality and setup second sdhci
controller as backup boot device.

Below is table with behavior:
HW/bootmode bootorder
sd0/sd0 mmc0/mmc1 (mmc1 never called)
sd1/sd1 mmc1/mmc0 (mmc0 fails and mmc1 is called)
sd0+sd1/sd0 mmc0/mmc1 (mmc1 never called)
sd0+sd1/sd1 mmc1/mmc0 (mmc0 never called)

All other bootmodes are not affected but order can be extended to cover
advance boot flows.

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

arm64: zynqmp: spl: install a PMU firmware config object at runtime

Optionally allow U-Boot to load a configuration object into the Power
Management Unit (PMU) firmware on Xilinx ZynqMP.

The configuration object is required by the PMU FW to enable most SoC
peripherals. So far the only way to boot using U-Boot SPL was to hard-code
the configuration object in the PMU firmware. Allow a different boot
process, where the PMU FW is equal for any ZynqMP chip and its
configuration is passed at runtime by U-Boot SPL.

All the code for Inter-processor communication with the PMU is isolated in
a new file (pmu_ipc.c). The code is inspired by the same feature as
implemented in the Xilinx First Stage Bootloader (FSBL) and Arm Trusted
Firmware:

* https://github.com/Xilinx/embeddedsw/blob/fb647e6b4c00f5154eba52a88b948195b6f1dc2b/lib/sw_apps/zynqmp_fsbl/src/xfsbl_misc_drivers.c#L295
* https://github.com/ARM-software/arm-trusted-firmware/blob/c48d02bade88b07fa7f43aa44e5217f68e5d047f/plat/xilinx/zynqmp/pm_service/pm_api_sys.c#L357

SPL logs on the console before loading the configuration object:

U-Boot SPL 2019.07-rc1-00511-gaec224515c87 (May 15 2019 - 08:43:41 +0200)
Loading PMUFW cfg obj (2008 bytes)
EL Level: EL3
...

Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

arm64: zynqmp: Fix logic around CONFIG_ZYNQ_SDHCI

Replace SDHCI controller listing by Kconfig symbol to let SPL know that
this board is using multiple SDHCIs controllers.
Kconfig help message should explain why this is needed.
Origin symbols were used in full u-boot but with moving to distro boot
this was fixed already.

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

spl: Kconfig: Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT

Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT so
obj-$(CONFIG_$(SPL_)FS_FAT) can be used to control the build in both
SPL and U-Boot.

Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

arm64: zynqmp: Move SoC sources to mach-zynqmp

Similar changes was done for Zynq in past and this patch just follow
this pattern to separate cpu code from SoC code.

Move arch/arm/cpu/armv8/zynqmp/* -> arch/arm/mach-zynqmp/*
And also fix references to these files.

Based on
"ARM: zynq: move SoC sources to mach-zynq"
(sha1: 0107f2403669f764ab726d0d404e35bb9447bbcc)

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

zynqmp: config: Add proper dependencies for USB

When CONFIG_CMD_USB and CONFIG_USB are disabled, still some compilation
errors are seen as below.

In file included from include/configs/xilinx_zynqmp.h:173,
from include/config.h:3,
from include/common.h:16,
from env/common.c:10:
include/config_distro_bootcmd.h:302:9: error: expected '}' before 'BOOT_TARGET_DEVICES_references_USB_without_CONFIG_CMD_USB'
302 | BOOT_TARGET_DEVICES_references_USB_without_CONFIG_CMD_USB
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/config_distro_bootcmd.h:302:9: note: in definition of macro
'BOOTENV_DEV_NAME_USB'
302 | BOOT_TARGET_DEVICES_references_USB_without_CONFIG_CMD_USB
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/configs/xilinx_zynqmp.h:77:41: note: in expansion of macro
'BOOTENV_DEV_NAME'
77 | # define BOOT_TARGET_DEVICES_USB(func) func(USB, usb, 0)
func(USB, usb, 1)
| ^~~~
include/configs/xilinx_zynqmp.h:168:9: note: in expansion of macro
'BOOT_TARGET_DEVICES_USB'
168 | BOOT_TARGET_DEVICES_USB(func) \
| ^~~~~~~~~~~~~~~~~~~~~~~
include/config_distro_bootcmd.h:454:25: note: in expansion of macro
'BOOT_TARGET_DEVICES'
454 | "boot_targets=" BOOT_TARGET_DEVICES(BOOTENV_DEV_NAME) "\0"
| ^~~~~~~~~~~~~~~~~~~
include/config_distro_bootcmd.h:474:9: note: in expansion of macro
'BOOTENV_BOOT_TARGETS'
474 | BOOTENV_BOOT_TARGETS \
| ^~~~~~~~~~~~~~~~~~~~
include/configs/xilinx_zynqmp.h:179:9: note: in expansion of macro
'BOOTENV'
179 | BOOTENV
| ^~~~~~~
include/env_default.h:120:9: note: in expansion of macro
'CFG_EXTRA_ENV_SETTINGS'
120 | CFG_EXTRA_ENV_SETTINGS
| ^~~~~~~~~~~~~~~~~~~~~~
In file included from env/common.c:32:
include/env_default.h:27:36: note: to match this '{'
27 | const char default_environment[] = {
| ^
scripts/Makefile.build:256: recipe for target 'env/common.o' failed
make[1]: *** [env/common.o] Error 1
Makefile:1853: recipe for target 'env' failed
make: *** [env] Error 2
make: *** Waiting for unfinished jobs....

Add CONFIG_USB_STORAGE as dependency for USB related macro's such as
BOOT_TARGET_DEVICES_USB() and DFU_DEFAULT_POLL_TIMEOUT and
CONFIG_THOR_RESET_OFF.

Remove CONFIG_ZYNQMP_USB from Kconfig and also from defconfig since it
is not used anywhere else.

Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@amd.com>
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Link: https://lore.kernel.org/r/20230904031528.11817-3-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>

arm64: zynqmp: Do not include psu_init to U-Boot by default

The commit ed35de617013 ("Convert CONFIG_ZYNQMP_PSU_INIT_ENABLED to
Kconfig") converted CONFIG_ZYNQMP_PSU_INIT_ENABLED symbol and enabled it by
default which is not correct configuration.
Intention of this config was to have it enabled by default for SPL and
provide an option to users to also do low level initialization directly
from U-Boot.
That's why it is necessary to define second symbol with SPL marking in it
and properly use symbols depends on usage in Makefile.
Also disable ZYNQMP_PSU_INIT_ENABLED from boards which enables it by
default. CONFIG_SPL_ZYNQMP_PSU_INIT_ENABLED is enabled by default when SPL
is enabled.

Reported-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Reviewed-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/d5fcbd66b05bf0d7ef594e66464ee23b48c5e4cc.1669969083.git.michal.simek@amd.com

arm64: zynqmp: Fix dependencies around ZYNQMP_PSU_INIT_ENABLED

ZYNQMP_PSU_INIT_ENABLED is called only when BOARD_EARLY_INIT_F is defined
that's why cover this dependency in Kconfig.
board_early_init_f() is only part related to
CONFIG_ZYNQMP_PSU_INIT_ENABLED which is disabled now that's why disable
BOARD_EARLY_INIT_F and also build board_early_init_f() only when
CONFIG_BOARD_EARLY_INIT_F is enabled.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Link: https://lore.kernel.org/r/d89253ec1590cd513dcd4bfbedebae618bd6d605.1645104518.git.michal.simek@xilinx.com

arm64: zynqmp: allow overriding board name

There is no need to use zynqmp name as SYS_BOARD for all boards.
The patch is adding an option to change it.

Signed-off-by: Liam Beguin <liambeguin@gmail.com>
Link: https://lore.kernel.org/r/20211020152518.3511912-1-liambeguin@gmail.com
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

zynqmp: restore the jtag interface

When boot.bin is configured for secure boot the CSU will disable the
JTAG interface on all cases.

Some boards might rely on this interface for flashing to QSPI in which
case those systems might end up bricked during development.

This commit will restore the interface under CSU control

Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Link: https://lore.kernel.org/r/20211013134800.19452-1-jorge@foundries.io
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

spi: Rename SPI_SUPPORT to SPI

Rename these options so that CONFIG_IS_ENABLED can be used with them.

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

serial: Rename SERIAL_SUPPORT to SERIAL

Rename these options so that CONFIG_IS_ENABLED can be used with them.

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

mmc: Rename MMC_SUPPORT to MMC

Rename these options so that CONFIG_IS_ENABLED can be used with them.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
[trini: Fixup some incorrect renames]
Signed-off-by: Tom Rini <trini@konsulko.com>

zynqmp: spl: support DRAM ECC initialization

Use the ZDMA channel 0 to initialize the DRAM banks. This avoid
spurious ECC errors that can occur when accessing unitialized memory.

The feature is enabled by setting the option
CONFIG_SPL_ZYNQMP_DRAM_ECC_INIT and providing the following data:

SPL_ZYNQMP_DRAM_BANK1_BASE: start of memory to initialize
SPL_ZYNQMP_DRAM_BANK1_LEN : len of memory to initialize (hex)
SPL_ZYNQMP_DRAM_BANK2_BASE: start of memory to initialize
SPL_ZYNQMP_DRAM_BANK2_LEN : len of memory to initialize (hex)

Setting SPL_ZYNQMP_DRAM_BANK_LEN to 0 takes no action.

Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

xilinx: kconfig: Move sourcing of board Kconfig to mach folders

Do not source xilinx board Kconfig by other boards. These configs should be
available only when Xilinx platforms are selected.

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

arm64: zynqmp: Add board_boot_order for MMC boot extension

In past SPL_ZYNQMP_TWO_SDHCI symbol was introduced to handle boards with
two sdhci controllers. The problem was that U-Boot is registering
controllers based on aliases in DT but bootmode targets specific controller
ID. That's why on boards with one "second" sdhci controller bootmode was
pointing to second controller(MMC2) but alias was setup to mmc0 (the first
controller). And SPL requires to point to mmc0 in this case.

Long time ago commit f101e4bd3703
("spl: add support for alternative boot device") added support for handling
multiple bootmodes in SPL. Use this functionality and setup second sdhci
controller as backup boot device.

Below is table with behavior:
HW/bootmode bootorder
sd0/sd0 mmc0/mmc1 (mmc1 never called)
sd1/sd1 mmc1/mmc0 (mmc0 fails and mmc1 is called)
sd0+sd1/sd0 mmc0/mmc1 (mmc1 never called)
sd0+sd1/sd1 mmc1/mmc0 (mmc0 never called)

All other bootmodes are not affected but order can be extended to cover
advance boot flows.

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

arm64: zynqmp: spl: install a PMU firmware config object at runtime

Optionally allow U-Boot to load a configuration object into the Power
Management Unit (PMU) firmware on Xilinx ZynqMP.

The configuration object is required by the PMU FW to enable most SoC
peripherals. So far the only way to boot using U-Boot SPL was to hard-code
the configuration object in the PMU firmware. Allow a different boot
process, where the PMU FW is equal for any ZynqMP chip and its
configuration is passed at runtime by U-Boot SPL.

All the code for Inter-processor communication with the PMU is isolated in
a new file (pmu_ipc.c). The code is inspired by the same feature as
implemented in the Xilinx First Stage Bootloader (FSBL) and Arm Trusted
Firmware:

* https://github.com/Xilinx/embeddedsw/blob/fb647e6b4c00f5154eba52a88b948195b6f1dc2b/lib/sw_apps/zynqmp_fsbl/src/xfsbl_misc_drivers.c#L295
* https://github.com/ARM-software/arm-trusted-firmware/blob/c48d02bade88b07fa7f43aa44e5217f68e5d047f/plat/xilinx/zynqmp/pm_service/pm_api_sys.c#L357

SPL logs on the console before loading the configuration object:

U-Boot SPL 2019.07-rc1-00511-gaec224515c87 (May 15 2019 - 08:43:41 +0200)
Loading PMUFW cfg obj (2008 bytes)
EL Level: EL3
...

Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

arm64: zynqmp: Fix logic around CONFIG_ZYNQ_SDHCI

Replace SDHCI controller listing by Kconfig symbol to let SPL know that
this board is using multiple SDHCIs controllers.
Kconfig help message should explain why this is needed.
Origin symbols were used in full u-boot but with moving to distro boot
this was fixed already.

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

spl: Kconfig: Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT

Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT so
obj-$(CONFIG_$(SPL_)FS_FAT) can be used to control the build in both
SPL and U-Boot.

Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

arm64: zynqmp: Move SoC sources to mach-zynqmp

Similar changes was done for Zynq in past and this patch just follow
this pattern to separate cpu code from SoC code.

Move arch/arm/cpu/armv8/zynqmp/* -> arch/arm/mach-zynqmp/*
And also fix references to these files.

Based on
"ARM: zynq: move SoC sources to mach-zynq"
(sha1: 0107f2403669f764ab726d0d404e35bb9447bbcc)

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

arm64: zynqmp: Do not include psu_init to U-Boot by default

The commit ed35de617013 ("Convert CONFIG_ZYNQMP_PSU_INIT_ENABLED to
Kconfig") converted CONFIG_ZYNQMP_PSU_INIT_ENABLED symbol and enabled it by
default which is not correct configuration.
Intention of this config was to have it enabled by default for SPL and
provide an option to users to also do low level initialization directly
from U-Boot.
That's why it is necessary to define second symbol with SPL marking in it
and properly use symbols depends on usage in Makefile.
Also disable ZYNQMP_PSU_INIT_ENABLED from boards which enables it by
default. CONFIG_SPL_ZYNQMP_PSU_INIT_ENABLED is enabled by default when SPL
is enabled.

Reported-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Reviewed-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/d5fcbd66b05bf0d7ef594e66464ee23b48c5e4cc.1669969083.git.michal.simek@amd.com

arm64: zynqmp: Fix dependencies around ZYNQMP_PSU_INIT_ENABLED

ZYNQMP_PSU_INIT_ENABLED is called only when BOARD_EARLY_INIT_F is defined
that's why cover this dependency in Kconfig.
board_early_init_f() is only part related to
CONFIG_ZYNQMP_PSU_INIT_ENABLED which is disabled now that's why disable
BOARD_EARLY_INIT_F and also build board_early_init_f() only when
CONFIG_BOARD_EARLY_INIT_F is enabled.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Link: https://lore.kernel.org/r/d89253ec1590cd513dcd4bfbedebae618bd6d605.1645104518.git.michal.simek@xilinx.com

arm64: zynqmp: allow overriding board name

There is no need to use zynqmp name as SYS_BOARD for all boards.
The patch is adding an option to change it.

Signed-off-by: Liam Beguin <liambeguin@gmail.com>
Link: https://lore.kernel.org/r/20211020152518.3511912-1-liambeguin@gmail.com
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

zynqmp: restore the jtag interface

When boot.bin is configured for secure boot the CSU will disable the
JTAG interface on all cases.

Some boards might rely on this interface for flashing to QSPI in which
case those systems might end up bricked during development.

This commit will restore the interface under CSU control

Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Link: https://lore.kernel.org/r/20211013134800.19452-1-jorge@foundries.io
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

spi: Rename SPI_SUPPORT to SPI

Rename these options so that CONFIG_IS_ENABLED can be used with them.

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

serial: Rename SERIAL_SUPPORT to SERIAL

Rename these options so that CONFIG_IS_ENABLED can be used with them.

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

mmc: Rename MMC_SUPPORT to MMC

Rename these options so that CONFIG_IS_ENABLED can be used with them.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
[trini: Fixup some incorrect renames]
Signed-off-by: Tom Rini <trini@konsulko.com>

zynqmp: spl: support DRAM ECC initialization

Use the ZDMA channel 0 to initialize the DRAM banks. This avoid
spurious ECC errors that can occur when accessing unitialized memory.

The feature is enabled by setting the option
CONFIG_SPL_ZYNQMP_DRAM_ECC_INIT and providing the following data:

SPL_ZYNQMP_DRAM_BANK1_BASE: start of memory to initialize
SPL_ZYNQMP_DRAM_BANK1_LEN : len of memory to initialize (hex)
SPL_ZYNQMP_DRAM_BANK2_BASE: start of memory to initialize
SPL_ZYNQMP_DRAM_BANK2_LEN : len of memory to initialize (hex)

Setting SPL_ZYNQMP_DRAM_BANK_LEN to 0 takes no action.

Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

xilinx: kconfig: Move sourcing of board Kconfig to mach folders

Do not source xilinx board Kconfig by other boards. These configs should be
available only when Xilinx platforms are selected.

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

arm64: zynqmp: Add board_boot_order for MMC boot extension

In past SPL_ZYNQMP_TWO_SDHCI symbol was introduced to handle boards with
two sdhci controllers. The problem was that U-Boot is registering
controllers based on aliases in DT but bootmode targets specific controller
ID. That's why on boards with one "second" sdhci controller bootmode was
pointing to second controller(MMC2) but alias was setup to mmc0 (the first
controller). And SPL requires to point to mmc0 in this case.

Long time ago commit f101e4bd3703
("spl: add support for alternative boot device") added support for handling
multiple bootmodes in SPL. Use this functionality and setup second sdhci
controller as backup boot device.

Below is table with behavior:
HW/bootmode bootorder
sd0/sd0 mmc0/mmc1 (mmc1 never called)
sd1/sd1 mmc1/mmc0 (mmc0 fails and mmc1 is called)
sd0+sd1/sd0 mmc0/mmc1 (mmc1 never called)
sd0+sd1/sd1 mmc1/mmc0 (mmc0 never called)

All other bootmodes are not affected but order can be extended to cover
advance boot flows.

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

arm64: zynqmp: spl: install a PMU firmware config object at runtime

Optionally allow U-Boot to load a configuration object into the Power
Management Unit (PMU) firmware on Xilinx ZynqMP.

The configuration object is required by the PMU FW to enable most SoC
peripherals. So far the only way to boot using U-Boot SPL was to hard-code
the configuration object in the PMU firmware. Allow a different boot
process, where the PMU FW is equal for any ZynqMP chip and its
configuration is passed at runtime by U-Boot SPL.

All the code for Inter-processor communication with the PMU is isolated in
a new file (pmu_ipc.c). The code is inspired by the same feature as
implemented in the Xilinx First Stage Bootloader (FSBL) and Arm Trusted
Firmware:

* https://github.com/Xilinx/embeddedsw/blob/fb647e6b4c00f5154eba52a88b948195b6f1dc2b/lib/sw_apps/zynqmp_fsbl/src/xfsbl_misc_drivers.c#L295
* https://github.com/ARM-software/arm-trusted-firmware/blob/c48d02bade88b07fa7f43aa44e5217f68e5d047f/plat/xilinx/zynqmp/pm_service/pm_api_sys.c#L357

SPL logs on the console before loading the configuration object:

U-Boot SPL 2019.07-rc1-00511-gaec224515c87 (May 15 2019 - 08:43:41 +0200)
Loading PMUFW cfg obj (2008 bytes)
EL Level: EL3
...

Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

arm64: zynqmp: Fix logic around CONFIG_ZYNQ_SDHCI

Replace SDHCI controller listing by Kconfig symbol to let SPL know that
this board is using multiple SDHCIs controllers.
Kconfig help message should explain why this is needed.
Origin symbols were used in full u-boot but with moving to distro boot
this was fixed already.

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

spl: Kconfig: Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT

Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT so
obj-$(CONFIG_$(SPL_)FS_FAT) can be used to control the build in both
SPL and U-Boot.

Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

arm64: zynqmp: Move SoC sources to mach-zynqmp

Similar changes was done for Zynq in past and this patch just follow
this pattern to separate cpu code from SoC code.

Move arch/arm/cpu/armv8/zynqmp/* -> arch/arm/mach-zynqmp/*
And also fix references to these files.

Based on
"ARM: zynq: move SoC sources to mach-zynq"
(sha1: 0107f2403669f764ab726d0d404e35bb9447bbcc)

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

arm64: zynqmp: Fix dependencies around ZYNQMP_PSU_INIT_ENABLED

ZYNQMP_PSU_INIT_ENABLED is called only when BOARD_EARLY_INIT_F is defined
that's why cover this dependency in Kconfig.
board_early_init_f() is only part related to
CONFIG_ZYNQMP_PSU_INIT_ENABLED which is disabled now that's why disable
BOARD_EARLY_INIT_F and also build board_early_init_f() only when
CONFIG_BOARD_EARLY_INIT_F is enabled.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Link: https://lore.kernel.org/r/d89253ec1590cd513dcd4bfbedebae618bd6d605.1645104518.git.michal.simek@xilinx.com

arm64: zynqmp: allow overriding board name

There is no need to use zynqmp name as SYS_BOARD for all boards.
The patch is adding an option to change it.

Signed-off-by: Liam Beguin <liambeguin@gmail.com>
Link: https://lore.kernel.org/r/20211020152518.3511912-1-liambeguin@gmail.com
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

zynqmp: restore the jtag interface

When boot.bin is configured for secure boot the CSU will disable the
JTAG interface on all cases.

Some boards might rely on this interface for flashing to QSPI in which
case those systems might end up bricked during development.

This commit will restore the interface under CSU control

Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Link: https://lore.kernel.org/r/20211013134800.19452-1-jorge@foundries.io
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

spi: Rename SPI_SUPPORT to SPI

Rename these options so that CONFIG_IS_ENABLED can be used with them.

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

serial: Rename SERIAL_SUPPORT to SERIAL

Rename these options so that CONFIG_IS_ENABLED can be used with them.

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

mmc: Rename MMC_SUPPORT to MMC

Rename these options so that CONFIG_IS_ENABLED can be used with them.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
[trini: Fixup some incorrect renames]
Signed-off-by: Tom Rini <trini@konsulko.com>

zynqmp: spl: support DRAM ECC initialization

Use the ZDMA channel 0 to initialize the DRAM banks. This avoid
spurious ECC errors that can occur when accessing unitialized memory.

The feature is enabled by setting the option
CONFIG_SPL_ZYNQMP_DRAM_ECC_INIT and providing the following data:

SPL_ZYNQMP_DRAM_BANK1_BASE: start of memory to initialize
SPL_ZYNQMP_DRAM_BANK1_LEN : len of memory to initialize (hex)
SPL_ZYNQMP_DRAM_BANK2_BASE: start of memory to initialize
SPL_ZYNQMP_DRAM_BANK2_LEN : len of memory to initialize (hex)

Setting SPL_ZYNQMP_DRAM_BANK_LEN to 0 takes no action.

Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

xilinx: kconfig: Move sourcing of board Kconfig to mach folders

Do not source xilinx board Kconfig by other boards. These configs should be
available only when Xilinx platforms are selected.

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

arm64: zynqmp: Add board_boot_order for MMC boot extension

In past SPL_ZYNQMP_TWO_SDHCI symbol was introduced to handle boards with
two sdhci controllers. The problem was that U-Boot is registering
controllers based on aliases in DT but bootmode targets specific controller
ID. That's why on boards with one "second" sdhci controller bootmode was
pointing to second controller(MMC2) but alias was setup to mmc0 (the first
controller). And SPL requires to point to mmc0 in this case.

Long time ago commit f101e4bd3703
("spl: add support for alternative boot device") added support for handling
multiple bootmodes in SPL. Use this functionality and setup second sdhci
controller as backup boot device.

Below is table with behavior:
HW/bootmode bootorder
sd0/sd0 mmc0/mmc1 (mmc1 never called)
sd1/sd1 mmc1/mmc0 (mmc0 fails and mmc1 is called)
sd0+sd1/sd0 mmc0/mmc1 (mmc1 never called)
sd0+sd1/sd1 mmc1/mmc0 (mmc0 never called)

All other bootmodes are not affected but order can be extended to cover
advance boot flows.

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

arm64: zynqmp: spl: install a PMU firmware config object at runtime

Optionally allow U-Boot to load a configuration object into the Power
Management Unit (PMU) firmware on Xilinx ZynqMP.

The configuration object is required by the PMU FW to enable most SoC
peripherals. So far the only way to boot using U-Boot SPL was to hard-code
the configuration object in the PMU firmware. Allow a different boot
process, where the PMU FW is equal for any ZynqMP chip and its
configuration is passed at runtime by U-Boot SPL.

All the code for Inter-processor communication with the PMU is isolated in
a new file (pmu_ipc.c). The code is inspired by the same feature as
implemented in the Xilinx First Stage Bootloader (FSBL) and Arm Trusted
Firmware:

* https://github.com/Xilinx/embeddedsw/blob/fb647e6b4c00f5154eba52a88b948195b6f1dc2b/lib/sw_apps/zynqmp_fsbl/src/xfsbl_misc_drivers.c#L295
* https://github.com/ARM-software/arm-trusted-firmware/blob/c48d02bade88b07fa7f43aa44e5217f68e5d047f/plat/xilinx/zynqmp/pm_service/pm_api_sys.c#L357

SPL logs on the console before loading the configuration object:

U-Boot SPL 2019.07-rc1-00511-gaec224515c87 (May 15 2019 - 08:43:41 +0200)
Loading PMUFW cfg obj (2008 bytes)
EL Level: EL3
...

Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

arm64: zynqmp: Fix logic around CONFIG_ZYNQ_SDHCI

Replace SDHCI controller listing by Kconfig symbol to let SPL know that
this board is using multiple SDHCIs controllers.
Kconfig help message should explain why this is needed.
Origin symbols were used in full u-boot but with moving to distro boot
this was fixed already.

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

spl: Kconfig: Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT

Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT so
obj-$(CONFIG_$(SPL_)FS_FAT) can be used to control the build in both
SPL and U-Boot.

Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

arm64: zynqmp: Move SoC sources to mach-zynqmp

Similar changes was done for Zynq in past and this patch just follow
this pattern to separate cpu code from SoC code.

Move arch/arm/cpu/armv8/zynqmp/* -> arch/arm/mach-zynqmp/*
And also fix references to these files.

Based on
"ARM: zynq: move SoC sources to mach-zynq"
(sha1: 0107f2403669f764ab726d0d404e35bb9447bbcc)

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

arm64: zynqmp: allow overriding board name

There is no need to use zynqmp name as SYS_BOARD for all boards.
The patch is adding an option to change it.

Signed-off-by: Liam Beguin <liambeguin@gmail.com>
Link: https://lore.kernel.org/r/20211020152518.3511912-1-liambeguin@gmail.com
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

zynqmp: restore the jtag interface

When boot.bin is configured for secure boot the CSU will disable the
JTAG interface on all cases.

Some boards might rely on this interface for flashing to QSPI in which
case those systems might end up bricked during development.

This commit will restore the interface under CSU control

Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Link: https://lore.kernel.org/r/20211013134800.19452-1-jorge@foundries.io
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

spi: Rename SPI_SUPPORT to SPI

Rename these options so that CONFIG_IS_ENABLED can be used with them.

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

serial: Rename SERIAL_SUPPORT to SERIAL

Rename these options so that CONFIG_IS_ENABLED can be used with them.

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

mmc: Rename MMC_SUPPORT to MMC

Rename these options so that CONFIG_IS_ENABLED can be used with them.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
[trini: Fixup some incorrect renames]
Signed-off-by: Tom Rini <trini@konsulko.com>

zynqmp: spl: support DRAM ECC initialization

Use the ZDMA channel 0 to initialize the DRAM banks. This avoid
spurious ECC errors that can occur when accessing unitialized memory.

The feature is enabled by setting the option
CONFIG_SPL_ZYNQMP_DRAM_ECC_INIT and providing the following data:

SPL_ZYNQMP_DRAM_BANK1_BASE: start of memory to initialize
SPL_ZYNQMP_DRAM_BANK1_LEN : len of memory to initialize (hex)
SPL_ZYNQMP_DRAM_BANK2_BASE: start of memory to initialize
SPL_ZYNQMP_DRAM_BANK2_LEN : len of memory to initialize (hex)

Setting SPL_ZYNQMP_DRAM_BANK_LEN to 0 takes no action.

Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

xilinx: kconfig: Move sourcing of board Kconfig to mach folders

Do not source xilinx board Kconfig by other boards. These configs should be
available only when Xilinx platforms are selected.

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

arm64: zynqmp: Add board_boot_order for MMC boot extension

In past SPL_ZYNQMP_TWO_SDHCI symbol was introduced to handle boards with
two sdhci controllers. The problem was that U-Boot is registering
controllers based on aliases in DT but bootmode targets specific controller
ID. That's why on boards with one "second" sdhci controller bootmode was
pointing to second controller(MMC2) but alias was setup to mmc0 (the first
controller). And SPL requires to point to mmc0 in this case.

Long time ago commit f101e4bd3703
("spl: add support for alternative boot device") added support for handling
multiple bootmodes in SPL. Use this functionality and setup second sdhci
controller as backup boot device.

Below is table with behavior:
HW/bootmode bootorder
sd0/sd0 mmc0/mmc1 (mmc1 never called)
sd1/sd1 mmc1/mmc0 (mmc0 fails and mmc1 is called)
sd0+sd1/sd0 mmc0/mmc1 (mmc1 never called)
sd0+sd1/sd1 mmc1/mmc0 (mmc0 never called)

All other bootmodes are not affected but order can be extended to cover
advance boot flows.

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

arm64: zynqmp: spl: install a PMU firmware config object at runtime

Optionally allow U-Boot to load a configuration object into the Power
Management Unit (PMU) firmware on Xilinx ZynqMP.

The configuration object is required by the PMU FW to enable most SoC
peripherals. So far the only way to boot using U-Boot SPL was to hard-code
the configuration object in the PMU firmware. Allow a different boot
process, where the PMU FW is equal for any ZynqMP chip and its
configuration is passed at runtime by U-Boot SPL.

All the code for Inter-processor communication with the PMU is isolated in
a new file (pmu_ipc.c). The code is inspired by the same feature as
implemented in the Xilinx First Stage Bootloader (FSBL) and Arm Trusted
Firmware:

* https://github.com/Xilinx/embeddedsw/blob/fb647e6b4c00f5154eba52a88b948195b6f1dc2b/lib/sw_apps/zynqmp_fsbl/src/xfsbl_misc_drivers.c#L295
* https://github.com/ARM-software/arm-trusted-firmware/blob/c48d02bade88b07fa7f43aa44e5217f68e5d047f/plat/xilinx/zynqmp/pm_service/pm_api_sys.c#L357

SPL logs on the console before loading the configuration object:

U-Boot SPL 2019.07-rc1-00511-gaec224515c87 (May 15 2019 - 08:43:41 +0200)
Loading PMUFW cfg obj (2008 bytes)
EL Level: EL3
...

Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

arm64: zynqmp: Fix logic around CONFIG_ZYNQ_SDHCI

Replace SDHCI controller listing by Kconfig symbol to let SPL know that
this board is using multiple SDHCIs controllers.
Kconfig help message should explain why this is needed.
Origin symbols were used in full u-boot but with moving to distro boot
this was fixed already.

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

spl: Kconfig: Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT

Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT so
obj-$(CONFIG_$(SPL_)FS_FAT) can be used to control the build in both
SPL and U-Boot.

Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

arm64: zynqmp: Move SoC sources to mach-zynqmp

Similar changes was done for Zynq in past and this patch just follow
this pattern to separate cpu code from SoC code.

Move arch/arm/cpu/armv8/zynqmp/* -> arch/arm/mach-zynqmp/*
And also fix references to these files.

Based on
"ARM: zynq: move SoC sources to mach-zynq"
(sha1: 0107f2403669f764ab726d0d404e35bb9447bbcc)

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

spi: Rename SPI_SUPPORT to SPI

Rename these options so that CONFIG_IS_ENABLED can be used with them.

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

serial: Rename SERIAL_SUPPORT to SERIAL

Rename these options so that CONFIG_IS_ENABLED can be used with them.

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

mmc: Rename MMC_SUPPORT to MMC

Rename these options so that CONFIG_IS_ENABLED can be used with them.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
[trini: Fixup some incorrect renames]
Signed-off-by: Tom Rini <trini@konsulko.com>

zynqmp: spl: support DRAM ECC initialization

Use the ZDMA channel 0 to initialize the DRAM banks. This avoid
spurious ECC errors that can occur when accessing unitialized memory.

The feature is enabled by setting the option
CONFIG_SPL_ZYNQMP_DRAM_ECC_INIT and providing the following data:

SPL_ZYNQMP_DRAM_BANK1_BASE: start of memory to initialize
SPL_ZYNQMP_DRAM_BANK1_LEN : len of memory to initialize (hex)
SPL_ZYNQMP_DRAM_BANK2_BASE: start of memory to initialize
SPL_ZYNQMP_DRAM_BANK2_LEN : len of memory to initialize (hex)

Setting SPL_ZYNQMP_DRAM_BANK_LEN to 0 takes no action.

Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

xilinx: kconfig: Move sourcing of board Kconfig to mach folders

Do not source xilinx board Kconfig by other boards. These configs should be
available only when Xilinx platforms are selected.

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

arm64: zynqmp: Add board_boot_order for MMC boot extension

In past SPL_ZYNQMP_TWO_SDHCI symbol was introduced to handle boards with
two sdhci controllers. The problem was that U-Boot is registering
controllers based on aliases in DT but bootmode targets specific controller
ID. That's why on boards with one "second" sdhci controller bootmode was
pointing to second controller(MMC2) but alias was setup to mmc0 (the first
controller). And SPL requires to point to mmc0 in this case.

Long time ago commit f101e4bd3703
("spl: add support for alternative boot device") added support for handling
multiple bootmodes in SPL. Use this functionality and setup second sdhci
controller as backup boot device.

Below is table with behavior:
HW/bootmode bootorder
sd0/sd0 mmc0/mmc1 (mmc1 never called)
sd1/sd1 mmc1/mmc0 (mmc0 fails and mmc1 is called)
sd0+sd1/sd0 mmc0/mmc1 (mmc1 never called)
sd0+sd1/sd1 mmc1/mmc0 (mmc0 never called)

All other bootmodes are not affected but order can be extended to cover
advance boot flows.

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

arm64: zynqmp: spl: install a PMU firmware config object at runtime

Optionally allow U-Boot to load a configuration object into the Power
Management Unit (PMU) firmware on Xilinx ZynqMP.

The configuration object is required by the PMU FW to enable most SoC
peripherals. So far the only way to boot using U-Boot SPL was to hard-code
the configuration object in the PMU firmware. Allow a different boot
process, where the PMU FW is equal for any ZynqMP chip and its
configuration is passed at runtime by U-Boot SPL.

All the code for Inter-processor communication with the PMU is isolated in
a new file (pmu_ipc.c). The code is inspired by the same feature as
implemented in the Xilinx First Stage Bootloader (FSBL) and Arm Trusted
Firmware:

* https://github.com/Xilinx/embeddedsw/blob/fb647e6b4c00f5154eba52a88b948195b6f1dc2b/lib/sw_apps/zynqmp_fsbl/src/xfsbl_misc_drivers.c#L295
* https://github.com/ARM-software/arm-trusted-firmware/blob/c48d02bade88b07fa7f43aa44e5217f68e5d047f/plat/xilinx/zynqmp/pm_service/pm_api_sys.c#L357

SPL logs on the console before loading the configuration object:

U-Boot SPL 2019.07-rc1-00511-gaec224515c87 (May 15 2019 - 08:43:41 +0200)
Loading PMUFW cfg obj (2008 bytes)
EL Level: EL3
...

Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

arm64: zynqmp: Fix logic around CONFIG_ZYNQ_SDHCI

Replace SDHCI controller listing by Kconfig symbol to let SPL know that
this board is using multiple SDHCIs controllers.
Kconfig help message should explain why this is needed.
Origin symbols were used in full u-boot but with moving to distro boot
this was fixed already.

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

spl: Kconfig: Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT

Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT so
obj-$(CONFIG_$(SPL_)FS_FAT) can be used to control the build in both
SPL and U-Boot.

Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

arm64: zynqmp: Move SoC sources to mach-zynqmp

Similar changes was done for Zynq in past and this patch just follow
this pattern to separate cpu code from SoC code.

Move arch/arm/cpu/armv8/zynqmp/* -> arch/arm/mach-zynqmp/*
And also fix references to these files.

Based on
"ARM: zynq: move SoC sources to mach-zynq"
(sha1: 0107f2403669f764ab726d0d404e35bb9447bbcc)

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

zynqmp: spl: support DRAM ECC initialization

Use the ZDMA channel 0 to initialize the DRAM banks. This avoid
spurious ECC errors that can occur when accessing unitialized memory.

The feature is enabled by setting the option
CONFIG_SPL_ZYNQMP_DRAM_ECC_INIT and providing the following data:

SPL_ZYNQMP_DRAM_BANK1_BASE: start of memory to initialize
SPL_ZYNQMP_DRAM_BANK1_LEN : len of memory to initialize (hex)
SPL_ZYNQMP_DRAM_BANK2_BASE: start of memory to initialize
SPL_ZYNQMP_DRAM_BANK2_LEN : len of memory to initialize (hex)

Setting SPL_ZYNQMP_DRAM_BANK_LEN to 0 takes no action.

Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

xilinx: kconfig: Move sourcing of board Kconfig to mach folders

Do not source xilinx board Kconfig by other boards. These configs should be
available only when Xilinx platforms are selected.

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

arm64: zynqmp: Add board_boot_order for MMC boot extension

In past SPL_ZYNQMP_TWO_SDHCI symbol was introduced to handle boards with
two sdhci controllers. The problem was that U-Boot is registering
controllers based on aliases in DT but bootmode targets specific controller
ID. That's why on boards with one "second" sdhci controller bootmode was
pointing to second controller(MMC2) but alias was setup to mmc0 (the first
controller). And SPL requires to point to mmc0 in this case.

Long time ago commit f101e4bd3703
("spl: add support for alternative boot device") added support for handling
multiple bootmodes in SPL. Use this functionality and setup second sdhci
controller as backup boot device.

Below is table with behavior:
HW/bootmode bootorder
sd0/sd0 mmc0/mmc1 (mmc1 never called)
sd1/sd1 mmc1/mmc0 (mmc0 fails and mmc1 is called)
sd0+sd1/sd0 mmc0/mmc1 (mmc1 never called)
sd0+sd1/sd1 mmc1/mmc0 (mmc0 never called)

All other bootmodes are not affected but order can be extended to cover
advance boot flows.

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

arm64: zynqmp: spl: install a PMU firmware config object at runtime

Optionally allow U-Boot to load a configuration object into the Power
Management Unit (PMU) firmware on Xilinx ZynqMP.

The configuration object is required by the PMU FW to enable most SoC
peripherals. So far the only way to boot using U-Boot SPL was to hard-code
the configuration object in the PMU firmware. Allow a different boot
process, where the PMU FW is equal for any ZynqMP chip and its
configuration is passed at runtime by U-Boot SPL.

All the code for Inter-processor communication with the PMU is isolated in
a new file (pmu_ipc.c). The code is inspired by the same feature as
implemented in the Xilinx First Stage Bootloader (FSBL) and Arm Trusted
Firmware:

* https://github.com/Xilinx/embeddedsw/blob/fb647e6b4c00f5154eba52a88b948195b6f1dc2b/lib/sw_apps/zynqmp_fsbl/src/xfsbl_misc_drivers.c#L295
* https://github.com/ARM-software/arm-trusted-firmware/blob/c48d02bade88b07fa7f43aa44e5217f68e5d047f/plat/xilinx/zynqmp/pm_service/pm_api_sys.c#L357

SPL logs on the console before loading the configuration object:

U-Boot SPL 2019.07-rc1-00511-gaec224515c87 (May 15 2019 - 08:43:41 +0200)
Loading PMUFW cfg obj (2008 bytes)
EL Level: EL3
...

Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

arm64: zynqmp: Fix logic around CONFIG_ZYNQ_SDHCI

Replace SDHCI controller listing by Kconfig symbol to let SPL know that
this board is using multiple SDHCIs controllers.
Kconfig help message should explain why this is needed.
Origin symbols were used in full u-boot but with moving to distro boot
this was fixed already.

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

spl: Kconfig: Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT

Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT so
obj-$(CONFIG_$(SPL_)FS_FAT) can be used to control the build in both
SPL and U-Boot.

Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

arm64: zynqmp: Move SoC sources to mach-zynqmp

Similar changes was done for Zynq in past and this patch just follow
this pattern to separate cpu code from SoC code.

Move arch/arm/cpu/armv8/zynqmp/* -> arch/arm/mach-zynqmp/*
And also fix references to these files.

Based on
"ARM: zynq: move SoC sources to mach-zynq"
(sha1: 0107f2403669f764ab726d0d404e35bb9447bbcc)

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

xilinx: kconfig: Move sourcing of board Kconfig to mach folders

Do not source xilinx board Kconfig by other boards. These configs should be
available only when Xilinx platforms are selected.

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

arm64: zynqmp: Add board_boot_order for MMC boot extension

In past SPL_ZYNQMP_TWO_SDHCI symbol was introduced to handle boards with
two sdhci controllers. The problem was that U-Boot is registering
controllers based on aliases in DT but bootmode targets specific controller
ID. That's why on boards with one "second" sdhci controller bootmode was
pointing to second controller(MMC2) but alias was setup to mmc0 (the first
controller). And SPL requires to point to mmc0 in this case.

Long time ago commit f101e4bd3703
("spl: add support for alternative boot device") added support for handling
multiple bootmodes in SPL. Use this functionality and setup second sdhci
controller as backup boot device.

Below is table with behavior:
HW/bootmode bootorder
sd0/sd0 mmc0/mmc1 (mmc1 never called)
sd1/sd1 mmc1/mmc0 (mmc0 fails and mmc1 is called)
sd0+sd1/sd0 mmc0/mmc1 (mmc1 never called)
sd0+sd1/sd1 mmc1/mmc0 (mmc0 never called)

All other bootmodes are not affected but order can be extended to cover
advance boot flows.

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

arm64: zynqmp: spl: install a PMU firmware config object at runtime

Optionally allow U-Boot to load a configuration object into the Power
Management Unit (PMU) firmware on Xilinx ZynqMP.

The configuration object is required by the PMU FW to enable most SoC
peripherals. So far the only way to boot using U-Boot SPL was to hard-code
the configuration object in the PMU firmware. Allow a different boot
process, where the PMU FW is equal for any ZynqMP chip and its
configuration is passed at runtime by U-Boot SPL.

All the code for Inter-processor communication with the PMU is isolated in
a new file (pmu_ipc.c). The code is inspired by the same feature as
implemented in the Xilinx First Stage Bootloader (FSBL) and Arm Trusted
Firmware:

* https://github.com/Xilinx/embeddedsw/blob/fb647e6b4c00f5154eba52a88b948195b6f1dc2b/lib/sw_apps/zynqmp_fsbl/src/xfsbl_misc_drivers.c#L295
* https://github.com/ARM-software/arm-trusted-firmware/blob/c48d02bade88b07fa7f43aa44e5217f68e5d047f/plat/xilinx/zynqmp/pm_service/pm_api_sys.c#L357

SPL logs on the console before loading the configuration object:

U-Boot SPL 2019.07-rc1-00511-gaec224515c87 (May 15 2019 - 08:43:41 +0200)
Loading PMUFW cfg obj (2008 bytes)
EL Level: EL3
...

Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

arm64: zynqmp: Fix logic around CONFIG_ZYNQ_SDHCI

Replace SDHCI controller listing by Kconfig symbol to let SPL know that
this board is using multiple SDHCIs controllers.
Kconfig help message should explain why this is needed.
Origin symbols were used in full u-boot but with moving to distro boot
this was fixed already.

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

spl: Kconfig: Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT

Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT so
obj-$(CONFIG_$(SPL_)FS_FAT) can be used to control the build in both
SPL and U-Boot.

Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

arm64: zynqmp: Move SoC sources to mach-zynqmp

Similar changes was done for Zynq in past and this patch just follow
this pattern to separate cpu code from SoC code.

Move arch/arm/cpu/armv8/zynqmp/* -> arch/arm/mach-zynqmp/*
And also fix references to these files.

Based on
"ARM: zynq: move SoC sources to mach-zynq"
(sha1: 0107f2403669f764ab726d0d404e35bb9447bbcc)

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

xilinx: kconfig: Move sourcing of board Kconfig to mach folders

Do not source xilinx board Kconfig by other boards. These configs should be
available only when Xilinx platforms are selected.

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

arm64: zynqmp: Add board_boot_order for MMC boot extension

In past SPL_ZYNQMP_TWO_SDHCI symbol was introduced to handle boards with
two sdhci controllers. The problem was that U-Boot is registering
controllers based on aliases in DT but bootmode targets specific controller
ID. That's why on boards with one "second" sdhci controller bootmode was
pointing to second controller(MMC2) but alias was setup to mmc0 (the first
controller). And SPL requires to point to mmc0 in this case.

Long time ago commit f101e4bd3703
("spl: add support for alternative boot device") added support for handling
multiple bootmodes in SPL. Use this functionality and setup second sdhci
controller as backup boot device.

Below is table with behavior:
HW/bootmode bootorder
sd0/sd0 mmc0/mmc1 (mmc1 never called)
sd1/sd1 mmc1/mmc0 (mmc0 fails and mmc1 is called)
sd0+sd1/sd0 mmc0/mmc1 (mmc1 never called)
sd0+sd1/sd1 mmc1/mmc0 (mmc0 never called)

All other bootmodes are not affected but order can be extended to cover
advance boot flows.

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

arm64: zynqmp: spl: install a PMU firmware config object at runtime

Optionally allow U-Boot to load a configuration object into the Power
Management Unit (PMU) firmware on Xilinx ZynqMP.

The configuration object is required by the PMU FW to enable most SoC
peripherals. So far the only way to boot using U-Boot SPL was to hard-code
the configuration object in the PMU firmware. Allow a different boot
process, where the PMU FW is equal for any ZynqMP chip and its
configuration is passed at runtime by U-Boot SPL.

All the code for Inter-processor communication with the PMU is isolated in
a new file (pmu_ipc.c). The code is inspired by the same feature as
implemented in the Xilinx First Stage Bootloader (FSBL) and Arm Trusted
Firmware:

* https://github.com/Xilinx/embeddedsw/blob/fb647e6b4c00f5154eba52a88b948195b6f1dc2b/lib/sw_apps/zynqmp_fsbl/src/xfsbl_misc_drivers.c#L295
* https://github.com/ARM-software/arm-trusted-firmware/blob/c48d02bade88b07fa7f43aa44e5217f68e5d047f/plat/xilinx/zynqmp/pm_service/pm_api_sys.c#L357

SPL logs on the console before loading the configuration object:

U-Boot SPL 2019.07-rc1-00511-gaec224515c87 (May 15 2019 - 08:43:41 +0200)
Loading PMUFW cfg obj (2008 bytes)
EL Level: EL3
...

Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

arm64: zynqmp: Fix logic around CONFIG_ZYNQ_SDHCI

Replace SDHCI controller listing by Kconfig symbol to let SPL know that
this board is using multiple SDHCIs controllers.
Kconfig help message should explain why this is needed.
Origin symbols were used in full u-boot but with moving to distro boot
this was fixed already.

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

spl: Kconfig: Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT

Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT so
obj-$(CONFIG_$(SPL_)FS_FAT) can be used to control the build in both
SPL and U-Boot.

Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

arm64: zynqmp: Move SoC sources to mach-zynqmp

Similar changes was done for Zynq in past and this patch just follow
this pattern to separate cpu code from SoC code.

Move arch/arm/cpu/armv8/zynqmp/* -> arch/arm/mach-zynqmp/*
And also fix references to these files.

Based on
"ARM: zynq: move SoC sources to mach-zynq"
(sha1: 0107f2403669f764ab726d0d404e35bb9447bbcc)

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

xilinx: kconfig: Move sourcing of board Kconfig to mach folders

Do not source xilinx board Kconfig by other boards. These configs should be
available only when Xilinx platforms are selected.

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

arm64: zynqmp: Add board_boot_order for MMC boot extension

In past SPL_ZYNQMP_TWO_SDHCI symbol was introduced to handle boards with
two sdhci controllers. The problem was that U-Boot is registering
controllers based on aliases in DT but bootmode targets specific controller
ID. That's why on boards with one "second" sdhci controller bootmode was
pointing to second controller(MMC2) but alias was setup to mmc0 (the first
controller). And SPL requires to point to mmc0 in this case.

Long time ago commit f101e4bd3703
("spl: add support for alternative boot device") added support for handling
multiple bootmodes in SPL. Use this functionality and setup second sdhci
controller as backup boot device.

Below is table with behavior:
HW/bootmode bootorder
sd0/sd0 mmc0/mmc1 (mmc1 never called)
sd1/sd1 mmc1/mmc0 (mmc0 fails and mmc1 is called)
sd0+sd1/sd0 mmc0/mmc1 (mmc1 never called)
sd0+sd1/sd1 mmc1/mmc0 (mmc0 never called)

All other bootmodes are not affected but order can be extended to cover
advance boot flows.

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

arm64: zynqmp: spl: install a PMU firmware config object at runtime

Optionally allow U-Boot to load a configuration object into the Power
Management Unit (PMU) firmware on Xilinx ZynqMP.

The configuration object is required by the PMU FW to enable most SoC
peripherals. So far the only way to boot using U-Boot SPL was to hard-code
the configuration object in the PMU firmware. Allow a different boot
process, where the PMU FW is equal for any ZynqMP chip and its
configuration is passed at runtime by U-Boot SPL.

All the code for Inter-processor communication with the PMU is isolated in
a new file (pmu_ipc.c). The code is inspired by the same feature as
implemented in the Xilinx First Stage Bootloader (FSBL) and Arm Trusted
Firmware:

* https://github.com/Xilinx/embeddedsw/blob/fb647e6b4c00f5154eba52a88b948195b6f1dc2b/lib/sw_apps/zynqmp_fsbl/src/xfsbl_misc_drivers.c#L295
* https://github.com/ARM-software/arm-trusted-firmware/blob/c48d02bade88b07fa7f43aa44e5217f68e5d047f/plat/xilinx/zynqmp/pm_service/pm_api_sys.c#L357

SPL logs on the console before loading the configuration object:

U-Boot SPL 2019.07-rc1-00511-gaec224515c87 (May 15 2019 - 08:43:41 +0200)
Loading PMUFW cfg obj (2008 bytes)
EL Level: EL3
...

Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

arm64: zynqmp: Fix logic around CONFIG_ZYNQ_SDHCI

Replace SDHCI controller listing by Kconfig symbol to let SPL know that
this board is using multiple SDHCIs controllers.
Kconfig help message should explain why this is needed.
Origin symbols were used in full u-boot but with moving to distro boot
this was fixed already.

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

spl: Kconfig: Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT

Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT so
obj-$(CONFIG_$(SPL_)FS_FAT) can be used to control the build in both
SPL and U-Boot.

Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

arm64: zynqmp: Move SoC sources to mach-zynqmp

Similar changes was done for Zynq in past and this patch just follow
this pattern to separate cpu code from SoC code.

Move arch/arm/cpu/armv8/zynqmp/* -> arch/arm/mach-zynqmp/*
And also fix references to these files.

Based on
"ARM: zynq: move SoC sources to mach-zynq"
(sha1: 0107f2403669f764ab726d0d404e35bb9447bbcc)

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

xilinx: kconfig: Move sourcing of board Kconfig to mach folders

Do not source xilinx board Kconfig by other boards. These configs should be
available only when Xilinx platforms are selected.

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

arm64: zynqmp: Add board_boot_order for MMC boot extension

In past SPL_ZYNQMP_TWO_SDHCI symbol was introduced to handle boards with
two sdhci controllers. The problem was that U-Boot is registering
controllers based on aliases in DT but bootmode targets specific controller
ID. That's why on boards with one "second" sdhci controller bootmode was
pointing to second controller(MMC2) but alias was setup to mmc0 (the first
controller). And SPL requires to point to mmc0 in this case.

Long time ago commit f101e4bd3703
("spl: add support for alternative boot device") added support for handling
multiple bootmodes in SPL. Use this functionality and setup second sdhci
controller as backup boot device.

Below is table with behavior:
HW/bootmode bootorder
sd0/sd0 mmc0/mmc1 (mmc1 never called)
sd1/sd1 mmc1/mmc0 (mmc0 fails and mmc1 is called)
sd0+sd1/sd0 mmc0/mmc1 (mmc1 never called)
sd0+sd1/sd1 mmc1/mmc0 (mmc0 never called)

All other bootmodes are not affected but order can be extended to cover
advance boot flows.

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

arm64: zynqmp: spl: install a PMU firmware config object at runtime

Optionally allow U-Boot to load a configuration object into the Power
Management Unit (PMU) firmware on Xilinx ZynqMP.

The configuration object is required by the PMU FW to enable most SoC
peripherals. So far the only way to boot using U-Boot SPL was to hard-code
the configuration object in the PMU firmware. Allow a different boot
process, where the PMU FW is equal for any ZynqMP chip and its
configuration is passed at runtime by U-Boot SPL.

All the code for Inter-processor communication with the PMU is isolated in
a new file (pmu_ipc.c). The code is inspired by the same feature as
implemented in the Xilinx First Stage Bootloader (FSBL) and Arm Trusted
Firmware:

* https://github.com/Xilinx/embeddedsw/blob/fb647e6b4c00f5154eba52a88b948195b6f1dc2b/lib/sw_apps/zynqmp_fsbl/src/xfsbl_misc_drivers.c#L295
* https://github.com/ARM-software/arm-trusted-firmware/blob/c48d02bade88b07fa7f43aa44e5217f68e5d047f/plat/xilinx/zynqmp/pm_service/pm_api_sys.c#L357

SPL logs on the console before loading the configuration object:

U-Boot SPL 2019.07-rc1-00511-gaec224515c87 (May 15 2019 - 08:43:41 +0200)
Loading PMUFW cfg obj (2008 bytes)
EL Level: EL3
...

Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

arm64: zynqmp: Fix logic around CONFIG_ZYNQ_SDHCI

Replace SDHCI controller listing by Kconfig symbol to let SPL know that
this board is using multiple SDHCIs controllers.
Kconfig help message should explain why this is needed.
Origin symbols were used in full u-boot but with moving to distro boot
this was fixed already.

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

spl: Kconfig: Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT

Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT so
obj-$(CONFIG_$(SPL_)FS_FAT) can be used to control the build in both
SPL and U-Boot.

Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

arm64: zynqmp: Move SoC sources to mach-zynqmp

Similar changes was done for Zynq in past and this patch just follow
this pattern to separate cpu code from SoC code.

Move arch/arm/cpu/armv8/zynqmp/* -> arch/arm/mach-zynqmp/*
And also fix references to these files.

Based on
"ARM: zynq: move SoC sources to mach-zynq"
(sha1: 0107f2403669f764ab726d0d404e35bb9447bbcc)

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

xilinx: kconfig: Move sourcing of board Kconfig to mach folders

Do not source xilinx board Kconfig by other boards. These configs should be
available only when Xilinx platforms are selected.

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

arm64: zynqmp: Add board_boot_order for MMC boot extension

In past SPL_ZYNQMP_TWO_SDHCI symbol was introduced to handle boards with
two sdhci controllers. The problem was that U-Boot is registering
controllers based on aliases in DT but bootmode targets specific controller
ID. That's why on boards with one "second" sdhci controller bootmode was
pointing to second controller(MMC2) but alias was setup to mmc0 (the first
controller). And SPL requires to point to mmc0 in this case.

Long time ago commit f101e4bd3703
("spl: add support for alternative boot device") added support for handling
multiple bootmodes in SPL. Use this functionality and setup second sdhci
controller as backup boot device.

Below is table with behavior:
HW/bootmode bootorder
sd0/sd0 mmc0/mmc1 (mmc1 never called)
sd1/sd1 mmc1/mmc0 (mmc0 fails and mmc1 is called)
sd0+sd1/sd0 mmc0/mmc1 (mmc1 never called)
sd0+sd1/sd1 mmc1/mmc0 (mmc0 never called)

All other bootmodes are not affected but order can be extended to cover
advance boot flows.

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

arm64: zynqmp: spl: install a PMU firmware config object at runtime

Optionally allow U-Boot to load a configuration object into the Power
Management Unit (PMU) firmware on Xilinx ZynqMP.

The configuration object is required by the PMU FW to enable most SoC
peripherals. So far the only way to boot using U-Boot SPL was to hard-code
the configuration object in the PMU firmware. Allow a different boot
process, where the PMU FW is equal for any ZynqMP chip and its
configuration is passed at runtime by U-Boot SPL.

All the code for Inter-processor communication with the PMU is isolated in
a new file (pmu_ipc.c). The code is inspired by the same feature as
implemented in the Xilinx First Stage Bootloader (FSBL) and Arm Trusted
Firmware:

* https://github.com/Xilinx/embeddedsw/blob/fb647e6b4c00f5154eba52a88b948195b6f1dc2b/lib/sw_apps/zynqmp_fsbl/src/xfsbl_misc_drivers.c#L295
* https://github.com/ARM-software/arm-trusted-firmware/blob/c48d02bade88b07fa7f43aa44e5217f68e5d047f/plat/xilinx/zynqmp/pm_service/pm_api_sys.c#L357

SPL logs on the console before loading the configuration object:

U-Boot SPL 2019.07-rc1-00511-gaec224515c87 (May 15 2019 - 08:43:41 +0200)
Loading PMUFW cfg obj (2008 bytes)
EL Level: EL3
...

Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

arm64: zynqmp: Fix logic around CONFIG_ZYNQ_SDHCI

Replace SDHCI controller listing by Kconfig symbol to let SPL know that
this board is using multiple SDHCIs controllers.
Kconfig help message should explain why this is needed.
Origin symbols were used in full u-boot but with moving to distro boot
this was fixed already.

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

spl: Kconfig: Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT

Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT so
obj-$(CONFIG_$(SPL_)FS_FAT) can be used to control the build in both
SPL and U-Boot.

Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

arm64: zynqmp: Move SoC sources to mach-zynqmp

Similar changes was done for Zynq in past and this patch just follow
this pattern to separate cpu code from SoC code.

Move arch/arm/cpu/armv8/zynqmp/* -> arch/arm/mach-zynqmp/*
And also fix references to these files.

Based on
"ARM: zynq: move SoC sources to mach-zynq"
(sha1: 0107f2403669f764ab726d0d404e35bb9447bbcc)

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

xilinx: kconfig: Move sourcing of board Kconfig to mach folders

Do not source xilinx board Kconfig by other boards. These configs should be
available only when Xilinx platforms are selected.

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

arm64: zynqmp: Add board_boot_order for MMC boot extension

In past SPL_ZYNQMP_TWO_SDHCI symbol was introduced to handle boards with
two sdhci controllers. The problem was that U-Boot is registering
controllers based on aliases in DT but bootmode targets specific controller
ID. That's why on boards with one "second" sdhci controller bootmode was
pointing to second controller(MMC2) but alias was setup to mmc0 (the first
controller). And SPL requires to point to mmc0 in this case.

Long time ago commit f101e4bd3703
("spl: add support for alternative boot device") added support for handling
multiple bootmodes in SPL. Use this functionality and setup second sdhci
controller as backup boot device.

Below is table with behavior:
HW/bootmode bootorder
sd0/sd0 mmc0/mmc1 (mmc1 never called)
sd1/sd1 mmc1/mmc0 (mmc0 fails and mmc1 is called)
sd0+sd1/sd0 mmc0/mmc1 (mmc1 never called)
sd0+sd1/sd1 mmc1/mmc0 (mmc0 never called)

All other bootmodes are not affected but order can be extended to cover
advance boot flows.

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

arm64: zynqmp: spl: install a PMU firmware config object at runtime

Optionally allow U-Boot to load a configuration object into the Power
Management Unit (PMU) firmware on Xilinx ZynqMP.

The configuration object is required by the PMU FW to enable most SoC
peripherals. So far the only way to boot using U-Boot SPL was to hard-code
the configuration object in the PMU firmware. Allow a different boot
process, where the PMU FW is equal for any ZynqMP chip and its
configuration is passed at runtime by U-Boot SPL.

All the code for Inter-processor communication with the PMU is isolated in
a new file (pmu_ipc.c). The code is inspired by the same feature as
implemented in the Xilinx First Stage Bootloader (FSBL) and Arm Trusted
Firmware:

* https://github.com/Xilinx/embeddedsw/blob/fb647e6b4c00f5154eba52a88b948195b6f1dc2b/lib/sw_apps/zynqmp_fsbl/src/xfsbl_misc_drivers.c#L295
* https://github.com/ARM-software/arm-trusted-firmware/blob/c48d02bade88b07fa7f43aa44e5217f68e5d047f/plat/xilinx/zynqmp/pm_service/pm_api_sys.c#L357

SPL logs on the console before loading the configuration object:

U-Boot SPL 2019.07-rc1-00511-gaec224515c87 (May 15 2019 - 08:43:41 +0200)
Loading PMUFW cfg obj (2008 bytes)
EL Level: EL3
...

Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

arm64: zynqmp: Fix logic around CONFIG_ZYNQ_SDHCI

Replace SDHCI controller listing by Kconfig symbol to let SPL know that
this board is using multiple SDHCIs controllers.
Kconfig help message should explain why this is needed.
Origin symbols were used in full u-boot but with moving to distro boot
this was fixed already.

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

spl: Kconfig: Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT

Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT so
obj-$(CONFIG_$(SPL_)FS_FAT) can be used to control the build in both
SPL and U-Boot.

Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

arm64: zynqmp: Move SoC sources to mach-zynqmp

Similar changes was done for Zynq in past and this patch just follow
this pattern to separate cpu code from SoC code.

Move arch/arm/cpu/armv8/zynqmp/* -> arch/arm/mach-zynqmp/*
And also fix references to these files.

Based on
"ARM: zynq: move SoC sources to mach-zynq"
(sha1: 0107f2403669f764ab726d0d404e35bb9447bbcc)

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

xilinx: kconfig: Move sourcing of board Kconfig to mach folders

Do not source xilinx board Kconfig by other boards. These configs should be
available only when Xilinx platforms are selected.

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

arm64: zynqmp: Add board_boot_order for MMC boot extension

In past SPL_ZYNQMP_TWO_SDHCI symbol was introduced to handle boards with
two sdhci controllers. The problem was that U-Boot is registering
controllers based on aliases in DT but bootmode targets specific controller
ID. That's why on boards with one "second" sdhci controller bootmode was
pointing to second controller(MMC2) but alias was setup to mmc0 (the first
controller). And SPL requires to point to mmc0 in this case.

Long time ago commit f101e4bd3703
("spl: add support for alternative boot device") added support for handling
multiple bootmodes in SPL. Use this functionality and setup second sdhci
controller as backup boot device.

Below is table with behavior:
HW/bootmode bootorder
sd0/sd0 mmc0/mmc1 (mmc1 never called)
sd1/sd1 mmc1/mmc0 (mmc0 fails and mmc1 is called)
sd0+sd1/sd0 mmc0/mmc1 (mmc1 never called)
sd0+sd1/sd1 mmc1/mmc0 (mmc0 never called)

All other bootmodes are not affected but order can be extended to cover
advance boot flows.

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

arm64: zynqmp: spl: install a PMU firmware config object at runtime

Optionally allow U-Boot to load a configuration object into the Power
Management Unit (PMU) firmware on Xilinx ZynqMP.

The configuration object is required by the PMU FW to enable most SoC
peripherals. So far the only way to boot using U-Boot SPL was to hard-code
the configuration object in the PMU firmware. Allow a different boot
process, where the PMU FW is equal for any ZynqMP chip and its
configuration is passed at runtime by U-Boot SPL.

All the code for Inter-processor communication with the PMU is isolated in
a new file (pmu_ipc.c). The code is inspired by the same feature as
implemented in the Xilinx First Stage Bootloader (FSBL) and Arm Trusted
Firmware:

* https://github.com/Xilinx/embeddedsw/blob/fb647e6b4c00f5154eba52a88b948195b6f1dc2b/lib/sw_apps/zynqmp_fsbl/src/xfsbl_misc_drivers.c#L295
* https://github.com/ARM-software/arm-trusted-firmware/blob/c48d02bade88b07fa7f43aa44e5217f68e5d047f/plat/xilinx/zynqmp/pm_service/pm_api_sys.c#L357

SPL logs on the console before loading the configuration object:

U-Boot SPL 2019.07-rc1-00511-gaec224515c87 (May 15 2019 - 08:43:41 +0200)
Loading PMUFW cfg obj (2008 bytes)
EL Level: EL3
...

Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

arm64: zynqmp: Fix logic around CONFIG_ZYNQ_SDHCI

Replace SDHCI controller listing by Kconfig symbol to let SPL know that
this board is using multiple SDHCIs controllers.
Kconfig help message should explain why this is needed.
Origin symbols were used in full u-boot but with moving to distro boot
this was fixed already.

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

spl: Kconfig: Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT

Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT so
obj-$(CONFIG_$(SPL_)FS_FAT) can be used to control the build in both
SPL and U-Boot.

Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

arm64: zynqmp: Move SoC sources to mach-zynqmp

Similar changes was done for Zynq in past and this patch just follow
this pattern to separate cpu code from SoC code.

Move arch/arm/cpu/armv8/zynqmp/* -> arch/arm/mach-zynqmp/*
And also fix references to these files.

Based on
"ARM: zynq: move SoC sources to mach-zynq"
(sha1: 0107f2403669f764ab726d0d404e35bb9447bbcc)

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

xilinx: kconfig: Move sourcing of board Kconfig to mach folders

Do not source xilinx board Kconfig by other boards. These configs should be
available only when Xilinx platforms are selected.

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

arm64: zynqmp: Add board_boot_order for MMC boot extension

In past SPL_ZYNQMP_TWO_SDHCI symbol was introduced to handle boards with
two sdhci controllers. The problem was that U-Boot is registering
controllers based on aliases in DT but bootmode targets specific controller
ID. That's why on boards with one "second" sdhci controller bootmode was
pointing to second controller(MMC2) but alias was setup to mmc0 (the first
controller). And SPL requires to point to mmc0 in this case.

Long time ago commit f101e4bd3703
("spl: add support for alternative boot device") added support for handling
multiple bootmodes in SPL. Use this functionality and setup second sdhci
controller as backup boot device.

Below is table with behavior:
HW/bootmode bootorder
sd0/sd0 mmc0/mmc1 (mmc1 never called)
sd1/sd1 mmc1/mmc0 (mmc0 fails and mmc1 is called)
sd0+sd1/sd0 mmc0/mmc1 (mmc1 never called)
sd0+sd1/sd1 mmc1/mmc0 (mmc0 never called)

All other bootmodes are not affected but order can be extended to cover
advance boot flows.

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

arm64: zynqmp: spl: install a PMU firmware config object at runtime

Optionally allow U-Boot to load a configuration object into the Power
Management Unit (PMU) firmware on Xilinx ZynqMP.

The configuration object is required by the PMU FW to enable most SoC
peripherals. So far the only way to boot using U-Boot SPL was to hard-code
the configuration object in the PMU firmware. Allow a different boot
process, where the PMU FW is equal for any ZynqMP chip and its
configuration is passed at runtime by U-Boot SPL.

All the code for Inter-processor communication with the PMU is isolated in
a new file (pmu_ipc.c). The code is inspired by the same feature as
implemented in the Xilinx First Stage Bootloader (FSBL) and Arm Trusted
Firmware:

* https://github.com/Xilinx/embeddedsw/blob/fb647e6b4c00f5154eba52a88b948195b6f1dc2b/lib/sw_apps/zynqmp_fsbl/src/xfsbl_misc_drivers.c#L295
* https://github.com/ARM-software/arm-trusted-firmware/blob/c48d02bade88b07fa7f43aa44e5217f68e5d047f/plat/xilinx/zynqmp/pm_service/pm_api_sys.c#L357

SPL logs on the console before loading the configuration object:

U-Boot SPL 2019.07-rc1-00511-gaec224515c87 (May 15 2019 - 08:43:41 +0200)
Loading PMUFW cfg obj (2008 bytes)
EL Level: EL3
...

Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

arm64: zynqmp: Fix logic around CONFIG_ZYNQ_SDHCI

Replace SDHCI controller listing by Kconfig symbol to let SPL know that
this board is using multiple SDHCIs controllers.
Kconfig help message should explain why this is needed.
Origin symbols were used in full u-boot but with moving to distro boot
this was fixed already.

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

spl: Kconfig: Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT

Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT so
obj-$(CONFIG_$(SPL_)FS_FAT) can be used to control the build in both
SPL and U-Boot.

Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

arm64: zynqmp: Move SoC sources to mach-zynqmp

Similar changes was done for Zynq in past and this patch just follow
this pattern to separate cpu code from SoC code.

Move arch/arm/cpu/armv8/zynqmp/* -> arch/arm/mach-zynqmp/*
And also fix references to these files.

Based on
"ARM: zynq: move SoC sources to mach-zynq"
(sha1: 0107f2403669f764ab726d0d404e35bb9447bbcc)

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

xilinx: kconfig: Move sourcing of board Kconfig to mach folders

Do not source xilinx board Kconfig by other boards. These configs should be
available only when Xilinx platforms are selected.

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

arm64: zynqmp: Add board_boot_order for MMC boot extension

In past SPL_ZYNQMP_TWO_SDHCI symbol was introduced to handle boards with
two sdhci controllers. The problem was that U-Boot is registering
controllers based on aliases in DT but bootmode targets specific controller
ID. That's why on boards with one "second" sdhci controller bootmode was
pointing to second controller(MMC2) but alias was setup to mmc0 (the first
controller). And SPL requires to point to mmc0 in this case.

Long time ago commit f101e4bd3703
("spl: add support for alternative boot device") added support for handling
multiple bootmodes in SPL. Use this functionality and setup second sdhci
controller as backup boot device.

Below is table with behavior:
HW/bootmode bootorder
sd0/sd0 mmc0/mmc1 (mmc1 never called)
sd1/sd1 mmc1/mmc0 (mmc0 fails and mmc1 is called)
sd0+sd1/sd0 mmc0/mmc1 (mmc1 never called)
sd0+sd1/sd1 mmc1/mmc0 (mmc0 never called)

All other bootmodes are not affected but order can be extended to cover
advance boot flows.

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

arm64: zynqmp: spl: install a PMU firmware config object at runtime

Optionally allow U-Boot to load a configuration object into the Power
Management Unit (PMU) firmware on Xilinx ZynqMP.

The configuration object is required by the PMU FW to enable most SoC
peripherals. So far the only way to boot using U-Boot SPL was to hard-code
the configuration object in the PMU firmware. Allow a different boot
process, where the PMU FW is equal for any ZynqMP chip and its
configuration is passed at runtime by U-Boot SPL.

All the code for Inter-processor communication with the PMU is isolated in
a new file (pmu_ipc.c). The code is inspired by the same feature as
implemented in the Xilinx First Stage Bootloader (FSBL) and Arm Trusted
Firmware:

* https://github.com/Xilinx/embeddedsw/blob/fb647e6b4c00f5154eba52a88b948195b6f1dc2b/lib/sw_apps/zynqmp_fsbl/src/xfsbl_misc_drivers.c#L295
* https://github.com/ARM-software/arm-trusted-firmware/blob/c48d02bade88b07fa7f43aa44e5217f68e5d047f/plat/xilinx/zynqmp/pm_service/pm_api_sys.c#L357

SPL logs on the console before loading the configuration object:

U-Boot SPL 2019.07-rc1-00511-gaec224515c87 (May 15 2019 - 08:43:41 +0200)
Loading PMUFW cfg obj (2008 bytes)
EL Level: EL3
...

Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

arm64: zynqmp: Fix logic around CONFIG_ZYNQ_SDHCI

Replace SDHCI controller listing by Kconfig symbol to let SPL know that
this board is using multiple SDHCIs controllers.
Kconfig help message should explain why this is needed.
Origin symbols were used in full u-boot but with moving to distro boot
this was fixed already.

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

spl: Kconfig: Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT

Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT so
obj-$(CONFIG_$(SPL_)FS_FAT) can be used to control the build in both
SPL and U-Boot.

Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

arm64: zynqmp: Move SoC sources to mach-zynqmp

Similar changes was done for Zynq in past and this patch just follow
this pattern to separate cpu code from SoC code.

Move arch/arm/cpu/armv8/zynqmp/* -> arch/arm/mach-zynqmp/*
And also fix references to these files.

Based on
"ARM: zynq: move SoC sources to mach-zynq"
(sha1: 0107f2403669f764ab726d0d404e35bb9447bbcc)

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

xilinx: kconfig: Move sourcing of board Kconfig to mach folders

Do not source xilinx board Kconfig by other boards. These configs should be
available only when Xilinx platforms are selected.

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

arm64: zynqmp: Add board_boot_order for MMC boot extension

In past SPL_ZYNQMP_TWO_SDHCI symbol was introduced to handle boards with
two sdhci controllers. The problem was that U-Boot is registering
controllers based on aliases in DT but bootmode targets specific controller
ID. That's why on boards with one "second" sdhci controller bootmode was
pointing to second controller(MMC2) but alias was setup to mmc0 (the first
controller). And SPL requires to point to mmc0 in this case.

Long time ago commit f101e4bd3703
("spl: add support for alternative boot device") added support for handling
multiple bootmodes in SPL. Use this functionality and setup second sdhci
controller as backup boot device.

Below is table with behavior:
HW/bootmode bootorder
sd0/sd0 mmc0/mmc1 (mmc1 never called)
sd1/sd1 mmc1/mmc0 (mmc0 fails and mmc1 is called)
sd0+sd1/sd0 mmc0/mmc1 (mmc1 never called)
sd0+sd1/sd1 mmc1/mmc0 (mmc0 never called)

All other bootmodes are not affected but order can be extended to cover
advance boot flows.

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

arm64: zynqmp: spl: install a PMU firmware config object at runtime

Optionally allow U-Boot to load a configuration object into the Power
Management Unit (PMU) firmware on Xilinx ZynqMP.

The configuration object is required by the PMU FW to enable most SoC
peripherals. So far the only way to boot using U-Boot SPL was to hard-code
the configuration object in the PMU firmware. Allow a different boot
process, where the PMU FW is equal for any ZynqMP chip and its
configuration is passed at runtime by U-Boot SPL.

All the code for Inter-processor communication with the PMU is isolated in
a new file (pmu_ipc.c). The code is inspired by the same feature as
implemented in the Xilinx First Stage Bootloader (FSBL) and Arm Trusted
Firmware:

* https://github.com/Xilinx/embeddedsw/blob/fb647e6b4c00f5154eba52a88b948195b6f1dc2b/lib/sw_apps/zynqmp_fsbl/src/xfsbl_misc_drivers.c#L295
* https://github.com/ARM-software/arm-trusted-firmware/blob/c48d02bade88b07fa7f43aa44e5217f68e5d047f/plat/xilinx/zynqmp/pm_service/pm_api_sys.c#L357

SPL logs on the console before loading the configuration object:

U-Boot SPL 2019.07-rc1-00511-gaec224515c87 (May 15 2019 - 08:43:41 +0200)
Loading PMUFW cfg obj (2008 bytes)
EL Level: EL3
...

Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

arm64: zynqmp: Fix logic around CONFIG_ZYNQ_SDHCI

Replace SDHCI controller listing by Kconfig symbol to let SPL know that
this board is using multiple SDHCIs controllers.
Kconfig help message should explain why this is needed.
Origin symbols were used in full u-boot but with moving to distro boot
this was fixed already.

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

spl: Kconfig: Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT

Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT so
obj-$(CONFIG_$(SPL_)FS_FAT) can be used to control the build in both
SPL and U-Boot.

Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

arm64: zynqmp: Move SoC sources to mach-zynqmp

Similar changes was done for Zynq in past and this patch just follow
this pattern to separate cpu code from SoC code.

Move arch/arm/cpu/armv8/zynqmp/* -> arch/arm/mach-zynqmp/*
And also fix references to these files.

Based on
"ARM: zynq: move SoC sources to mach-zynq"
(sha1: 0107f2403669f764ab726d0d404e35bb9447bbcc)

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

xilinx: kconfig: Move sourcing of board Kconfig to mach folders

Do not source xilinx board Kconfig by other boards. These configs should be
available only when Xilinx platforms are selected.

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

arm64: zynqmp: Add board_boot_order for MMC boot extension

In past SPL_ZYNQMP_TWO_SDHCI symbol was introduced to handle boards with
two sdhci controllers. The problem was that U-Boot is registering
controllers based on aliases in DT but bootmode targets specific controller
ID. That's why on boards with one "second" sdhci controller bootmode was
pointing to second controller(MMC2) but alias was setup to mmc0 (the first
controller). And SPL requires to point to mmc0 in this case.

Long time ago commit f101e4bd3703
("spl: add support for alternative boot device") added support for handling
multiple bootmodes in SPL. Use this functionality and setup second sdhci
controller as backup boot device.

Below is table with behavior:
HW/bootmode bootorder
sd0/sd0 mmc0/mmc1 (mmc1 never called)
sd1/sd1 mmc1/mmc0 (mmc0 fails and mmc1 is called)
sd0+sd1/sd0 mmc0/mmc1 (mmc1 never called)
sd0+sd1/sd1 mmc1/mmc0 (mmc0 never called)

All other bootmodes are not affected but order can be extended to cover
advance boot flows.

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

arm64: zynqmp: spl: install a PMU firmware config object at runtime

Optionally allow U-Boot to load a configuration object into the Power
Management Unit (PMU) firmware on Xilinx ZynqMP.

The configuration object is required by the PMU FW to enable most SoC
peripherals. So far the only way to boot using U-Boot SPL was to hard-code
the configuration object in the PMU firmware. Allow a different boot
process, where the PMU FW is equal for any ZynqMP chip and its
configuration is passed at runtime by U-Boot SPL.

All the code for Inter-processor communication with the PMU is isolated in
a new file (pmu_ipc.c). The code is inspired by the same feature as
implemented in the Xilinx First Stage Bootloader (FSBL) and Arm Trusted
Firmware:

* https://github.com/Xilinx/embeddedsw/blob/fb647e6b4c00f5154eba52a88b948195b6f1dc2b/lib/sw_apps/zynqmp_fsbl/src/xfsbl_misc_drivers.c#L295
* https://github.com/ARM-software/arm-trusted-firmware/blob/c48d02bade88b07fa7f43aa44e5217f68e5d047f/plat/xilinx/zynqmp/pm_service/pm_api_sys.c#L357

SPL logs on the console before loading the configuration object:

U-Boot SPL 2019.07-rc1-00511-gaec224515c87 (May 15 2019 - 08:43:41 +0200)
Loading PMUFW cfg obj (2008 bytes)
EL Level: EL3
...

Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

arm64: zynqmp: Fix logic around CONFIG_ZYNQ_SDHCI

Replace SDHCI controller listing by Kconfig symbol to let SPL know that
this board is using multiple SDHCIs controllers.
Kconfig help message should explain why this is needed.
Origin symbols were used in full u-boot but with moving to distro boot
this was fixed already.

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

spl: Kconfig: Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT

Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT so
obj-$(CONFIG_$(SPL_)FS_FAT) can be used to control the build in both
SPL and U-Boot.

Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

arm64: zynqmp: Move SoC sources to mach-zynqmp

Similar changes was done for Zynq in past and this patch just follow
this pattern to separate cpu code from SoC code.

Move arch/arm/cpu/armv8/zynqmp/* -> arch/arm/mach-zynqmp/*
And also fix references to these files.

Based on
"ARM: zynq: move SoC sources to mach-zynq"
(sha1: 0107f2403669f764ab726d0d404e35bb9447bbcc)

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

xilinx: kconfig: Move sourcing of board Kconfig to mach folders

Do not source xilinx board Kconfig by other boards. These configs should be
available only when Xilinx platforms are selected.

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

arm64: zynqmp: Add board_boot_order for MMC boot extension

In past SPL_ZYNQMP_TWO_SDHCI symbol was introduced to handle boards with
two sdhci controllers. The problem was that U-Boot is registering
controllers based on aliases in DT but bootmode targets specific controller
ID. That's why on boards with one "second" sdhci controller bootmode was
pointing to second controller(MMC2) but alias was setup to mmc0 (the first
controller). And SPL requires to point to mmc0 in this case.

Long time ago commit f101e4bd3703
("spl: add support for alternative boot device") added support for handling
multiple bootmodes in SPL. Use this functionality and setup second sdhci
controller as backup boot device.

Below is table with behavior:
HW/bootmode bootorder
sd0/sd0 mmc0/mmc1 (mmc1 never called)
sd1/sd1 mmc1/mmc0 (mmc0 fails and mmc1 is called)
sd0+sd1/sd0 mmc0/mmc1 (mmc1 never called)
sd0+sd1/sd1 mmc1/mmc0 (mmc0 never called)

All other bootmodes are not affected but order can be extended to cover
advance boot flows.

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

arm64: zynqmp: spl: install a PMU firmware config object at runtime

Optionally allow U-Boot to load a configuration object into the Power
Management Unit (PMU) firmware on Xilinx ZynqMP.

The configuration object is required by the PMU FW to enable most SoC
peripherals. So far the only way to boot using U-Boot SPL was to hard-code
the configuration object in the PMU firmware. Allow a different boot
process, where the PMU FW is equal for any ZynqMP chip and its
configuration is passed at runtime by U-Boot SPL.

All the code for Inter-processor communication with the PMU is isolated in
a new file (pmu_ipc.c). The code is inspired by the same feature as
implemented in the Xilinx First Stage Bootloader (FSBL) and Arm Trusted
Firmware:

* https://github.com/Xilinx/embeddedsw/blob/fb647e6b4c00f5154eba52a88b948195b6f1dc2b/lib/sw_apps/zynqmp_fsbl/src/xfsbl_misc_drivers.c#L295
* https://github.com/ARM-software/arm-trusted-firmware/blob/c48d02bade88b07fa7f43aa44e5217f68e5d047f/plat/xilinx/zynqmp/pm_service/pm_api_sys.c#L357

SPL logs on the console before loading the configuration object:

U-Boot SPL 2019.07-rc1-00511-gaec224515c87 (May 15 2019 - 08:43:41 +0200)
Loading PMUFW cfg obj (2008 bytes)
EL Level: EL3
...

Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

arm64: zynqmp: Fix logic around CONFIG_ZYNQ_SDHCI

Replace SDHCI controller listing by Kconfig symbol to let SPL know that
this board is using multiple SDHCIs controllers.
Kconfig help message should explain why this is needed.
Origin symbols were used in full u-boot but with moving to distro boot
this was fixed already.

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

spl: Kconfig: Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT

Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT so
obj-$(CONFIG_$(SPL_)FS_FAT) can be used to control the build in both
SPL and U-Boot.

Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

arm64: zynqmp: Move SoC sources to mach-zynqmp

Similar changes was done for Zynq in past and this patch just follow
this pattern to separate cpu code from SoC code.

Move arch/arm/cpu/armv8/zynqmp/* -> arch/arm/mach-zynqmp/*
And also fix references to these files.

Based on
"ARM: zynq: move SoC sources to mach-zynq"
(sha1: 0107f2403669f764ab726d0d404e35bb9447bbcc)

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

xilinx: kconfig: Move sourcing of board Kconfig to mach folders

Do not source xilinx board Kconfig by other boards. These configs should be
available only when Xilinx platforms are selected.

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

arm64: zynqmp: Add board_boot_order for MMC boot extension

In past SPL_ZYNQMP_TWO_SDHCI symbol was introduced to handle boards with
two sdhci controllers. The problem was that U-Boot is registering
controllers based on aliases in DT but bootmode targets specific controller
ID. That's why on boards with one "second" sdhci controller bootmode was
pointing to second controller(MMC2) but alias was setup to mmc0 (the first
controller). And SPL requires to point to mmc0 in this case.

Long time ago commit f101e4bd3703
("spl: add support for alternative boot device") added support for handling
multiple bootmodes in SPL. Use this functionality and setup second sdhci
controller as backup boot device.

Below is table with behavior:
HW/bootmode bootorder
sd0/sd0 mmc0/mmc1 (mmc1 never called)
sd1/sd1 mmc1/mmc0 (mmc0 fails and mmc1 is called)
sd0+sd1/sd0 mmc0/mmc1 (mmc1 never called)
sd0+sd1/sd1 mmc1/mmc0 (mmc0 never called)

All other bootmodes are not affected but order can be extended to cover
advance boot flows.

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

arm64: zynqmp: spl: install a PMU firmware config object at runtime

Optionally allow U-Boot to load a configuration object into the Power
Management Unit (PMU) firmware on Xilinx ZynqMP.

The configuration object is required by the PMU FW to enable most SoC
peripherals. So far the only way to boot using U-Boot SPL was to hard-code
the configuration object in the PMU firmware. Allow a different boot
process, where the PMU FW is equal for any ZynqMP chip and its
configuration is passed at runtime by U-Boot SPL.

All the code for Inter-processor communication with the PMU is isolated in
a new file (pmu_ipc.c). The code is inspired by the same feature as
implemented in the Xilinx First Stage Bootloader (FSBL) and Arm Trusted
Firmware:

* https://github.com/Xilinx/embeddedsw/blob/fb647e6b4c00f5154eba52a88b948195b6f1dc2b/lib/sw_apps/zynqmp_fsbl/src/xfsbl_misc_drivers.c#L295
* https://github.com/ARM-software/arm-trusted-firmware/blob/c48d02bade88b07fa7f43aa44e5217f68e5d047f/plat/xilinx/zynqmp/pm_service/pm_api_sys.c#L357

SPL logs on the console before loading the configuration object:

U-Boot SPL 2019.07-rc1-00511-gaec224515c87 (May 15 2019 - 08:43:41 +0200)
Loading PMUFW cfg obj (2008 bytes)
EL Level: EL3
...

Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

arm64: zynqmp: Fix logic around CONFIG_ZYNQ_SDHCI

Replace SDHCI controller listing by Kconfig symbol to let SPL know that
this board is using multiple SDHCIs controllers.
Kconfig help message should explain why this is needed.
Origin symbols were used in full u-boot but with moving to distro boot
this was fixed already.

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

spl: Kconfig: Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT

Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT so
obj-$(CONFIG_$(SPL_)FS_FAT) can be used to control the build in both
SPL and U-Boot.

Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

arm64: zynqmp: Move SoC sources to mach-zynqmp

Similar changes was done for Zynq in past and this patch just follow
this pattern to separate cpu code from SoC code.

Move arch/arm/cpu/armv8/zynqmp/* -> arch/arm/mach-zynqmp/*
And also fix references to these files.

Based on
"ARM: zynq: move SoC sources to mach-zynq"
(sha1: 0107f2403669f764ab726d0d404e35bb9447bbcc)

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

xilinx: kconfig: Move sourcing of board Kconfig to mach folders

Do not source xilinx board Kconfig by other boards. These configs should be
available only when Xilinx platforms are selected.

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

arm64: zynqmp: Add board_boot_order for MMC boot extension

In past SPL_ZYNQMP_TWO_SDHCI symbol was introduced to handle boards with
two sdhci controllers. The problem was that U-Boot is registering
controllers based on aliases in DT but bootmode targets specific controller
ID. That's why on boards with one "second" sdhci controller bootmode was
pointing to second controller(MMC2) but alias was setup to mmc0 (the first
controller). And SPL requires to point to mmc0 in this case.

Long time ago commit f101e4bd3703
("spl: add support for alternative boot device") added support for handling
multiple bootmodes in SPL. Use this functionality and setup second sdhci
controller as backup boot device.

Below is table with behavior:
HW/bootmode bootorder
sd0/sd0 mmc0/mmc1 (mmc1 never called)
sd1/sd1 mmc1/mmc0 (mmc0 fails and mmc1 is called)
sd0+sd1/sd0 mmc0/mmc1 (mmc1 never called)
sd0+sd1/sd1 mmc1/mmc0 (mmc0 never called)

All other bootmodes are not affected but order can be extended to cover
advance boot flows.

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

arm64: zynqmp: spl: install a PMU firmware config object at runtime

Optionally allow U-Boot to load a configuration object into the Power
Management Unit (PMU) firmware on Xilinx ZynqMP.

The configuration object is required by the PMU FW to enable most SoC
peripherals. So far the only way to boot using U-Boot SPL was to hard-code
the configuration object in the PMU firmware. Allow a different boot
process, where the PMU FW is equal for any ZynqMP chip and its
configuration is passed at runtime by U-Boot SPL.

All the code for Inter-processor communication with the PMU is isolated in
a new file (pmu_ipc.c). The code is inspired by the same feature as
implemented in the Xilinx First Stage Bootloader (FSBL) and Arm Trusted
Firmware:

* https://github.com/Xilinx/embeddedsw/blob/fb647e6b4c00f5154eba52a88b948195b6f1dc2b/lib/sw_apps/zynqmp_fsbl/src/xfsbl_misc_drivers.c#L295
* https://github.com/ARM-software/arm-trusted-firmware/blob/c48d02bade88b07fa7f43aa44e5217f68e5d047f/plat/xilinx/zynqmp/pm_service/pm_api_sys.c#L357

SPL logs on the console before loading the configuration object:

U-Boot SPL 2019.07-rc1-00511-gaec224515c87 (May 15 2019 - 08:43:41 +0200)
Loading PMUFW cfg obj (2008 bytes)
EL Level: EL3
...

Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

arm64: zynqmp: Fix logic around CONFIG_ZYNQ_SDHCI

Replace SDHCI controller listing by Kconfig symbol to let SPL know that
this board is using multiple SDHCIs controllers.
Kconfig help message should explain why this is needed.
Origin symbols were used in full u-boot but with moving to distro boot
this was fixed already.

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

spl: Kconfig: Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT

Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT so
obj-$(CONFIG_$(SPL_)FS_FAT) can be used to control the build in both
SPL and U-Boot.

Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

arm64: zynqmp: Move SoC sources to mach-zynqmp

Similar changes was done for Zynq in past and this patch just follow
this pattern to separate cpu code from SoC code.

Move arch/arm/cpu/armv8/zynqmp/* -> arch/arm/mach-zynqmp/*
And also fix references to these files.

Based on
"ARM: zynq: move SoC sources to mach-zynq"
(sha1: 0107f2403669f764ab726d0d404e35bb9447bbcc)

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

xilinx: kconfig: Move sourcing of board Kconfig to mach folders

Do not source xilinx board Kconfig by other boards. These configs should be
available only when Xilinx platforms are selected.

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

arm64: zynqmp: Add board_boot_order for MMC boot extension

In past SPL_ZYNQMP_TWO_SDHCI symbol was introduced to handle boards with
two sdhci controllers. The problem was that U-Boot is registering
controllers based on aliases in DT but bootmode targets specific controller
ID. That's why on boards with one "second" sdhci controller bootmode was
pointing to second controller(MMC2) but alias was setup to mmc0 (the first
controller). And SPL requires to point to mmc0 in this case.

Long time ago commit f101e4bd3703
("spl: add support for alternative boot device") added support for handling
multiple bootmodes in SPL. Use this functionality and setup second sdhci
controller as backup boot device.

Below is table with behavior:
HW/bootmode bootorder
sd0/sd0 mmc0/mmc1 (mmc1 never called)
sd1/sd1 mmc1/mmc0 (mmc0 fails and mmc1 is called)
sd0+sd1/sd0 mmc0/mmc1 (mmc1 never called)
sd0+sd1/sd1 mmc1/mmc0 (mmc0 never called)

All other bootmodes are not affected but order can be extended to cover
advance boot flows.

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

arm64: zynqmp: spl: install a PMU firmware config object at runtime

Optionally allow U-Boot to load a configuration object into the Power
Management Unit (PMU) firmware on Xilinx ZynqMP.

The configuration object is required by the PMU FW to enable most SoC
peripherals. So far the only way to boot using U-Boot SPL was to hard-code
the configuration object in the PMU firmware. Allow a different boot
process, where the PMU FW is equal for any ZynqMP chip and its
configuration is passed at runtime by U-Boot SPL.

All the code for Inter-processor communication with the PMU is isolated in
a new file (pmu_ipc.c). The code is inspired by the same feature as
implemented in the Xilinx First Stage Bootloader (FSBL) and Arm Trusted
Firmware:

* https://github.com/Xilinx/embeddedsw/blob/fb647e6b4c00f5154eba52a88b948195b6f1dc2b/lib/sw_apps/zynqmp_fsbl/src/xfsbl_misc_drivers.c#L295
* https://github.com/ARM-software/arm-trusted-firmware/blob/c48d02bade88b07fa7f43aa44e5217f68e5d047f/plat/xilinx/zynqmp/pm_service/pm_api_sys.c#L357

SPL logs on the console before loading the configuration object:

U-Boot SPL 2019.07-rc1-00511-gaec224515c87 (May 15 2019 - 08:43:41 +0200)
Loading PMUFW cfg obj (2008 bytes)
EL Level: EL3
...

Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

arm64: zynqmp: Fix logic around CONFIG_ZYNQ_SDHCI

Replace SDHCI controller listing by Kconfig symbol to let SPL know that
this board is using multiple SDHCIs controllers.
Kconfig help message should explain why this is needed.
Origin symbols were used in full u-boot but with moving to distro boot
this was fixed already.

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

spl: Kconfig: Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT

Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT so
obj-$(CONFIG_$(SPL_)FS_FAT) can be used to control the build in both
SPL and U-Boot.

Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

arm64: zynqmp: Move SoC sources to mach-zynqmp

Similar changes was done for Zynq in past and this patch just follow
this pattern to separate cpu code from SoC code.

Move arch/arm/cpu/armv8/zynqmp/* -> arch/arm/mach-zynqmp/*
And also fix references to these files.

Based on
"ARM: zynq: move SoC sources to mach-zynq"
(sha1: 0107f2403669f764ab726d0d404e35bb9447bbcc)

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

xilinx: kconfig: Move sourcing of board Kconfig to mach folders

Do not source xilinx board Kconfig by other boards. These configs should be
available only when Xilinx platforms are selected.

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

arm64: zynqmp: Add board_boot_order for MMC boot extension

In past SPL_ZYNQMP_TWO_SDHCI symbol was introduced to handle boards with
two sdhci controllers. The problem was that U-Boot is registering
controllers based on aliases in DT but bootmode targets specific controller
ID. That's why on boards with one "second" sdhci controller bootmode was
pointing to second controller(MMC2) but alias was setup to mmc0 (the first
controller). And SPL requires to point to mmc0 in this case.

Long time ago commit f101e4bd3703
("spl: add support for alternative boot device") added support for handling
multiple bootmodes in SPL. Use this functionality and setup second sdhci
controller as backup boot device.

Below is table with behavior:
HW/bootmode bootorder
sd0/sd0 mmc0/mmc1 (mmc1 never called)
sd1/sd1 mmc1/mmc0 (mmc0 fails and mmc1 is called)
sd0+sd1/sd0 mmc0/mmc1 (mmc1 never called)
sd0+sd1/sd1 mmc1/mmc0 (mmc0 never called)

All other bootmodes are not affected but order can be extended to cover
advance boot flows.

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

arm64: zynqmp: spl: install a PMU firmware config object at runtime

Optionally allow U-Boot to load a configuration object into the Power
Management Unit (PMU) firmware on Xilinx ZynqMP.

The configuration object is required by the PMU FW to enable most SoC
peripherals. So far the only way to boot using U-Boot SPL was to hard-code
the configuration object in the PMU firmware. Allow a different boot
process, where the PMU FW is equal for any ZynqMP chip and its
configuration is passed at runtime by U-Boot SPL.

All the code for Inter-processor communication with the PMU is isolated in
a new file (pmu_ipc.c). The code is inspired by the same feature as
implemented in the Xilinx First Stage Bootloader (FSBL) and Arm Trusted
Firmware:

* https://github.com/Xilinx/embeddedsw/blob/fb647e6b4c00f5154eba52a88b948195b6f1dc2b/lib/sw_apps/zynqmp_fsbl/src/xfsbl_misc_drivers.c#L295
* https://github.com/ARM-software/arm-trusted-firmware/blob/c48d02bade88b07fa7f43aa44e5217f68e5d047f/plat/xilinx/zynqmp/pm_service/pm_api_sys.c#L357

SPL logs on the console before loading the configuration object:

U-Boot SPL 2019.07-rc1-00511-gaec224515c87 (May 15 2019 - 08:43:41 +0200)
Loading PMUFW cfg obj (2008 bytes)
EL Level: EL3
...

Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

arm64: zynqmp: Fix logic around CONFIG_ZYNQ_SDHCI

Replace SDHCI controller listing by Kconfig symbol to let SPL know that
this board is using multiple SDHCIs controllers.
Kconfig help message should explain why this is needed.
Origin symbols were used in full u-boot but with moving to distro boot
this was fixed already.

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

spl: Kconfig: Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT

Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT so
obj-$(CONFIG_$(SPL_)FS_FAT) can be used to control the build in both
SPL and U-Boot.

Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

arm64: zynqmp: Move SoC sources to mach-zynqmp

Similar changes was done for Zynq in past and this patch just follow
this pattern to separate cpu code from SoC code.

Move arch/arm/cpu/armv8/zynqmp/* -> arch/arm/mach-zynqmp/*
And also fix references to these files.

Based on
"ARM: zynq: move SoC sources to mach-zynq"
(sha1: 0107f2403669f764ab726d0d404e35bb9447bbcc)

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

xilinx: kconfig: Move sourcing of board Kconfig to mach folders

Do not source xilinx board Kconfig by other boards. These configs should be
available only when Xilinx platforms are selected.

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

arm64: zynqmp: Add board_boot_order for MMC boot extension

In past SPL_ZYNQMP_TWO_SDHCI symbol was introduced to handle boards with
two sdhci controllers. The problem was that U-Boot is registering
controllers based on aliases in DT but bootmode targets specific controller
ID. That's why on boards with one "second" sdhci controller bootmode was
pointing to second controller(MMC2) but alias was setup to mmc0 (the first
controller). And SPL requires to point to mmc0 in this case.

Long time ago commit f101e4bd3703
("spl: add support for alternative boot device") added support for handling
multiple bootmodes in SPL. Use this functionality and setup second sdhci
controller as backup boot device.

Below is table with behavior:
HW/bootmode bootorder
sd0/sd0 mmc0/mmc1 (mmc1 never called)
sd1/sd1 mmc1/mmc0 (mmc0 fails and mmc1 is called)
sd0+sd1/sd0 mmc0/mmc1 (mmc1 never called)
sd0+sd1/sd1 mmc1/mmc0 (mmc0 never called)

All other bootmodes are not affected but order can be extended to cover
advance boot flows.

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

arm64: zynqmp: spl: install a PMU firmware config object at runtime

Optionally allow U-Boot to load a configuration object into the Power
Management Unit (PMU) firmware on Xilinx ZynqMP.

The configuration object is required by the PMU FW to enable most SoC
peripherals. So far the only way to boot using U-Boot SPL was to hard-code
the configuration object in the PMU firmware. Allow a different boot
process, where the PMU FW is equal for any ZynqMP chip and its
configuration is passed at runtime by U-Boot SPL.

All the code for Inter-processor communication with the PMU is isolated in
a new file (pmu_ipc.c). The code is inspired by the same feature as
implemented in the Xilinx First Stage Bootloader (FSBL) and Arm Trusted
Firmware:

* https://github.com/Xilinx/embeddedsw/blob/fb647e6b4c00f5154eba52a88b948195b6f1dc2b/lib/sw_apps/zynqmp_fsbl/src/xfsbl_misc_drivers.c#L295
* https://github.com/ARM-software/arm-trusted-firmware/blob/c48d02bade88b07fa7f43aa44e5217f68e5d047f/plat/xilinx/zynqmp/pm_service/pm_api_sys.c#L357

SPL logs on the console before loading the configuration object:

U-Boot SPL 2019.07-rc1-00511-gaec224515c87 (May 15 2019 - 08:43:41 +0200)
Loading PMUFW cfg obj (2008 bytes)
EL Level: EL3
...

Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

arm64: zynqmp: Fix logic around CONFIG_ZYNQ_SDHCI

Replace SDHCI controller listing by Kconfig symbol to let SPL know that
this board is using multiple SDHCIs controllers.
Kconfig help message should explain why this is needed.
Origin symbols were used in full u-boot but with moving to distro boot
this was fixed already.

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

spl: Kconfig: Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT

Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT so
obj-$(CONFIG_$(SPL_)FS_FAT) can be used to control the build in both
SPL and U-Boot.

Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

arm64: zynqmp: Move SoC sources to mach-zynqmp

Similar changes was done for Zynq in past and this patch just follow
this pattern to separate cpu code from SoC code.

Move arch/arm/cpu/armv8/zynqmp/* -> arch/arm/mach-zynqmp/*
And also fix references to these files.

Based on
"ARM: zynq: move SoC sources to mach-zynq"
(sha1: 0107f2403669f764ab726d0d404e35bb9447bbcc)

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

xilinx: kconfig: Move sourcing of board Kconfig to mach folders

Do not source xilinx board Kconfig by other boards. These configs should be
available only when Xilinx platforms are selected.

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

arm64: zynqmp: Add board_boot_order for MMC boot extension

In past SPL_ZYNQMP_TWO_SDHCI symbol was introduced to handle boards with
two sdhci controllers. The problem was that U-Boot is registering
controllers based on aliases in DT but bootmode targets specific controller
ID. That's why on boards with one "second" sdhci controller bootmode was
pointing to second controller(MMC2) but alias was setup to mmc0 (the first
controller). And SPL requires to point to mmc0 in this case.

Long time ago commit f101e4bd3703
("spl: add support for alternative boot device") added support for handling
multiple bootmodes in SPL. Use this functionality and setup second sdhci
controller as backup boot device.

Below is table with behavior:
HW/bootmode bootorder
sd0/sd0 mmc0/mmc1 (mmc1 never called)
sd1/sd1 mmc1/mmc0 (mmc0 fails and mmc1 is called)
sd0+sd1/sd0 mmc0/mmc1 (mmc1 never called)
sd0+sd1/sd1 mmc1/mmc0 (mmc0 never called)

All other bootmodes are not affected but order can be extended to cover
advance boot flows.

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

arm64: zynqmp: spl: install a PMU firmware config object at runtime

Optionally allow U-Boot to load a configuration object into the Power
Management Unit (PMU) firmware on Xilinx ZynqMP.

The configuration object is required by the PMU FW to enable most SoC
peripherals. So far the only way to boot using U-Boot SPL was to hard-code
the configuration object in the PMU firmware. Allow a different boot
process, where the PMU FW is equal for any ZynqMP chip and its
configuration is passed at runtime by U-Boot SPL.

All the code for Inter-processor communication with the PMU is isolated in
a new file (pmu_ipc.c). The code is inspired by the same feature as
implemented in the Xilinx First Stage Bootloader (FSBL) and Arm Trusted
Firmware:

* https://github.com/Xilinx/embeddedsw/blob/fb647e6b4c00f5154eba52a88b948195b6f1dc2b/lib/sw_apps/zynqmp_fsbl/src/xfsbl_misc_drivers.c#L295
* https://github.com/ARM-software/arm-trusted-firmware/blob/c48d02bade88b07fa7f43aa44e5217f68e5d047f/plat/xilinx/zynqmp/pm_service/pm_api_sys.c#L357

SPL logs on the console before loading the configuration object:

U-Boot SPL 2019.07-rc1-00511-gaec224515c87 (May 15 2019 - 08:43:41 +0200)
Loading PMUFW cfg obj (2008 bytes)
EL Level: EL3
...

Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

arm64: zynqmp: Fix logic around CONFIG_ZYNQ_SDHCI

Replace SDHCI controller listing by Kconfig symbol to let SPL know that
this board is using multiple SDHCIs controllers.
Kconfig help message should explain why this is needed.
Origin symbols were used in full u-boot but with moving to distro boot
this was fixed already.

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

spl: Kconfig: Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT

Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT so
obj-$(CONFIG_$(SPL_)FS_FAT) can be used to control the build in both
SPL and U-Boot.

Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

arm64: zynqmp: Move SoC sources to mach-zynqmp

Similar changes was done for Zynq in past and this patch just follow
this pattern to separate cpu code from SoC code.

Move arch/arm/cpu/armv8/zynqmp/* -> arch/arm/mach-zynqmp/*
And also fix references to these files.

Based on
"ARM: zynq: move SoC sources to mach-zynq"
(sha1: 0107f2403669f764ab726d0d404e35bb9447bbcc)

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

xilinx: kconfig: Move sourcing of board Kconfig to mach folders

Do not source xilinx board Kconfig by other boards. These configs should be
available only when Xilinx platforms are selected.

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

arm64: zynqmp: Add board_boot_order for MMC boot extension

In past SPL_ZYNQMP_TWO_SDHCI symbol was introduced to handle boards with
two sdhci controllers. The problem was that U-Boot is registering
controllers based on aliases in DT but bootmode targets specific controller
ID. That's why on boards with one "second" sdhci controller bootmode was
pointing to second controller(MMC2) but alias was setup to mmc0 (the first
controller). And SPL requires to point to mmc0 in this case.

Long time ago commit f101e4bd3703
("spl: add support for alternative boot device") added support for handling
multiple bootmodes in SPL. Use this functionality and setup second sdhci
controller as backup boot device.

Below is table with behavior:
HW/bootmode bootorder
sd0/sd0 mmc0/mmc1 (mmc1 never called)
sd1/sd1 mmc1/mmc0 (mmc0 fails and mmc1 is called)
sd0+sd1/sd0 mmc0/mmc1 (mmc1 never called)
sd0+sd1/sd1 mmc1/mmc0 (mmc0 never called)

All other bootmodes are not affected but order can be extended to cover
advance boot flows.

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

arm64: zynqmp: spl: install a PMU firmware config object at runtime

Optionally allow U-Boot to load a configuration object into the Power
Management Unit (PMU) firmware on Xilinx ZynqMP.

The configuration object is required by the PMU FW to enable most SoC
peripherals. So far the only way to boot using U-Boot SPL was to hard-code
the configuration object in the PMU firmware. Allow a different boot
process, where the PMU FW is equal for any ZynqMP chip and its
configuration is passed at runtime by U-Boot SPL.

All the code for Inter-processor communication with the PMU is isolated in
a new file (pmu_ipc.c). The code is inspired by the same feature as
implemented in the Xilinx First Stage Bootloader (FSBL) and Arm Trusted
Firmware:

* https://github.com/Xilinx/embeddedsw/blob/fb647e6b4c00f5154eba52a88b948195b6f1dc2b/lib/sw_apps/zynqmp_fsbl/src/xfsbl_misc_drivers.c#L295
* https://github.com/ARM-software/arm-trusted-firmware/blob/c48d02bade88b07fa7f43aa44e5217f68e5d047f/plat/xilinx/zynqmp/pm_service/pm_api_sys.c#L357

SPL logs on the console before loading the configuration object:

U-Boot SPL 2019.07-rc1-00511-gaec224515c87 (May 15 2019 - 08:43:41 +0200)
Loading PMUFW cfg obj (2008 bytes)
EL Level: EL3
...

Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

arm64: zynqmp: Fix logic around CONFIG_ZYNQ_SDHCI

Replace SDHCI controller listing by Kconfig symbol to let SPL know that
this board is using multiple SDHCIs controllers.
Kconfig help message should explain why this is needed.
Origin symbols were used in full u-boot but with moving to distro boot
this was fixed already.

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

spl: Kconfig: Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT

Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT so
obj-$(CONFIG_$(SPL_)FS_FAT) can be used to control the build in both
SPL and U-Boot.

Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

arm64: zynqmp: Move SoC sources to mach-zynqmp

Similar changes was done for Zynq in past and this patch just follow
this pattern to separate cpu code from SoC code.

Move arch/arm/cpu/armv8/zynqmp/* -> arch/arm/mach-zynqmp/*
And also fix references to these files.

Based on
"ARM: zynq: move SoC sources to mach-zynq"
(sha1: 0107f2403669f764ab726d0d404e35bb9447bbcc)

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

xilinx: kconfig: Move sourcing of board Kconfig to mach folders

Do not source xilinx board Kconfig by other boards. These configs should be
available only when Xilinx platforms are selected.

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

arm64: zynqmp: Add board_boot_order for MMC boot extension

In past SPL_ZYNQMP_TWO_SDHCI symbol was introduced to handle boards with
two sdhci controllers. The problem was that U-Boot is registering
controllers based on aliases in DT but bootmode targets specific controller
ID. That's why on boards with one "second" sdhci controller bootmode was
pointing to second controller(MMC2) but alias was setup to mmc0 (the first
controller). And SPL requires to point to mmc0 in this case.

Long time ago commit f101e4bd3703
("spl: add support for alternative boot device") added support for handling
multiple bootmodes in SPL. Use this functionality and setup second sdhci
controller as backup boot device.

Below is table with behavior:
HW/bootmode bootorder
sd0/sd0 mmc0/mmc1 (mmc1 never called)
sd1/sd1 mmc1/mmc0 (mmc0 fails and mmc1 is called)
sd0+sd1/sd0 mmc0/mmc1 (mmc1 never called)
sd0+sd1/sd1 mmc1/mmc0 (mmc0 never called)

All other bootmodes are not affected but order can be extended to cover
advance boot flows.

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

arm64: zynqmp: spl: install a PMU firmware config object at runtime

Optionally allow U-Boot to load a configuration object into the Power
Management Unit (PMU) firmware on Xilinx ZynqMP.

The configuration object is required by the PMU FW to enable most SoC
peripherals. So far the only way to boot using U-Boot SPL was to hard-code
the configuration object in the PMU firmware. Allow a different boot
process, where the PMU FW is equal for any ZynqMP chip and its
configuration is passed at runtime by U-Boot SPL.

All the code for Inter-processor communication with the PMU is isolated in
a new file (pmu_ipc.c). The code is inspired by the same feature as
implemented in the Xilinx First Stage Bootloader (FSBL) and Arm Trusted
Firmware:

* https://github.com/Xilinx/embeddedsw/blob/fb647e6b4c00f5154eba52a88b948195b6f1dc2b/lib/sw_apps/zynqmp_fsbl/src/xfsbl_misc_drivers.c#L295
* https://github.com/ARM-software/arm-trusted-firmware/blob/c48d02bade88b07fa7f43aa44e5217f68e5d047f/plat/xilinx/zynqmp/pm_service/pm_api_sys.c#L357

SPL logs on the console before loading the configuration object:

U-Boot SPL 2019.07-rc1-00511-gaec224515c87 (May 15 2019 - 08:43:41 +0200)
Loading PMUFW cfg obj (2008 bytes)
EL Level: EL3
...

Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

arm64: zynqmp: Fix logic around CONFIG_ZYNQ_SDHCI

Replace SDHCI controller listing by Kconfig symbol to let SPL know that
this board is using multiple SDHCIs controllers.
Kconfig help message should explain why this is needed.
Origin symbols were used in full u-boot but with moving to distro boot
this was fixed already.

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

spl: Kconfig: Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT

Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT so
obj-$(CONFIG_$(SPL_)FS_FAT) can be used to control the build in both
SPL and U-Boot.

Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

arm64: zynqmp: Move SoC sources to mach-zynqmp

Similar changes was done for Zynq in past and this patch just follow
this pattern to separate cpu code from SoC code.

Move arch/arm/cpu/armv8/zynqmp/* -> arch/arm/mach-zynqmp/*
And also fix references to these files.

Based on
"ARM: zynq: move SoC sources to mach-zynq"
(sha1: 0107f2403669f764ab726d0d404e35bb9447bbcc)

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

xilinx: kconfig: Move sourcing of board Kconfig to mach folders

Do not source xilinx board Kconfig by other boards. These configs should be
available only when Xilinx platforms are selected.

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

arm64: zynqmp: Add board_boot_order for MMC boot extension

In past SPL_ZYNQMP_TWO_SDHCI symbol was introduced to handle boards with
two sdhci controllers. The problem was that U-Boot is registering
controllers based on aliases in DT but bootmode targets specific controller
ID. That's why on boards with one "second" sdhci controller bootmode was
pointing to second controller(MMC2) but alias was setup to mmc0 (the first
controller). And SPL requires to point to mmc0 in this case.

Long time ago commit f101e4bd3703
("spl: add support for alternative boot device") added support for handling
multiple bootmodes in SPL. Use this functionality and setup second sdhci
controller as backup boot device.

Below is table with behavior:
HW/bootmode bootorder
sd0/sd0 mmc0/mmc1 (mmc1 never called)
sd1/sd1 mmc1/mmc0 (mmc0 fails and mmc1 is called)
sd0+sd1/sd0 mmc0/mmc1 (mmc1 never called)
sd0+sd1/sd1 mmc1/mmc0 (mmc0 never called)

All other bootmodes are not affected but order can be extended to cover
advance boot flows.

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

arm64: zynqmp: spl: install a PMU firmware config object at runtime

Optionally allow U-Boot to load a configuration object into the Power
Management Unit (PMU) firmware on Xilinx ZynqMP.

The configuration object is required by the PMU FW to enable most SoC
peripherals. So far the only way to boot using U-Boot SPL was to hard-code
the configuration object in the PMU firmware. Allow a different boot
process, where the PMU FW is equal for any ZynqMP chip and its
configuration is passed at runtime by U-Boot SPL.

All the code for Inter-processor communication with the PMU is isolated in
a new file (pmu_ipc.c). The code is inspired by the same feature as
implemented in the Xilinx First Stage Bootloader (FSBL) and Arm Trusted
Firmware:

* https://github.com/Xilinx/embeddedsw/blob/fb647e6b4c00f5154eba52a88b948195b6f1dc2b/lib/sw_apps/zynqmp_fsbl/src/xfsbl_misc_drivers.c#L295
* https://github.com/ARM-software/arm-trusted-firmware/blob/c48d02bade88b07fa7f43aa44e5217f68e5d047f/plat/xilinx/zynqmp/pm_service/pm_api_sys.c#L357

SPL logs on the console before loading the configuration object:

U-Boot SPL 2019.07-rc1-00511-gaec224515c87 (May 15 2019 - 08:43:41 +0200)
Loading PMUFW cfg obj (2008 bytes)
EL Level: EL3
...

Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

arm64: zynqmp: Fix logic around CONFIG_ZYNQ_SDHCI

Replace SDHCI controller listing by Kconfig symbol to let SPL know that
this board is using multiple SDHCIs controllers.
Kconfig help message should explain why this is needed.
Origin symbols were used in full u-boot but with moving to distro boot
this was fixed already.

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

spl: Kconfig: Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT

Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT so
obj-$(CONFIG_$(SPL_)FS_FAT) can be used to control the build in both
SPL and U-Boot.

Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

arm64: zynqmp: Move SoC sources to mach-zynqmp

Similar changes was done for Zynq in past and this patch just follow
this pattern to separate cpu code from SoC code.

Move arch/arm/cpu/armv8/zynqmp/* -> arch/arm/mach-zynqmp/*
And also fix references to these files.

Based on
"ARM: zynq: move SoC sources to mach-zynq"
(sha1: 0107f2403669f764ab726d0d404e35bb9447bbcc)

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

xilinx: kconfig: Move sourcing of board Kconfig to mach folders

Do not source xilinx board Kconfig by other boards. These configs should be
available only when Xilinx platforms are selected.

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

arm64: zynqmp: Add board_boot_order for MMC boot extension

In past SPL_ZYNQMP_TWO_SDHCI symbol was introduced to handle boards with
two sdhci controllers. The problem was that U-Boot is registering
controllers based on aliases in DT but bootmode targets specific controller
ID. That's why on boards with one "second" sdhci controller bootmode was
pointing to second controller(MMC2) but alias was setup to mmc0 (the first
controller). And SPL requires to point to mmc0 in this case.

Long time ago commit f101e4bd3703
("spl: add support for alternative boot device") added support for handling
multiple bootmodes in SPL. Use this functionality and setup second sdhci
controller as backup boot device.

Below is table with behavior:
HW/bootmode bootorder
sd0/sd0 mmc0/mmc1 (mmc1 never called)
sd1/sd1 mmc1/mmc0 (mmc0 fails and mmc1 is called)
sd0+sd1/sd0 mmc0/mmc1 (mmc1 never called)
sd0+sd1/sd1 mmc1/mmc0 (mmc0 never called)

All other bootmodes are not affected but order can be extended to cover
advance boot flows.

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

arm64: zynqmp: spl: install a PMU firmware config object at runtime

Optionally allow U-Boot to load a configuration object into the Power
Management Unit (PMU) firmware on Xilinx ZynqMP.

The configuration object is required by the PMU FW to enable most SoC
peripherals. So far the only way to boot using U-Boot SPL was to hard-code
the configuration object in the PMU firmware. Allow a different boot
process, where the PMU FW is equal for any ZynqMP chip and its
configuration is passed at runtime by U-Boot SPL.

All the code for Inter-processor communication with the PMU is isolated in
a new file (pmu_ipc.c). The code is inspired by the same feature as
implemented in the Xilinx First Stage Bootloader (FSBL) and Arm Trusted
Firmware:

* https://github.com/Xilinx/embeddedsw/blob/fb647e6b4c00f5154eba52a88b948195b6f1dc2b/lib/sw_apps/zynqmp_fsbl/src/xfsbl_misc_drivers.c#L295
* https://github.com/ARM-software/arm-trusted-firmware/blob/c48d02bade88b07fa7f43aa44e5217f68e5d047f/plat/xilinx/zynqmp/pm_service/pm_api_sys.c#L357

SPL logs on the console before loading the configuration object:

U-Boot SPL 2019.07-rc1-00511-gaec224515c87 (May 15 2019 - 08:43:41 +0200)
Loading PMUFW cfg obj (2008 bytes)
EL Level: EL3
...

Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

arm64: zynqmp: Fix logic around CONFIG_ZYNQ_SDHCI

Replace SDHCI controller listing by Kconfig symbol to let SPL know that
this board is using multiple SDHCIs controllers.
Kconfig help message should explain why this is needed.
Origin symbols were used in full u-boot but with moving to distro boot
this was fixed already.

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

spl: Kconfig: Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT

Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT so
obj-$(CONFIG_$(SPL_)FS_FAT) can be used to control the build in both
SPL and U-Boot.

Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

arm64: zynqmp: Move SoC sources to mach-zynqmp

Similar changes was done for Zynq in past and this patch just follow
this pattern to separate cpu code from SoC code.

Move arch/arm/cpu/armv8/zynqmp/* -> arch/arm/mach-zynqmp/*
And also fix references to these files.

Based on
"ARM: zynq: move SoC sources to mach-zynq"
(sha1: 0107f2403669f764ab726d0d404e35bb9447bbcc)

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

xilinx: kconfig: Move sourcing of board Kconfig to mach folders

Do not source xilinx board Kconfig by other boards. These configs should be
available only when Xilinx platforms are selected.

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

arm64: zynqmp: Add board_boot_order for MMC boot extension

In past SPL_ZYNQMP_TWO_SDHCI symbol was introduced to handle boards with
two sdhci controllers. The problem was that U-Boot is registering
controllers based on aliases in DT but bootmode targets specific controller
ID. That's why on boards with one "second" sdhci controller bootmode was
pointing to second controller(MMC2) but alias was setup to mmc0 (the first
controller). And SPL requires to point to mmc0 in this case.

Long time ago commit f101e4bd3703
("spl: add support for alternative boot device") added support for handling
multiple bootmodes in SPL. Use this functionality and setup second sdhci
controller as backup boot device.

Below is table with behavior:
HW/bootmode bootorder
sd0/sd0 mmc0/mmc1 (mmc1 never called)
sd1/sd1 mmc1/mmc0 (mmc0 fails and mmc1 is called)
sd0+sd1/sd0 mmc0/mmc1 (mmc1 never called)
sd0+sd1/sd1 mmc1/mmc0 (mmc0 never called)

All other bootmodes are not affected but order can be extended to cover
advance boot flows.

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

arm64: zynqmp: spl: install a PMU firmware config object at runtime

Optionally allow U-Boot to load a configuration object into the Power
Management Unit (PMU) firmware on Xilinx ZynqMP.

The configuration object is required by the PMU FW to enable most SoC
peripherals. So far the only way to boot using U-Boot SPL was to hard-code
the configuration object in the PMU firmware. Allow a different boot
process, where the PMU FW is equal for any ZynqMP chip and its
configuration is passed at runtime by U-Boot SPL.

All the code for Inter-processor communication with the PMU is isolated in
a new file (pmu_ipc.c). The code is inspired by the same feature as
implemented in the Xilinx First Stage Bootloader (FSBL) and Arm Trusted
Firmware:

* https://github.com/Xilinx/embeddedsw/blob/fb647e6b4c00f5154eba52a88b948195b6f1dc2b/lib/sw_apps/zynqmp_fsbl/src/xfsbl_misc_drivers.c#L295
* https://github.com/ARM-software/arm-trusted-firmware/blob/c48d02bade88b07fa7f43aa44e5217f68e5d047f/plat/xilinx/zynqmp/pm_service/pm_api_sys.c#L357

SPL logs on the console before loading the configuration object:

U-Boot SPL 2019.07-rc1-00511-gaec224515c87 (May 15 2019 - 08:43:41 +0200)
Loading PMUFW cfg obj (2008 bytes)
EL Level: EL3
...

Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

arm64: zynqmp: Fix logic around CONFIG_ZYNQ_SDHCI

Replace SDHCI controller listing by Kconfig symbol to let SPL know that
this board is using multiple SDHCIs controllers.
Kconfig help message should explain why this is needed.
Origin symbols were used in full u-boot but with moving to distro boot
this was fixed already.

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

spl: Kconfig: Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT

Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT so
obj-$(CONFIG_$(SPL_)FS_FAT) can be used to control the build in both
SPL and U-Boot.

Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

arm64: zynqmp: Move SoC sources to mach-zynqmp

Similar changes was done for Zynq in past and this patch just follow
this pattern to separate cpu code from SoC code.

Move arch/arm/cpu/armv8/zynqmp/* -> arch/arm/mach-zynqmp/*
And also fix references to these files.

Based on
"ARM: zynq: move SoC sources to mach-zynq"
(sha1: 0107f2403669f764ab726d0d404e35bb9447bbcc)

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

xilinx: kconfig: Move sourcing of board Kconfig to mach folders

Do not source xilinx board Kconfig by other boards. These configs should be
available only when Xilinx platforms are selected.

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

arm64: zynqmp: Add board_boot_order for MMC boot extension

In past SPL_ZYNQMP_TWO_SDHCI symbol was introduced to handle boards with
two sdhci controllers. The problem was that U-Boot is registering
controllers based on aliases in DT but bootmode targets specific controller
ID. That's why on boards with one "second" sdhci controller bootmode was
pointing to second controller(MMC2) but alias was setup to mmc0 (the first
controller). And SPL requires to point to mmc0 in this case.

Long time ago commit f101e4bd3703
("spl: add support for alternative boot device") added support for handling
multiple bootmodes in SPL. Use this functionality and setup second sdhci
controller as backup boot device.

Below is table with behavior:
HW/bootmode bootorder
sd0/sd0 mmc0/mmc1 (mmc1 never called)
sd1/sd1 mmc1/mmc0 (mmc0 fails and mmc1 is called)
sd0+sd1/sd0 mmc0/mmc1 (mmc1 never called)
sd0+sd1/sd1 mmc1/mmc0 (mmc0 never called)

All other bootmodes are not affected but order can be extended to cover
advance boot flows.

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

arm64: zynqmp: spl: install a PMU firmware config object at runtime

Optionally allow U-Boot to load a configuration object into the Power
Management Unit (PMU) firmware on Xilinx ZynqMP.

The configuration object is required by the PMU FW to enable most SoC
peripherals. So far the only way to boot using U-Boot SPL was to hard-code
the configuration object in the PMU firmware. Allow a different boot
process, where the PMU FW is equal for any ZynqMP chip and its
configuration is passed at runtime by U-Boot SPL.

All the code for Inter-processor communication with the PMU is isolated in
a new file (pmu_ipc.c). The code is inspired by the same feature as
implemented in the Xilinx First Stage Bootloader (FSBL) and Arm Trusted
Firmware:

* https://github.com/Xilinx/embeddedsw/blob/fb647e6b4c00f5154eba52a88b948195b6f1dc2b/lib/sw_apps/zynqmp_fsbl/src/xfsbl_misc_drivers.c#L295
* https://github.com/ARM-software/arm-trusted-firmware/blob/c48d02bade88b07fa7f43aa44e5217f68e5d047f/plat/xilinx/zynqmp/pm_service/pm_api_sys.c#L357

SPL logs on the console before loading the configuration object:

U-Boot SPL 2019.07-rc1-00511-gaec224515c87 (May 15 2019 - 08:43:41 +0200)
Loading PMUFW cfg obj (2008 bytes)
EL Level: EL3
...

Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>

arm64: zynqmp: Fix logic around CONFIG_ZYNQ_SDHCI

Replace SDHCI controller listing by Kconfig symbol to let SPL know that
this board is using multiple SDHCIs controllers.
Kconfig help message should explain why this is needed.
Origin symbols were used in full u-boot but with moving to distro boot
this was fixed already.

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

spl: Kconfig: Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT

Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT so
obj-$(CONFIG_$(SPL_)FS_FAT) can be used to control the build in both
SPL and U-Boot.

Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

arm64: zynqmp: Move SoC sources to mach-zynqmp

Similar changes was done for Zynq in past and this patch just follow
this pattern to separate cpu code from SoC code.

Move arch/arm/cpu/armv8/zynqmp/* -> arch/arm/mach-zynqmp/*
And also fix references to these files.

Based on
"ARM: zynq: move SoC sources to mach-zynq"
(sha1: 0107f2403669f764ab726d0d404e35bb9447bbcc)

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

xilinx: kconfig: Move sourcing of board Kconfig to mach folders

Do not source xilinx board Kconfig by other boards. These configs should be
available only when Xilinx platforms are selected.

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

arm64: zynqmp: Add board_boot_order for MMC boot extension

In past SPL_ZYNQMP_TWO_SDHCI symbol was introduced to handle boards with
two sdhci controllers. The problem was that U-Boot is registering
controllers based on aliases in DT but bootmode targets specific controller
ID. That's why on boards with one "second" sdhci controller bootmode was
pointing to second controller(MMC2) but alias was setup to mmc0 (the first
controller). And SPL requires to point to mmc0 in this case.

Long time ago commit f101e4bd3703
("spl: add support for alternative boot device") added support for handling
multiple bootmodes in SPL. Use this functionality and setup second sdhci
controller as backup boot device.

Below is table with behavior:
HW/bootmode bootorder
sd0/sd0 mmc0/mmc1 (mmc1 never called)
sd1/sd1 mmc1/mmc0 (mmc0 fails and mmc1 is called)
sd0+sd1/sd0 mmc0/mmc1 (mmc1 never called)
sd0+sd1/sd1 mmc1/mmc0 (mmc0 never called)

All other bootmodes are not affected but order can be extended to cover
advance boot flows.

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